Attila Bakos

Thanks for the link, but it's really hard to judge from these samples. From what I see I don't think Fuji changed anything, but I'll keep checking when new samples pop up. I spent quite some time recently to see how they handle skin tone colors compared to Canon. They try to equalize hue and luminosity to an extent we still consider natural when looking at it. It already hides some of the skin issues, but you don't even notice this unless you compare to an other camera. Then there is the chroma smoothing which adds another layer of flattening, so I tend to think this is all on purpose, to produce a flat looking skin, which is something a lot of people love. For this reason I don't think Fuji would ever remove this "feature", unless the majority of people start to demand something else.

It's a Fuji thing, it was there on the GFX line as well.

I'd bet a huge amount that it still uses the good old chroma smoothing, but the specs are lovely and I'm ready to be surprised. According to the latest rumor it's $7500.

Without testing it's hard to say who's responsibility it is 🙂 Of course now I know that it happens in the Video Assist as well, it's clear that it's Fuji's fault, but I didn't know that for a long time, neither did they, yet their effort was as low as possible.

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 just recorded 2 minutes of 3584 x 1730 14bit (I stopped it after 2mins). It was a scene with very fine details from edge to edge, to give the compression a hard time. If you don't ETTR in this mode, you should be fine, I don't know why you only get seconds (I suppose global draw is off).

Do you have the latest custom build from Danne? For me 3584x1730 at 14bit is continuous, as long as I don't have clipped highlights. 12bit is hard to break.

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.

The maximum I could get out from my 5D3 is 3584 x 1730 in 14bit lossless. That's not binned, it uses a 1.6x crop. We are now at around 150MB/s maximum with card spanning, sd card overclocking and several hacks to boost performance. And some talented people are still tweaking this thing.

When you test this make sure you cut the first second or so. Chroma is worse in the first few frames. Will test what you found later. The problem I described in my video is that ProRes RAW doesn't even have the DR of F-Log.

Actually I'm not a colorist, I'm a developer who loves color science, but I can tell you that the loss of color is final, no chance to get it back.

I needed similar in-camera and external resolutions for a fair comparison. 6.2K was the only way because in ProRes RAW you only have full-sensor 6.2K or cropped 4.8K. I don't have a CF card so I can only record ProRes HQ to the Ninja, and 6.2K is not available there, it's only available in ProRes RAW mode. This is the reason for internal H.265 instead of ProRes HQ. And if you record in UHD 24p, internal H.265 has actually more bitrate than ProRes HQ (720Mbps vs 707Mbps). I tested it, H.265 actually looks better due to more efficient compression. To you other question, I did not use any LUTs during my testing, I usually work with color space transform or aces nodes.

Summary of my findings so far:

Yes the blacks are just cut at a certain point, F-Log has at least 1 stop advantage over ProRes RAW, F-Log2 even more. Even 5D3 ML RAW has better dynamic range in 12bit mode. Something is not right about blacks being cut like this, I have no idea why Fuji does it. The only good thing I can say about ProRes RAW on the X-H2s is the color, this is the only way out of Fuji's chroma smoothing.

Well, just got reply from Atomos about the bad pixel issue in 6.2K raw: Please note that our engineering has gone over your case and replicated and tested your setup. Unfortunately, the issue lies with the camera as it is outputting the bad pixel in 6.2 k RAW. We would love to help you fix the issue but as it is on the camera end our hands are tied. Please contact the camera manufacturer to get this issue resolved. Fuji doesn't give a shit about my emails, so I wouldn't expect a fix anytime soon. This, and the framerate issue, and also the fact that Fuji's ProRes RAW has noticeably less dynamic range than F-Log, not to mention F-Log2, makes me loose faith in this company, they do a lot of things right but they always have to fuck up little things like this.

I'll correct myself, it's there in the Ninja V clips as well.

A small update on the X-H2s + Ninja raw recording. We tried another body and another recorder as well, and this is a general issue, not related to my unit. When you put the body to 6.2K raw mode sometimes you will get like 12 fps. It's easy to reproduce it when you switch between 23.98 and 24fps 10-20 times, at some point you will enter this low fps mode, and sometimes it stays in this mode even if you hit record. Really annoying. I also checked this another X-H2s body for that specific "bad pixel", and it's there, only in 6.2K raw mode, so this is a general issue as well. However, it was not visible when we used the Ninja V, it's related to the Ninja V Plus. I'm discussing these with Atomos already, will keep you posted. However, Fuji doesn't reply to any of my emails, so if it's their fault, I'm not sure what I can do.

Ok thanks, it seems to be the same location but I'd like to make sure :)

Thanks but I meant an actual still image from the recorded clip, so that I can check the exact location.

Can you send me a still that shows this pixel? I wonder if the location is the same...

Interesting you say that because I have a single pixel in the center of the screen as well, only in 6.2K ProRes RAW, it's not visible in 4.8K. If it's a bad pixel I'm not sure how Atomos could fix that, and why it's there in 6.2K and not in 4.8K. Even 4.8K60 is fine. Anyway, this is what I'm getting: https://drive.google.com/file/d/1m1w9o4LmO85ER9AWg3OFgQnJK1Q9cmMR/view?usp=share_link In the first half I pressed record on the Fuji, and I got like 12fps. Then I turned recording off and back on, and it was fine after that, as you can see in the second half. And this is one way to trigger it (download before watching): https://drive.google.com/file/d/1G0J2dvH2IS0mZIWlee0DZ5Rf4xvz97IK/view?usp=share_link But basically any change can trigger it, like tapping on the screen to refocus, it's totally random.

Does anyone use the X-H2s with a Ninja V Plus? Some of my 6.2K 24fps clips are stuttering badly, only every second frame is different, so it's basically 12fps. It happens and goes away by random camera actions. So if it's good and you don't touch the body it stays good. But even refocusing can make it bad. The camera is in boost mode, I hit recording on the body as well, newest firmware everywhere. The cable I'm using is HDMI2.1 8K60 certified, should be more than enough. I'm out of ideas really, I hope it's a user error but I fear that it's not.

To anyone who is interested in recording ProRes RAW with the X-H2s, I just got confirmation from Fuji that they convert X-Trans to Bayer in the camera, as I suspected. Because the two patterns are different, you have to calculate what's not there. So let's say at a given pixel X-Trans stores red but for Bayer we need blue. I asked Fuji if they interpolate this blue using the surrounding blue values in the X-Trans pattern or they just copy the value of a blue neighboring pixel. The latter is faster but more prone to artifacts. Unfortunately I received an one-liner that this is proprietary info. I'll know more when I test this out myself, I'll receive a Ninja V+ in the following days.