Possible regression: h.265 interpreted as video levels

I have some footage from a Fuji X-T3 recorded internally as h.265 and externally as ProRes 422. I'm finding in the current latest beta on OS X that I need to set the ProRes 422 to video levels to match the internal clip's full data levels. In other words, it seems the h.265 interpreted as full range is actually getting interpreted as video range.

I don't have Resolve 15 installed on my laptop any more, but from what I recall it behaved as I would expect where if both clips were set to full range then they would have the same luminance levels.

For example, see this video here:

(there's a separate issue in this video with 601 vs 709 interpretation with the h.265 clip)

You avoid many problems by not using data levels. Unless required differently by the manufacturer (i.e. some log formats require data levels) video levels should be used.

Also, some cameras will actually use Rec601 for full levels.

The usage scenario is not broadcast, I come from a film background. Yes, I'm starting with log formats and ingesting to log dpx or linear exr masters.

But also, the behaviour seems to deviate from Resolve 15 which is why I'm saying it seems to be a regression. Basically I'm getting video levels on h265 in v16 when it's set to full range, where I'd be getting full range that would match the Pro Res full range in v15. It's not consistent behaviour. The video shows that the clips behaved as expected in Resolve 15 regardless of file format.

Ok, so you say you start with log formats, so I presume you record F-Log. F-Log requires full range. External recording may not honor that (are you using Atomos?) and instead record at video levels. That may still not be a problem (although I heard of problems with the new Ninja V). Double check the levels on the scopes using a test with the lens cap on and full sensor saturation to see if your levels comply with the F-Log spec.

Resolve, since version 15, automatically defaults certain formats to an input colorspace, overriding the project colorspace. This is a feature but it does not always do the right thing.

I am kind of puzzled by your Rec.601 comment as F-log uses Rec.2020.

Bottom line is that when you do not record F-log you really should use video levels not full levels, both for broadcast and film.

Ok, so you say you start with log formats, so I presume you record F-Log. F-Log requires full range. External recording may not honor that (are you using Atomos?) and instead record at video levels. That may still not be a problem (although I heard of problems with the new Ninja V). Double check the levels on the scopes using a test with the lens cap on and full sensor saturation to see if your levels comply with the F-Log spec.

The topic is not about external recording. I'm reporting a potential issue to Blackmagic Design about their beta software. It's concerning internal recording with h.265 not being interpreted as full range like it was in Resolve 15. So I'm saying it looks like a regression. My workaround is to apply a lut to compress full to legal range, to match the Prores full range, but this was not required in Resolve 15.

I mentioned that the video was simultaneously captured on ProRes using an Atomos and that it behaves as expected. When I set it to full range, it's full range. The internal h.265 and external ProRes should match when set to full range like in Resolve 15 but for my tests they don't.

Resolve, since version 15, automatically defaults certain formats to an input colorspace, overriding the project colorspace. This is a feature but it does not always do the right thing.

That's not relevant to this topic. I'm talking about clip attributes>data levels.

I am kind of puzzled by your Rec.601 comment as F-log uses Rec.2020.

Yes, the F-log spec has a Rec.2020 gamut. Did you watch the video? The 601 matrix issue isn't actually the reason I posted it. The video just backs up what I'm saying that I got the expected behavior with matching full range levels in Resolve 15 whether recording h.265 internal or ProRes external.

Bottom line is that when you do not record F-log you really should use video levels not full levels, both for broadcast and film.

Thanks, but I do know this. I am shooting a log format and I require the full range image so that's not relevant. The purpose of my post is to report a possible regression for the Resolve 16 beta where full range is not returned when recording to h.265.

I downgraded to Resolve 15 to double check that the internal h.265 and ProRes clips match. Now I have the same issue as in the 16 beta, which makes me think there's an underlying library that got updated by the beta and did not get rolled back when I reinstalled 15.

As you can see, in the linked video the internal and external clips matched when set to full range, and that was also my experience until I upgraded to 16. Those clips are also available to download if you need to do a sanity check.

So it certainly appears that the issue is h.265 clips are now interpreted incorrectly as video levels when set to "full". Checking the "color range" metadata tag for the h.265 clip shows it's set to full, and when converted to ProRes by EditReady, it then matches the externally recorded ProRes when they are both set to "full" in Resolve.

This is 16.0b1 for Mac, running on Mojave 10.14.3

I should also note that this is for F-log clips, HLG is a separate issue that requires some looking into.

Those clips are also available to download if you need to do a sanity check.

Where is the link to the original clips?

...HLG is a separate issue that requires some looking into.

What HLG issue?

I downgraded to Resolve 15 to double check that the internal h.265 and ProRes clips match. Now I have the same issue as in the 16 beta, which makes me think there's an underlying library that got updated by the beta and did not get rolled back when I reinstalled 15.

As you can see, in the linked video the internal and external clips matched when set to full range, and that was also my experience until I upgraded to 16. Those clips are also available to download if you need to do a sanity check.

So it certainly appears that the issue is h.265 clips are now interpreted incorrectly as video levels when set to "full". Checking the "color range" metadata tag for the h.265 clip shows it's set to full, and when converted to ProRes by EditReady, it then matches the externally recorded ProRes when they are both set to "full" in Resolve.

This is 16.0b1 for Mac, running on Mojave 10.14.3

I should also note that this is for F-log clips, HLG is a separate issue that requires some looking into.

Is it not possible that it's the Mac OS and AVfoundation that is the issue and not Resolve?

h265 file are read using OSX capabilities, but you still have some control over this from programmers point, so at the end (from the user point) this is still Resolve issue.

Using Rec.601 for HD/UHD is rather wrong and against standards, so it's Fuji problem.
In the same time you should be able to fix all of these problems inside Resolve with manual interpretation- this is what color managed processing is for. Unfortunately Resolve has no setting for Rec.601 interpretation, so it can't be easily done. Looks like BM treats SD as dead format
Full vs. legal range should work though with manual overwrite.

h265 file are read using OSX capabilities, but you still have some control over this from programmers point, so at the end (from the user point) this is still Resolve issue.

I am not convinced at all, I would want to see the actual H.264 full range file and the ProRes video range file to see which one is actually adhering to the F-log spec.

It's easy to do, make a few second video with the lens cap on for a second and then off with full sensor saturation (using a modest light, no need to actually damage the sensor), the resulting log file should adhere to the F-log minimum and maximum code value specifications and it is easy to determine if the levels are correct. It's possible that the full range F-log interpreted by the Atomos as video range is the actual culprit.

I'm not arguing which one is wrong or correct. Resolve should read flags- this is the only point. I thought this was fixed (at least for h264) some time ago in v14 or 15.
Full range YUV files are not very common so you need to flag (and then read this flag) them, otherwise it's up to user to know about it and set it manually.

Using Rec.601 for HD/UHD is rather wrong and against standards, so it's Fuji problem.

That depends. Some cameras treat full range as jpeg family, which is Rec.601. Now if Fuji puts out Rec.601 at video levels as well, there is a problem.

I'm not arguing which one is wrong or correct. Resolve should read flags- this is the only point. I thought this was fixed (at least for h264) some time ago in v14 or 15.

True, but until the poster actually provides the video files we can't really help him.

Color matrix will be wrong on ProRes as I bet you Atomos simply takes YUV data as is and flags as Rec.709 (instead of 601) as it's HD file. Problems lies in bad design by Fuji for this (at least they write correct flag in h264 headers).
With range- it's not that easy to stay which one is correct. You can create full range h264/5 from known file and check if Resolve reads it properly. No need to test on "unknown" files. It can be again Atomos issue due to source being YUV full range.

Hey all,

Thanks for your responses. I've also escalated this directly to support since it's now affecting my Resolve 15 installation (not mission critical luckily).

I just want to make it clear that in this topic I'm addressing data levels. Yes there are colour matrix issues as well, but I'm putting that aside for now. I just linked to the video to show that the person who posted it also got the same predictable behavior as I did in Resolve 15 when importing internal and external F-log clips set to Full data levels. They got matching luminance range. It would appear that this is the correct interpretation.

Here is the link to the clips in the video if you want to take a look yourself:
https://drive.google.com/drive/folders/ ... ZpDEg69zVZ

In summary, when the clips (and others of my own that I've tried) are *always both set to Full data levels* here are my results:

Resolve 15: they match, and the result is the same as in the youtube video. Everything is right.
Resolve 16 Mac beta: the h.265 clip is now expanded to the same appearance as the ProRes *video* levels.
Downgrade back to Resolve 15: unfortunately now the same behavior as in Resolve 16 beta.

I'm happy to also ignore the Atomos output and stick to internal as long as I know it's correct, but that doesn't take away from the fact that there's a shift now happening somewhere behind the scenes with the internal clip.

Checked the files and to me everything looks good!

The H.264 file is full range (as it should!) and maps the F-log code values correctly.
The ProRes file from the Atomos is video levels (as it should!) and again the code values are mapped correctly.

Not sure what you think the problem is, it's working!

ffprobe shows a pixel format of yuv420p10le.
That Fuji writes smpte170m/bt709/smpte170m for transfer, primaries and matrix does certainly not deserve a price but is probably non-essential for the log format, but one has to inspect the LUT to see if that is true as Resolve does not have a built-in transform for F-log. You might want to follow up with Fuji why they have Rec601 in the file header, as they pride themselves of being good with color!

In R16B or 15?
I think it's said that issues appears in R16B (or once you installed 16 and went back to 15).

In R16B or 15?
I think it's said that issues appears in R16B (or once you installed 16 and went back to 15).

I tested it in Resolve 16.

Atomos uses videos levels for ProRes but correctly maps the data range on the video range (which is never a problem for log). To interpret the video levels ProRes in Resolve as full range would be a mistake.

Checked the files and to me everything looks good!

The H.264 file is full range (as it should!) and maps the F-log code values correctly.
The ProRes file from the Atomos is video levels (as it should!) and again the code values are mapped correctly.

Not sure what you think the problem is, it's working!

In Resolve 15, both clips matched when data levels were set to Full Range, which as you yourself said is the correct setting for a Log recorded image. In Resolve 16 beta, for me at least, and you have now verified (backing the whole point of this topic) the behavior is now different. In the beta, as you say, the h.265 clip at full range matches the ProRes clip at video range, which I consider to be a regression. At minimum, it's an undocumented under-the-hood change compared to Resolve 15.

The 709 vs 601 issue, as I've said countless times in this thread, is not the topic of discussion and is easily solved if needed.

In Resolve 15, both clips matched when data levels were set to Full Range, which as you yourself said is the correct setting for a Log recorded image.

Not for the ProRes output from the Atomos, that must remain video levels. The Atomos correctly maps the full range HDMI input to the video levels. For log data this is not a problem, the lowest 10-bit code value is 95 and the maximum value, well you never get there.

In the beta, as you say, the h.265 clip at full range matches the ProRes clip at video range, which I consider to be a regression. At minimum, it's an undocumented under-the-hood change compared to Resolve 15.

This is really as specified, it works the same for other cameras that use full range log formats, the Atomos ProRes just does not do full range and video levels work just fine as long as you interpret the video as video levels.

In Resolve 15, both clips matched when data levels were set to Full Range, which as you yourself said is the correct setting for a Log recorded image.

Not for the ProRes output from the Atomos, that must remain video levels.

I know that the ProRes spec is based on displaying video levels. However if you record Alexa 4444 ProRes LogC/AWG and then transcode to dpx on ingest for feature film production, you do it based on Full levels. I know this from experience in production on major releases. In this case I'm also working with a log image in the same kind of workflow.

And this is not the topic of the thread. The topic is that the h.265 data levels have shifted between Resolve 15 and 16.

In Resolve 15, both clips matched when data levels were set to Full Range, which as you yourself said is the correct setting for a Log recorded image.

Not for the ProRes output from the Atomos, that must remain video levels.

I know that the ProRes spec is based on displaying video levels. However if you record Alexa 4444 ProRes LogC/AWG and then transcode to dpx on ingest for feature film production, you do it based on Full levels. I know this from experience in production on major releases. In this case I'm also working with a log image in the same kind of workflow.

And this is not the topic of the thread. The topic is that the h.265 data levels have shifted between Resolve 15 and 16.

You know, I tried to explain to you there is no problem, but it seems you just don't want to accept it.
Have a great day!

Not for the ProRes output from the Atomos, that must remain video levels. The Atomos correctly maps the full range HDMI input to the video levels. For log data this is not a problem, the lowest 10-bit code value is 95 and the maximum value, well you never get there.

A log spec with black starting at 95 is not designed to accommodate broadcast video levels. F-log, like LogC is broadly based on what was established in the Kodak Cineon spec. The generic interpretation of a Cineon file going back years was black point 95, white point 685 out of 1024 code values.

You know, I tried to explain to you there is no problem, but it seems you just don't want to accept it.
Have a great day!

Sure, I've escalated it to support already. I didn't need you to "explain" anything to me, and you seemed to have failed to grasp the issue that the behavior deviates between Resolve 15 and 16.

In the same time you should be able to fix all of these problems inside Resolve with manual interpretation- this is what color managed processing is for. Unfortunately Resolve has no setting for Rec.601 interpretation, so it can't be easily done.

I know this is not the main issue in this topic, just adding my thoughts: you can't fix a bad YUV->RGB conversion with color space conversions. My understanding is that RCM works with RGB values so the values it gets are already incorrect in case of Fuji files. I could only solve this issue without re-encoding by undoing the BT.709 matrix and redoing the BT.601 matrix in a DCTL, or LUT. It can be confusing that these standards also define color spaces. (afaik early BT.601 specification didn't even have a color space definition)

In R16B or 15?
I think it's said that issues appears in R16B (or once you installed 16 and went back to 15).

I tested it in Resolve 16.

Atomos uses videos levels for ProRes but correctly maps the data range on the video range (which is never a problem for log). To interpret the video levels ProRes in Resolve as full range would be a mistake.

Mac or PC?

I've continued to test this issue, and I have more definitive data about what's not working at least on my machine. I'm referring specifically to a Resolve or Mac decoding bug for internally recorded ALL-I h265 (HEVC) movies from a Fuji X-T3.

Mainly, I've verified that a ProRes422HQ transcode in EditReady of the internal h265 footage, interpreted as Full levels in Resolve, will then display the image correctly as I would expect the h265 version to display it. This was the way Resolve 15 worked. Even when set to Full levels, the h265 is displaying forced Video levels, and is clipping shadow and highlights so they are not recoverable. Clipping is evident in the h265 regardless of how data levels are interpreted.

Is anyone else seeing this behavior, or is it peculiar to my Mac?

I've updated to Resolve Studio Beta 4 and Mojave 10.14.5. One thing I'm not clear on is if my Macbook is using the T2 chip to decode h265 and Resolve is relying on that, and if the issue lies there.

I should have tried this initially, but I did the lens cap test on HLG and F-log footage. I accept that most of the time ProRes data levels are meant to be interpreted as video levels, but for this camera the image is recorded at Full levels so in this case, the transcoded ProRes is correct when displayed at Full levels. Similarly, for the version of HLG it's recording, as per the HLG white paper, it's nominally using 0-1023, aka the Full range version of HLG.

Lens cap test with F-Log:
When I import the lens cap test to Resolve (one shot on h265 and the other transcoded to ProRes) and intrepret both as Full levels, the ProRes version comes in correctly, with the black level at 95 on the waveform as per the F-Log spec. The h265 version comes in as Video levels with black sitting at 36. If I apply a corrective Full to Legal LUT the black level then matches the ProRes version (95). The data below video levels is getting clipped in this scenario, but it's not evident in this test.

Lens cap test and photographed scene with HLG:
Black is nominally recorded at 0* in HLG but for the h265 version imported at Full Levels I'm getting clipping in the shadows even with a correctly exposed scene. As already mentioned, the image matches the contrast as if Video levels were applied. If I import the transcoded ProResHQ at Full levels, the shadow detail is there. If I apply the Full to Legal LUT to the h265, the waveform and visual contrast matches the ProRes Full levels, except the values getting clipped out are represented by a thick line showing where it's clipped.

*The actual recorded HLG min black value for the lens cap test is 32 in HLG log code values even at Full levels, but that's because in my experience with this camera, the HLG is recorded overexposed by 1 stop. Grading the exposure down by 1 stop in Resolve sets the black on the waveform very close to zero when HLG is converted to linear light (gamma 1.0). This is verified with footage of a grey card where the incident exposure was measured with a light meter. Dropping the exposure by a stop in post exposes it correctly down to around .18.

I've attached waveform screen grabs for h265 and h265 converted to ProRes, where you can clearly see the clipping in the h265 version.

h265 clipped shadows, full data levels, HLG:


h265 to ProResHQ in EditReady, Video data levels (so waveform matches), no clipped shadows, HLG:

*The actual recorded HLG min black value for the lens cap test is 32 in HLG log code values even at Full levels, but that's because in my experience with this camera, the HLG is recorded overexposed by 1 stop. Grading the exposure down by 1 stop in Resolve sets the black on the waveform very close to zero when HLG is converted to linear light (gamma 1.0). This is verified with footage of a grey card where the incident exposure was measured with a light meter. Dropping the exposure by a stop in post exposes it correctly down to around .18.

You should use video levels for HLG.

I think you keep being confused with respect to video and data levels and how they are mapped.

You should use video levels for HLG.

I think you keep being confused with respect to video and data levels and how they are mapped.

Cary, as I've demonstrated, at Full or Video levels, on my machine at least, shadow and highlight image data is being incorrectly clipped and is unrecoverable in the h265 version. It doesn't matter what's "correct" if image data is being lost. However, I know that in this case, Full data levels as represented in the transcoded ProRes version is the correct interpretation.

As per the HLG white paper, table 9 page 9, there is a full range implementation of HLG. At video levels, black is at 64, so a full range HLG black point of 32/1023 in my lens cap test is still sub-black at video levels. The grey card value is still over exposed in the video levels version and is largely corrected by dropping 1 stop, because highlights and shadows are what's getting stretched most by video vs full levels.

I believe that this exposure behavior is just a quirk of the HLG implementation in the X-T3, connected to the base ISO moving from 640 to 1000 when recording HLG, and it needs to be compensated for. I just mentioned it as an aside regarding the full range black level of 32.

I am giving up, your teacup is obviously full!

Ignoring full vs video levels, here is a crop of a h265 Full levels clip vs h265 converted to Prores at Video levels, namely so that the luminance matches at a glance. This is in R16 Studio Beta 4.

Out of camera h265 Full levels, shadow data is clipped. The image is lifted to clearly show this.

Here's the corresponding waveform:


Here is the h265 converted to ProRes beforehand, in this case displayed as Video levels to visually match the h265 and so that the waveform matches. Also lifted so that shadow detail can be clearly seen.

Here's the waveform, showing that the shadow data is not clipped on import and was recoverable by lifting in the grade.


Note that in Resolve 15, the h265 was not clipped on import, and both h265 and ProRes luminance matched when both were set to either Full or Data levels. I'm interested to know if others still have the R15 behavior in R16b.

Just checked this in Resolve 16 b5, the issue is still present. I'm also hearing from others experiencing this:

https://www.eoshd.com/comments/topic/33 ... xt3-issue/

The consensus appears to be that this is an issue with the way the T2 chip on MacBook Pros are decoding h.265, as it's apparently affecting X-T3 and GoPro footage.

As stated, my workaround has been to pre-transcode to ProRes 422 in EditReady to avoid clipping when importing into Resolve.

This clamping issue is now fixed if I disable hardware decoding of h265 files in the preferences. From memory, I did try this obvious solution months ago and it made no difference. However in the latest Mac beta (b050?) it's now working.

Obviously this is a workaround, and it means native 4k h.265 editing is probably unworkable, but I was intending to transcode on ingest to ProRes or dpx/exr frames anyway.

Okay, so apparently this is fixed in Catalina - which I have not upgrade to yet due to still using Nuke 11. My workaround for now is still to disable h.265 hardware acceleration or transcode using EditReady beforehand.