Attila Bakos

9 hours ago, Daniel Robben said:

Concerning chroma details, I tested a bit, and noticed a jump of increased color details at ISO 3200 in standard profiles. Further, h265 All-I is a bad choice vs longGOP for such detailed not moving scenes. Prores has advantage as well here, even if its Intra frame encoding. f-log2 also worse than standard profiles.

So the best I could get (and almost completely get rid of smoothing) is with Prores HQ at ISO 3200 in standard profile.

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.

6 hours ago, D Verco said:

Also internal Flog2 will always have more dynamic range than the raw options because it's coming from a 14bit readout

The problem I described in my video is that ProRes RAW doesn't even have the DR of F-Log.

25 minutes ago, Django said:

@Attila Bakos As a colorist do you know of any solutions to get the loss of colour back in post on the internal codecs or is it just gone forever? Fuji XTrans is usually touted for its color science and film simulations which is why its so disheartning and even confusing to watch these findings where it seems in fact very poor in this domain versus any other typical bayer sensor. I don't know what to make of it..

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.

2 hours ago, BrunoCH said:

Thank you for this test. I would have preferred to see ProRes HQ instead of H265. Did you delog the Flog2 with Fuji LUTs ?

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:

7 minutes ago, mechanicalEYE said:

As you mention the dynamic range internally is better. I’m just gonna use my SmallHd indie 5 monitor and stick with F-Log2

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.

On 2/11/2023 at 2:17 PM, Attila Bakos said:

However, it was not visible when we used the Ninja V, it's related to the Ninja V Plus.

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.

3 minutes ago, mechanicalEYE said:

You're welcome. I will when I can as I am currently away from home. I had that image in my phone from when I first reached out to Atomos support. I did come across a post on Instagram where another guy mentioned the same issue in 6.2K raw. He said the pixel was in the same location as mine going off the image. 

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

20 minutes ago, mechanicalEYE said:

 

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

40 minutes ago, mechanicalEYE said:

both units have a single pixel that is stuck on center of screen in 6.2K any frame rate

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

36 minutes ago, mechanicalEYE said:

I have them both, a X-H2s with two Ninja V+ recorders. Neither Ninja presented any stuttering but both units have a single pixel that is stuck on center of screen in 6.2K any frame rate. This pixel is also on the off loaded footage, but again in 6.2K only. It does not happen when recording 4K of any frame rate. I sent Atomos clips to review and they believe its firmware on their end. Not sure they'll move on it too soon if others aren't reporting it but to me it seems most X-H2s users are using the Ninja V and not the Ninja V+.

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.

6 hours ago, PannySVHS said:

Would love to hear your opinion about the GH6! @Attila Bakos

External recording with the Fuji is fine though? Thanks for your findings and contributions!

I don't have the GH6 unfortunately, but I checked a ProRes HQ V-Log L sample and the chroma channels are very good.

The Fuji chroma smoothing is there in all internal and external recordings, the only exception is ProRes RAW. As I mentioned earlier it's weird though. ProRes RAW can not hold X-Trans data, it's designed for Bayer. Atomos already confirmed to me that they don't modify the raw feed. I'm still waiting for Fuji's answer, but the only thing I can imagine is they demosaic X-Trans in the body, then remosaic it into Bayer and send that to the recorder. While it works it is kind of a trick, and when we compare ProRes RAW features to BRAW, one of the main things that sets them apart is that ProRes RAW is not debayered and thus more raw-like, while BRAW is partially debayered. So I'm not sure if we can talk about being not debayered as an advantage here, as the raw feed that the Ninja V records is actually already processed by the camera.
And if you go into details, demosaicing is basically filling the "holes" in the R,G,B planes by interpolation methods, using the pixels that are known. See the "holes" here (it's for Bayer, but you'll get the point):

Now if you remosaic the R,G,B planes to Bayer, you have to throw away about half the originally known values, as the pattern is different. You exchange them to interpolated values and send them to the Ninja as if they were the known values from the sensor. I have my doubts about the quality of this method, but I will test it when my Ninja V Plus arrives.

Revised my findings, the previous comment can be deleted.
(Both bodies are equally bad in 1080p.)

I read some comments about the 1080p quality being worse on the X-H2s than on the X-T3/4, and I thought it's nonsense, but after a few quick tests it is worse indeed, for some reason the moiré/aliasing artifacts are more pronounced. Not sure about the reason yet, maybe the readout is different.

Recently purchased the X-H2s, and you know me, the first thing I look at is chroma resolution. Just dropping this in, on the left side you see the Cr channel of an EOS R 4K C-Log 8bit 4:2:0 recording (about 420 Mbps), on the right side it's X-H2s 4K F-Log 10bit 4:2:2 (about 615Mbps):

Don't get me wrong it's better than the X-T3, but this smoothing can still lead to loss of color. I really wish we could turn it off and deal with color noise in post.

ProRes RAW helps but it's a mystery to me. RAW on the X-H2s has the X-Trans pattern, obviously. However, it gets magically converted into Bayer in the ProRes RAW file. I had discussions with people who are involved in ProRes RAW->DNG conversion, also did my own test with Raw convertor (resulting DNG has Bayer pattern) and it seems that the data that arrives to a Ninja V recorder is already Bayer, even though the sensor is X-Trans. I'm still trying to confirm all this but if the body demosaics the X-Trans pattern and remosaics it into Bayer, then it's kind of a hack which in some cases can lead to artifacts.

10 hours ago, Daniel Robben said:

Thanks, yes, I reckonized but thought that's normal for non-all-intra frame encoding like long GOP. From my head I believe in prores first frames were same quality as following.

Ah yes you are probably right 🙂

On 11/22/2022 at 10:08 PM, Daniel Robben said:

I checked this chroma smoothing issue on my X-H2s and I noticed that the chroma channel details are far better preserved when NOT using f-log or f-log2.

Luma channel seems to perform the opposite, however not as significant.

Yes the log profiles are worse. Btw when you're testing chroma components in Fuji files, make sure to skip the first few frames, those are worse than the rest.

On 11/21/2022 at 8:51 PM, PannySVHS said:

 @Attila Bakos has recognized the Fuji XH2s having a lack in colour resolution, blurring the red channel.

It's not the red channel that's blurred but the chroma components in the YCbCr format, that is Cb, and Cr. Both Cb and Cr are blurred the same way, but I used Cr for demonstration as it shows the issue a bit better. Btw Cr is red minus luma, so you are not that far from the truth 🙂

Forgot to mention that in this test in hybrid mode the decoding was done by the iGPU and the encoding was done by the dedicated GPU (as I encoded to 4:2:0), so they can really work together.

4 hours ago, herein2020 said:

I believe you are referring to Intel Arc, that's the only card I am aware of that can do that. The problem is if you already have a desktop that is not QS capable then the only way to get a QS capable system is to buy or build a new one.

No, I'm referring to NVIDIA/AMD. I just did a test for you. I have a Lenovo Legion 5i Pro laptop with an i7-12700h CPU and a 3070Ti GPU. I loaded a 2160p 4:2:2 HEVC F-Log clip to Resolve, added a LUT and some tweaking.
With hybrid mode enabled (that is Resolve can use both internal GPU and the dedicated one), I get smooth 25fps playback with low CPU usage and rendered out the clip with the H.265 Master preset in 18 seconds.
Now if I switch to dedicated GPU only mode, I get 21-23 fps playback and high CPU usage and the clip rendered out in 41 seconds.
So basically with 10th or higher gen Intel CPU I get 4:2:2 support in addition to what the GPU already offers, no need for a Mac (for this).

4 hours ago, herein2020 said:

Yes but to get that you need to buy a whole new PC, not an option to me and if you study Puget Sound's results, QS is still only marginal; meaning if you add DR color grades, and throw in a little Fusion and you are back to where you started; definitely not M1 Mac competition. There's just no way I am buying a whole new PC when all I need is a video card. 

But what if you have an Intel processor with 4:2:2 decoding support and a dedicated GPU? I was under the impression that they can work together.

20 minutes ago, herein2020 said:

It is very disappointing that in 2022 PC users still have no video card options for 4:2:2.

That's true, however Intel QuickSync supports hw encoding/decoding of 4:2:2 HEVC since Gen10. Better than nothing 🙂