Attila Bakos

I'm fed up with Atomos, I wasted a huge amount of time doing tests for them for the stuttering issue in ProRes RAW. They didn't even try to replicate it. I reported the problem at the 8th of February, since then I provided tons of test material. And where are we now? They still think it's my unit, or my SSD or my HDMI cable even when I told them I tested with multiple units, multiple cables and SSDs. Unbelievable.
In the meantime some other guy asked BlackMagic about the same issue (so apparently this is related the the X-H2s), and they sent it to their engineering team right away, they reproduced it and notified Fujifilm about it. HUGE difference between the two supports. Seriously, even Fuji is better than Atomos, because they don't reply at all, so you won't waste your time with them 🙂

The reason here is a bit different though. V-Log L clips at 80 IRE so my LUTs in the V-Log L LUT pack will push that to white. V-Log on the S1 clips at 88 IRE if I remember correctly so any information between 80-88 IRE will be lost, even if the interpretation of the clip is correct (full vs video range).

The reason here is a bit different though. V-Log L clips at 80 IRE so my LUTs in the V-Log L LUT pack will push that to white. V-Log on the S1 clips at 88 IRE if I remember correctly so any information between 80-88 IRE will be lost, even if the interpretation of the clip is correct (full vs video range).

@kye Great. Thank you for adding that note. I'm quite protective of highlights generally at the point of capture (as long as I'm not compromising skin tones) as I find that clipping is the greatest remaining "digital tell" that can usually be avoided. But this is always good to keep in mind. 
@Attila Bakos I've never approached LUTs as a "click and done" solution, particularly wanting to preserve options for the further application of tone curves. Since moving on from (and now partially back to) Fujifilm, I have missed Eterna as a baseline for further work. To date, my best, neutral LUT for V-Log has been a 2021 LUT by Gamut applied at 80% - even then the shadows would generally be more crushed that I'd prefer for further grading.
Your Eterna LC LUT! It's marvelous for how I like to work! I am now editing a piece that I filmed primarily last year. Replacing the Gamut with this low-contrast LUT - I really like the color interpretation (even in some challenging mixed-lighting) and a whole world of shadows is available to further work with, rather than to try and pull back in some fashion. 
Just so, so nice. 

@Walter H Thanks a lot, your feedback is very much appreciated. While the V-Log L version might work for the S1, keep an eye on the highlights, if the LUT clips them,  gently pull them down before the LUT is applied. The S5IIx package might be a better choice for you but I haven't started working on it yet. Whenever that's finished and you decide to get them, just let me know before you do :)

Hello,
This is the official topic for all Colorizer products.
My main focus is bringing high-precision Fujifilm Film Simulation LUTs to multiple cameras.
The following formats are supported at the moment, click the links for videos and details:
Fujifilm X-T3/X-T4 F-Log
Sony S-Log2/S-Gamut3.cine
Panasonic V-Log L & HLG
I also sell ACES IDTs for cameras that are not natively supported by Davinci Resolve:
- Fujifilm F-Log/F-Gamut
- Nikon N-Log/BT.2020
- Sony S-Log2/S-Gamut3.cine
- Z Cam ZLog2
- GoPro Protune
These packs include a lot of 3D LUTs simulating the ACES Rec.709 look, so it can be valuable for Premiere users as well.
I also have Technical fixes for common color shift issues caused by bad interpretation of certain clips in Premiere. I strongly suggest you check this out if you're a Fujifilm user.
As a bonus I created a bunch of free online tools for creating and modifying 3D LUTs, so if you're into this kind of stuff, visit http://colorizer.net.
Thank you for your attention,
Attila

Hello,
This is the official topic for all Colorizer products.
My main focus is bringing high-precision Fujifilm Film Simulation LUTs to multiple cameras.
The following formats are supported at the moment, click the links for videos and details:
Fujifilm X-T3/X-T4 F-Log
Sony S-Log2/S-Gamut3.cine
Panasonic V-Log L & HLG
I also sell ACES IDTs for cameras that are not natively supported by Davinci Resolve:
- Fujifilm F-Log/F-Gamut
- Nikon N-Log/BT.2020
- Sony S-Log2/S-Gamut3.cine
- Z Cam ZLog2
- GoPro Protune
These packs include a lot of 3D LUTs simulating the ACES Rec.709 look, so it can be valuable for Premiere users as well.
I also have Technical fixes for common color shift issues caused by bad interpretation of certain clips in Premiere. I strongly suggest you check this out if you're a Fujifilm user.
As a bonus I created a bunch of free online tools for creating and modifying 3D LUTs, so if you're into this kind of stuff, visit http://colorizer.net.
Thank you for your attention,
Attila

Hi, the X-H2s Film Simulation LUT pack is finally finished, see the demo video here:
Product details: https://colorizer.net/index.php?op=xh2s
The F-Log implementation on the X-H2s is slightly different from that of the X-H2/X-T5/X100VI, but the difference is very small, so you might be able to use this pack on those bodies as well. If you send me clips I can apply all the LUTs just to make sure. (I only have access to an X-H2s at the moment.)
I also added extra LUTs to the X-T3 LUT pack:
- Classic Neg
- Nostalgic Neg
- Eterna Bleach Bypass
This is a free addition to anyone who purchased this LUT pack before.
Product details: https://colorizer.net/index.php?op=xt3
About the future:
I invested a lot of time into the original EOS R to create Fuji Filmsims for C-Log but I faced many technical difficulties I could not solve. The thing is it reacts very differently to changes in light compared to the Fuji and the resulting LUTs were only precise in very specific lighting conditions. I also have an R6II in the house so I might focus on that body instead, maybe that's a better match for what I'm trying to do here.
I also have an S5IIx with me, we'll see what I can do with that camera, I'm very curious about the realtime LUT feature.

Thank you, the smoothing is there, no doubt about it.

I'm fed up with Atomos, I wasted a huge amount of time doing tests for them for the stuttering issue in ProRes RAW. They didn't even try to replicate it. I reported the problem at the 8th of February, since then I provided tons of test material. And where are we now? They still think it's my unit, or my SSD or my HDMI cable even when I told them I tested with multiple units, multiple cables and SSDs. Unbelievable.
In the meantime some other guy asked BlackMagic about the same issue (so apparently this is related the the X-H2s), and they sent it to their engineering team right away, they reproduced it and notified Fujifilm about it. HUGE difference between the two supports. Seriously, even Fuji is better than Atomos, because they don't reply at all, so you won't waste your time with them 🙂

I'm fed up with Atomos, I wasted a huge amount of time doing tests for them for the stuttering issue in ProRes RAW. They didn't even try to replicate it. I reported the problem at the 8th of February, since then I provided tons of test material. And where are we now? They still think it's my unit, or my SSD or my HDMI cable even when I told them I tested with multiple units, multiple cables and SSDs. Unbelievable.
In the meantime some other guy asked BlackMagic about the same issue (so apparently this is related the the X-H2s), and they sent it to their engineering team right away, they reproduced it and notified Fujifilm about it. HUGE difference between the two supports. Seriously, even Fuji is better than Atomos, because they don't reply at all, so you won't waste your time with them 🙂

I'm fed up with Atomos, I wasted a huge amount of time doing tests for them for the stuttering issue in ProRes RAW. They didn't even try to replicate it. I reported the problem at the 8th of February, since then I provided tons of test material. And where are we now? They still think it's my unit, or my SSD or my HDMI cable even when I told them I tested with multiple units, multiple cables and SSDs. Unbelievable.
In the meantime some other guy asked BlackMagic about the same issue (so apparently this is related the the X-H2s), and they sent it to their engineering team right away, they reproduced it and notified Fujifilm about it. HUGE difference between the two supports. Seriously, even Fuji is better than Atomos, because they don't reply at all, so you won't waste your time with them 🙂

I'm fed up with Atomos, I wasted a huge amount of time doing tests for them for the stuttering issue in ProRes RAW. They didn't even try to replicate it. I reported the problem at the 8th of February, since then I provided tons of test material. And where are we now? They still think it's my unit, or my SSD or my HDMI cable even when I told them I tested with multiple units, multiple cables and SSDs. Unbelievable.
In the meantime some other guy asked BlackMagic about the same issue (so apparently this is related the the X-H2s), and they sent it to their engineering team right away, they reproduced it and notified Fujifilm about it. HUGE difference between the two supports. Seriously, even Fuji is better than Atomos, because they don't reply at all, so you won't waste your time with them 🙂

I'm fed up with Atomos, I wasted a huge amount of time doing tests for them for the stuttering issue in ProRes RAW. They didn't even try to replicate it. I reported the problem at the 8th of February, since then I provided tons of test material. And where are we now? They still think it's my unit, or my SSD or my HDMI cable even when I told them I tested with multiple units, multiple cables and SSDs. Unbelievable.
In the meantime some other guy asked BlackMagic about the same issue (so apparently this is related the the X-H2s), and they sent it to their engineering team right away, they reproduced it and notified Fujifilm about it. HUGE difference between the two supports. Seriously, even Fuji is better than Atomos, because they don't reply at all, so you won't waste your time with them 🙂

I'm fed up with Atomos, I wasted a huge amount of time doing tests for them for the stuttering issue in ProRes RAW. They didn't even try to replicate it. I reported the problem at the 8th of February, since then I provided tons of test material. And where are we now? They still think it's my unit, or my SSD or my HDMI cable even when I told them I tested with multiple units, multiple cables and SSDs. Unbelievable.
In the meantime some other guy asked BlackMagic about the same issue (so apparently this is related the the X-H2s), and they sent it to their engineering team right away, they reproduced it and notified Fujifilm about it. HUGE difference between the two supports. Seriously, even Fuji is better than Atomos, because they don't reply at all, so you won't waste your time with them 🙂

I could only download one example which did not have it but I don't want to base my opinion on one example only. Does anyone have downloadable 6.2k BRAW from the X-H2s?
However people already confirmed to me that BRAW also has the stuttering issue so it's definitely a Fuji problem.
In general I would prefer ProRes RAW since it's true raw in a sense that it's needs the same processing as a common raw file after it's decompressed. BRAW seems to be more processed with slightly less color detail, but I believe you'll only see it when pixel peeping. The obvious difference is that BRAW works in Resolve, which is a big plus given how large these files are, it can be a pain to convert ProRes RAW.
But anyway both of them are unusable at the moment, I have a feeling that we only have raw for marketing reasons in this body. With the current issues and less DR it's garbage.

I analyzed the raw data in the DNG converted from ProRes RAW and now I know exactly how it's messed up.
I adjusted my tool and I think I have a working fix now. It fixes the raw data itself, so the result will be perfect in every software that reads DNG.
Before (see the broken line in the middle):

After:

 
I'm still testing my tool, it can read 12/16bit DNG, uncompressed, or lossless compressed, the lossy formats are not supported. It uses multiple threads, on my recent i7 laptop it converts with 25-35fps.
It's a pain to convert twice but at least I got it working, and learned a bit of C++ on the way.
If only I could fix the framerate issue as well, but no chance for that.

I analyzed the raw data in the DNG converted from ProRes RAW and now I know exactly how it's messed up.
I adjusted my tool and I think I have a working fix now. It fixes the raw data itself, so the result will be perfect in every software that reads DNG.
Before (see the broken line in the middle):

After:

 
I'm still testing my tool, it can read 12/16bit DNG, uncompressed, or lossless compressed, the lossy formats are not supported. It uses multiple threads, on my recent i7 laptop it converts with 25-35fps.
It's a pain to convert twice but at least I got it working, and learned a bit of C++ on the way.
If only I could fix the framerate issue as well, but no chance for that.

I analyzed the raw data in the DNG converted from ProRes RAW and now I know exactly how it's messed up.
I adjusted my tool and I think I have a working fix now. It fixes the raw data itself, so the result will be perfect in every software that reads DNG.
Before (see the broken line in the middle):

After:

 
I'm still testing my tool, it can read 12/16bit DNG, uncompressed, or lossless compressed, the lossy formats are not supported. It uses multiple threads, on my recent i7 laptop it converts with 25-35fps.
It's a pain to convert twice but at least I got it working, and learned a bit of C++ on the way.
If only I could fix the framerate issue as well, but no chance for that.

I analyzed the raw data in the DNG converted from ProRes RAW and now I know exactly how it's messed up.
I adjusted my tool and I think I have a working fix now. It fixes the raw data itself, so the result will be perfect in every software that reads DNG.
Before (see the broken line in the middle):

After:

 
I'm still testing my tool, it can read 12/16bit DNG, uncompressed, or lossless compressed, the lossy formats are not supported. It uses multiple threads, on my recent i7 laptop it converts with 25-35fps.
It's a pain to convert twice but at least I got it working, and learned a bit of C++ on the way.
If only I could fix the framerate issue as well, but no chance for that.

I analyzed the raw data in the DNG converted from ProRes RAW and now I know exactly how it's messed up.
I adjusted my tool and I think I have a working fix now. It fixes the raw data itself, so the result will be perfect in every software that reads DNG.
Before (see the broken line in the middle):

After:

 
I'm still testing my tool, it can read 12/16bit DNG, uncompressed, or lossless compressed, the lossy formats are not supported. It uses multiple threads, on my recent i7 laptop it converts with 25-35fps.
It's a pain to convert twice but at least I got it working, and learned a bit of C++ on the way.
If only I could fix the framerate issue as well, but no chance for that.

Remember we discussed earlier that X-H2s 6.2K ProRes RAW has a hot pixel at the exact same location for everyone?
I spent days to create an executable in C++ that removes that hot pixel from the DNG raw file created from ProRes RAW.
I was just about to post it here but then I noticed that this is not a hot pixel issue at all! All pixels in the same row right from the hot pixel are shifted towards the right.
See here:

It starts with the hot pixel, and it goes all the way to the right edge.
Or here (this is the right edge of an image, you don't see the hot pixel here, it's somewhere in the middle):

 
Atomos says it's Fuji's fault, and as usual, Fuji couldn't care less.
Atomos is also silent about the framerate bug I discovered. A new firmware was released just now and it's not fixed, it's not even listed in the known bugs.
Stuff like this makes me really disillusioned.
 

Remember we discussed earlier that X-H2s 6.2K ProRes RAW has a hot pixel at the exact same location for everyone?
I spent days to create an executable in C++ that removes that hot pixel from the DNG raw file created from ProRes RAW.
I was just about to post it here but then I noticed that this is not a hot pixel issue at all! All pixels in the same row right from the hot pixel are shifted towards the right.
See here:

It starts with the hot pixel, and it goes all the way to the right edge.
Or here (this is the right edge of an image, you don't see the hot pixel here, it's somewhere in the middle):

 
Atomos says it's Fuji's fault, and as usual, Fuji couldn't care less.
Atomos is also silent about the framerate bug I discovered. A new firmware was released just now and it's not fixed, it's not even listed in the known bugs.
Stuff like this makes me really disillusioned.
 

Remember we discussed earlier that X-H2s 6.2K ProRes RAW has a hot pixel at the exact same location for everyone?
I spent days to create an executable in C++ that removes that hot pixel from the DNG raw file created from ProRes RAW.
I was just about to post it here but then I noticed that this is not a hot pixel issue at all! All pixels in the same row right from the hot pixel are shifted towards the right.
See here:

It starts with the hot pixel, and it goes all the way to the right edge.
Or here (this is the right edge of an image, you don't see the hot pixel here, it's somewhere in the middle):

 
Atomos says it's Fuji's fault, and as usual, Fuji couldn't care less.
Atomos is also silent about the framerate bug I discovered. A new firmware was released just now and it's not fixed, it's not even listed in the known bugs.
Stuff like this makes me really disillusioned.
 

Remember we discussed earlier that X-H2s 6.2K ProRes RAW has a hot pixel at the exact same location for everyone?
I spent days to create an executable in C++ that removes that hot pixel from the DNG raw file created from ProRes RAW.
I was just about to post it here but then I noticed that this is not a hot pixel issue at all! All pixels in the same row right from the hot pixel are shifted towards the right.
See here:

It starts with the hot pixel, and it goes all the way to the right edge.
Or here (this is the right edge of an image, you don't see the hot pixel here, it's somewhere in the middle):

 
Atomos says it's Fuji's fault, and as usual, Fuji couldn't care less.
Atomos is also silent about the framerate bug I discovered. A new firmware was released just now and it's not fixed, it's not even listed in the known bugs.
Stuff like this makes me really disillusioned.