Pure White

Hey - seems like I'm loosing my mind, but there must be a setting I'm missing to render out pure white from resolve.

I've imported a 255/255/255 8bit PSD to the timline and rendered out a ProResHQ quicktime with zero changes, colour or otherwise. You can see the result below. Resolve's quicktime on the left, unedited PSD on the right (gamma has been shifted on preview image to illustrate, difference is very minor). Notice the values bottom right. Is resolve preforming some sort of clipping? Can it be turned off for digital deliveries? Any thoughts would be appreciated.

For what it's worth I've turned off broadcast safe, my timeline is Rec709 2.4 and there is no clipping curve applied. Scopes in resolve are showing pure white. Probably something simple...

Maybe PSD has layers which Resolve is mixing?
Where did you import it back? Is it Nuke? IT may not but file itself but app which reads it. Try importing file back to Resolve.
Is problem visible without any strong boosting?

yes, viewing both files back in Nuke.
No the problem isn't visible without bringing down the gamma in the viewer, but you can see the values have been adjusted from 1.00 to .99xxx

Also tried bringing file back into resolve - with the picker I get a reading of 255/255/254 and on the scopes it's coming in slightly below white.

ALSO rendering resolve's own 'solid colour' generator set to 100% white. Same result.

Just tried with a different codec, H264, same problem

Do you see the same behavior with other programs?

The reason why I ask is I'm wondering if it's an issue with RGB to YUV chroma subsampled conversion by the codec. So I'd also suggest trying an RGB codec/format and see what you get.

Peter - You're right - I tried the same thing in both Nuke and Premiere, they do something similar, but not nearly as much.

When you gamma down the resulting file from Nuke and Premiere they look closer to source but not the same. Definitely have a sub-sampling pattern as well, but seem very close to each other/near identical. I guess resolve is using a different version of codec?

I created a comparison with the same dramatic gamma boost to illustrate. All using the same PSD, rendered out with no changes to ProRes HQ quicktime

I'm wondering if somewhere along the line Resolve is rendering out an *effectively* 8 bit file, even though all of the Prores 422 codecs are nominally 10 bit; while Nuke and Premiere are rendering "true" 10 bit. That could explain why the "rounding error" in Resolve appears to be significantly greater.

If that is indeed the case, of course the next ? is why? Could it be a setting somewhere? Is Resolve seeing the source file as 8 bit, and because of that not dither to 10 bit? I honestly don't know and I'm on the road on my Windows laptop, so I can't test out Prores.

But if you want me to test out anything else, just ask.

Do you see the same behavior with other programs?

The reason why I ask is I'm wondering if it's an issue with RGB to YUV chroma subsampled conversion by the codec. So I'd also suggest trying an RGB codec/format and see what you get.

Yes, this can happen and it's "normal". You should never see it without massive "boost" though.
Resolve does look bit "strange" though.
Funny enough as it use 32bit float pipe, so should be very precise in all math I still think you should not worry about it.

This all makes sense - but I wonder, why would this conversion just not make a clean white file? Should not the Y value of 255 just be a clean 1?

So I created a white solid using Resolve's Generator effect and turning it into a compound clip (Resolve does not let you render straight generators for some reason). And in both DNxHR 444 12-bit and H.264 I see white as being 255, 255, 255 when 'Show picker RGB values' is enabled. I also tried adjust the gamma and wildly moving the curves, and I only see white, black or shades of grey. And I looked at the scopes and all I see is pure white.

So maybe this is something to do with the Mac, because I'm not seeing it here on Windows. Hope that helps a bit.

So I created a white solid using Resolve's Generator effect and turning it into a compound clip (Resolve does not let you render straight generators for some reason). And in both DNxHR 444 12-bit and H.264 I see white as being 255, 255, 255 when 'Show picker RGB values' is enabled. I also tried adjust the gamma and wildly moving the curves, and I only see white, black or shades of grey. And I looked at the scopes and all I see is pure white.

So maybe this is something to do with the Mac, because I'm not seeing it here on Windows. Hope that helps a bit.

Thanks for the test Peter - that's interesting. Perhaps it works properly on DNx? I'll give it a shot later today

I also tried H.264 and that worked properly as well.

I also tried H.264 and that worked properly as well.

Must be mac vs. pc. then. That's distressing - even though the difference is SUPER minor, it's weird there is a difference at all

So I created a white solid using Resolve's Generator effect and turning it into a compound clip (Resolve does not let you render straight generators for some reason). And in both DNxHR 444 12-bit and H.264 I see white as being 255, 255, 255 when 'Show picker RGB values' is enabled. I also tried adjust the gamma and wildly moving the curves, and I only see white, black or shades of grey. And I looked at the scopes and all I see is pure white.

So maybe this is something to do with the Mac, because I'm not seeing it here on Windows. Hope that helps a bit.

Make sure "use mac display profile" or whatever it's called is NOT checked in the settings. Then try again.

Julian, btw if you want to Dropbox the source PSD and the renders, I'll gladly take a look at them. Windows can *read* Prores.

Yeah I never have "use mac display profile" checked

And peter - send me your email and I'll share a dropbox

Done

So I was able to recreate what was happening with the PSD file on my Windows laptop; actually it was even a bit worse 255, 255, 253.

But I tried again using Resolve 14.1.1 and can't get the issue to happen again. Rendered H.264 from the PSD is 255 across the board. So it *looks* like 14.1.1 may have actually fixed whatever is going on.

Just upgraded to 14.1.1 and exact same result - still on a mac

I actually have a PC at the office that I never touch - perhaps I'll load up 14.1.1 on it today and see what's up

Just a real quick look-in regarding what might be expected re: rendering Photoshop values across broadcast codecs.

First off, wondering about the general awareness that the 8-bit values "0" and "255" are not particularly relevant in Resolve. What might be interesting would be the accuracy that mid-grey gets turned around... what most people I guess would consider "128" which is not half of 255... 127.5?

Please review the Manual, Chapter 6: Data Levels, Color Management, ACES, and HDR. Part 1 in particular.

Even "Full Range" RGB only deals with the values 4-1023 in 10-bit, and if you are converting to a codec that operates in "Video" Y',CbCr, the range is defined as 64-940. There will be some round-off errors. This might self-correct if you use an application that truncates its precision. Its equally possible that errors can be compounded if the ranging is mis-applied as gamma will also be inappropriately applied, so that not only will the black and white values miss, the grey scale will also be distorted.

Note that the values 0 and 1024 are not employed for image data, they are usually used to contain secondary data blocks. If you venture away from strictly defined simple RGB pixel arrays, jpg and so on are in effect encoding DCT coefficients, and not pure RGB values.

jPo, CSI

Try creating a new timeline or even using a new project before you switch over to the darkside (PC) lol.

Just a real quick look-in regarding what might be expected re: rendering Photoshop values across broadcast codecs.

First off, wondering about the general awareness that the 8-bit values "0" and "255" are not particularly relevant in Resolve. What might be interesting would be the accuracy that mid-grey gets turned around... what most people I guess would consider "128" which is not half of 255... 127.5?

Please review the Manual, Chapter 6: Data Levels, Color Management, ACES, and HDR. Part 1 in particular.

Even "Full Range" RGB only deals with the values 4-1023 in 10-bit, and if you are converting to a codec that operates in "Video" Y',CbCr, the range is defined as 64-940. There will be some round-off errors. This might self-correct if you use an application that truncates its precision. Its equally possible that errors can be compounded if the ranging is mis-applied as gamma will also be inappropriately applied, so that not only will the black and white values miss, the grey scale will also be distorted.

Note that the values 0 and 1024 are not employed for image data, they are usually used to contain secondary data blocks. If you venture away from strictly defined simple RGB pixel arrays, jpg and so on are in effect encoding DCT coefficients, and not pure RGB values.

jPo, CSI

JP, I totally thought that the cause was a combination full range to video scaling and RGB to YUV subsampled data loss.

But in fact, I was able to reproduce the issue in 14.1 and not in 14.1.1. So there is (or was) SOMETHING going on, albeit subtle.

Hey a quick update here:

I had a spot going today that had to deliver on pure white, and I found that rendering to ProRes 4444 did indeed give me absolute clean values. Reading 1.000 across the board in nuke. ProResHQ still gives me the slightly polluted whites.

So that's a fix, such as it is.

We performed extensive testing and narrowed down the issue to 4:2:2 codecs, specifically ProResHQ and DNxHD.

First spotted in 2015 during a series we finished - at the time we blamed it on Apple codec.
Our workaround was to exclusively use 444 codecs in Resolve, then generate the deliverables in Avid MediaComposer.

Fast forward to present day, the issue is still present in both 14.1.1 Studio and non-studio versions.

It can also be reproduced on Win systems, of course not with ProRes.
Essentially, red and blue channels are rendered with lower levels. So blacks go below zero.
The full scale is altered, blacks, mids, whites. Green does not seem to be affected. This is in comparison with original/source footage as well as with a 4444 render.

Tested with various footage: camera originals, graphic files, Resolve own test generators(bars), tested on all available versions between 11 and 14, on both Mac and PCs.

Educated guess, as already mentioned in this thread: there seems to be a flaw in the way Resolve performs the RGB to YUV calculation.

FWIW, MediaComposer on Mac and PC renders identical levels for 422 vs. 444 codecs. No level shift there.

We're prepping a support case with BMD with samples, screenshots, waveforms, etc.

cheers,
BG
www.finale.tv

Bogdan, I have no doubt that you are seeing what you are. I tested this on my Windows 10 laptop, and I can't replicate it using a new project in Resolve 14.1.1.

Here's a dropbox link to a folder with the test clip, the rendered files and a .drp of the project I used:

https://www.dropbox.com/sh/yosonknyk5v3 ... aWrua?dl=0

Peter, can you try with the attached tiff?

cheers,
BG
http://www.finale.tv

SMPTE_Bars219-2002.tif (895.58 KiB) Viewed 4486 times

I just did, and there was no color shift. For example, white is 235, 235, 235 on the SMPTE chart and it's 235, 235, 235 on the renders of DNxHD, DNxHR HQ and H.264.

I added my renders to the Dropbox folder linked to in my post above. Hope that helps a bit.

put source and rendered clip in the same timeline and watch it on your scopes, you'll see there is a difference. Can you try MXF OpAtom so we have apples for apples?

BG
www.finale.tv

After each render, I added the render to the Media Pool, selected the clip and created a new timeline.

I used show picker values on the Color Page. And saw no color shift. Attached is a screen print of what I see. My I ask, have you looked at the renders I uploaded to Dropbox in a Resolve timeline and don't see the same?

I just rendered out MXF OpAtom DNxHD, and added that render to the Dropbox folder. I cannot detect a color shift.

Here's an update. I tried using one of the DNx 10-bit codecs, and with that I do see a difference as explained in the OP. With 8-bit codec like DNxHD 115 or H.264 I see no color shift.

So if I use DNxHR HQX 10-bit I do see a color shift like described. I uploaded the HQX file to Dropbox. And below is a screen print.

Hi Peter,

I reproduced with the DNXHR HQX 10 bits (235,235,234) but with the DNXHR HQX 12 bit is OK.

SMPTE_TO_DNXHR_HQX_12bit.jpg

Is there a setting to allow Resolve's colour picker to get better than 8bit values?

So I ran a test on fresh install of resolve 14.1.1 on my MacBook at home and I'm getting interesting results.

ProRes HQ is giving me 235/235/235 on the white bar:


But ProRes 4444 is giving me 236/236/236 on the same:


However you can notice in both cases (less in the 4444) you can see with nuke's float picker that the white is slightly saturated. Also worth noting that the reading the tiff with nuke provides completely even values at 235/235/235 (0.83061522/0.83061522/0.83061522)

Is there a setting to allow Resolve's colour picker to get better than 8bit values?

You can set it to 8- or 10-bit values.

Yes, you can do so in the View menu. I believe it's like the first item, which means I usually scan right past it, lol.

Hi Peter,

I reproduced with the DNXHR HQX 10 bits (235,235,234) but with the DNXHR HQX 12 bit is OK.

SMPTE_TO_DNXHR_HQX_12bit.jpg

Thanks for testing that, and for the insight into the 12-bit version!