"Retain sub-black and super-white data" only for Y'UV?

I noticed in the 15.0 Deliver page that we now have an option for "Retain sub-black and super-white data." However, I noticed that sometimes it's grayed out--unable to be selected.

The manual on pp. 252-253 doesn't say which formats are able to take advantage of this, but in clicking around, I'm noticing a pattern: that only when Y'UV formats are selected are you able to click the box. Any RGB format makes it grayed out and unselectable.

Am I correct about this? It would make perfect sense, since the color model is different. Just curious.

RGB video is typically full range.

RGB video is typically full range.

Not what I'm asking about. Not asking about the difference between "Full" or "Video." I'm asking about the bits that are actually beyond even 4 or 1023 [for 10-bit]. In some formats you can pull that hidden data back into visible range.

RGB video is typically full range.

Not what I'm asking about. Not asking about the difference between "Full" or "Video." I'm asking about the bits that are actually beyond even 4 or 1023 [for 10-bit]. In some formats you can pull that hidden data back into visible range.

The retain sub-black and super-white option only makes sense for limited range data, not for full range data.

Checking the retain sub-black and super-white option retains this information for limited range data, not setting it means that it sub blacks and super-whites will be clipped for limited range data.

The retain sub-black and super-white option only makes sense for limited range data, not for full range data.

Checking the retain sub-black and super-white option retains this information for limited range data, not setting it means that it sub blacks and super-whites will be clipped for limited range data.

The convention is typically for Y'UV formats to be at Video while RGB are at Full. However, there are instances in which you'd want to preserve data far outside of even the Full range.

For instance, the Y'UV 4:2:2 capture codec XF-AVC in the C300 Mk II captures all sorts of detail way into the sub-black and super-white, even when shooting in CLog2. If you wanted to pass that footage onto a different colorist with a pre-conformed flattened media file workflow, you wouldn't just want to clip all that information out. You'd want to either choose a format that could preserve that data, or you'd pull everything back into range, like with Lift and/or Gain.

For instance, the Y'UV 4:2:2 capture codec XF-AVC in the C300 Mk II captures all sorts of detail way into the sub-black and super-white, even when shooting in CLog2.

That is absolutely untrue, Canon log is recorded with data levels. Interpreting Canon log footage with video levels is a mistake.

But the author said it's full levels, not video.

But the author said it's full levels, not video.

Right, so there won't be any sub-black or super-white code values and there won't be any clipping.

There will be super white/super black values and this is exactly why you need to treat this file as full range.
Super black/white is nothing more than data outside YUV standard defined black/white (64, 940 for 10bit). Such a file becomes full range and fact that it's YUV is not big deal here. There is nothing wrong with full range YUV file as long as it's clearly specified somewhere (in container/codec headers etc).

We can talk semantics until we are green but the fact is that the sub-blacks and super-whites checkbox is not relevant for full range video.

In earlier releases of Resolve, most codecs in the delivery page clipped the sub-blacks and super-whites when the output was defined as video levels (H.264 was one of the exceptions). Adding the checkbox left the user the option to either clip or retain those values.

That's the meaning of that checkbox.

Cary, I think you might be confusing two things: (1) having sub-black and super-white data with (2) having levels set to Full. These are two different things. As Andrew mentioned, some formats can have data way outside the code values of even Full levels.

You can see this yourself. Take a well-balanced source clip, and take the Offset and pull it way up or way down to deliberately clip it. Render it into a format and have the "preserve sub-black and super-white" checkbox checked. Then pull it back into Resolve and pull the data back with the Offset. You'll see that there is data stored in there that you can retrieve.

We can talk semantics until we are green but the fact is that the sub-blacks and super-whites checkbox is not relevant for full range video.

In earlier releases of Resolve, most codecs in the delivery page clipped the sub-blacks and super-whites when the output was defined as video levels (H.264 was one of the exceptions). Adding the checkbox left the user the option to either clip or retain those values.

That's the meaning of that checkbox.

Yes and it only applies to YUV based codecs (well, some of them).
User just have to be carful as unfortunately most codecs/containers can't flag that file is YUV, but full range, which can cause small issues if you rely on flagging/auto interpretation further in the production chain.

DNxHR has flagging for range and Resolve properly reads/sets video vs. full range (which is not the case for ProRes).

Cary, I think you might be confusing two things: (1) having sub-black and super-white data with (2) having levels set to Full. These are two different things. As Andrew mentioned, some formats can have data way outside the code values of even Full levels.

You can see this yourself. Take a well-balanced source clip, and take the Offset and pull it way up or way down to deliberately clip it. Render it into a format and have the "preserve sub-black and super-white" checkbox checked. Then pull it back into Resolve and pull the data back with the Offset. You'll see that there is data stored in there that you can retrieve.

Beyond 109 IRE?
That would be news to me, I want to see that.
With which codec did you try this?

Cary, I think you might be confusing two things: (1) having sub-black and super-white data with (2) having levels set to Full. These are two different things. As Andrew mentioned, some formats can have data way outside the code values of even Full levels.

There is no data outside the code values of full range video, 0-1023.
Sub-black and super-white only exist in video range, 64-940, between 0-64 and 940-1023.
0-1023 is the absolute total range available. There is nothing outside this range.

It's worth reading about the history of sub-black/super-white from it's analogue origins to see how it was affected by digital video standards.

Somehow the data is represented. Try it yourself. I used DNxHD 175.


Sent from my iPhone using Tapatalk

Beyond 109 IRE?
That would be news to me, I want to see that.
With which codec did you try this?

IRE is such a outdated terminology which has really no place in current digital world (related to old analog composite signal). I don't know what purpose does it serve in Resolve- basically none.
You should use current terminology.

There is no data outside the code values of full range video, 0-1023.

True for video, but I just want to point out that for anyone that needs to render some intermediate file outside that range without clipping, you can use DPX RGB half float or EXR RGB half. Resolve doesn't clip those files (at least I've never hit the clipping point, but I'm sure you can if you try).

You should also not use preserve super white/black when doing YUV masters for broadcast.

Somehow the data is represented. Try it yourself. I used DNxHD 175.
Sent from my iPhone using Tapatalk

DNxHD 175 is video range 64-940. That's why. Use a full range codec and try again.

Somehow the data is represented. Try it yourself. I used DNxHD 175.

In case you didn't already know, when the scopes in Resolve shows data above 1024 on a YUV file with video data level and super whites, it's been scaled correctly so 64-940 is displayed as 0-1023. That's why there's some headroom left above 1024 and below 0.

Amen.

Any log encoding can encode image data values way beyond the normalized 0.0-1.0 range. But actual values in file are still within the range of possible values for integer storage. To get out of integer storage box, use float format like exr as Roger wrote. Half float exr has 5 bits for exponent and 10 for mantissa, giving 32 effective "stops" with each stop having 10 bit precision. And all that to both positive and negative values (one bit for sign).

Somehow the data is represented. Try it yourself. I used DNxHD 175.
Sent from my iPhone using Tapatalk

DNxHD 175 is video range 64-940. That's why. Use a full range codec and try again.

Isn't this just restating my question?

If the convention is for Y'UV codecs to be at Video levels, and RGB codecs to be at Full levels, then how would I even select an RGB codec to try? The checkbox is not able to be selected.

Somehow the data is represented. Try it yourself. I used DNxHD 175.
Sent from my iPhone using Tapatalk

DNxHD 175 is video range 64-940. That's why. Use a full range codec and try again.

Isn't this just restating my question?

If the convention is for Y'UV codecs to be at Video levels, and RGB codecs to be at Full levels, then how would I even select an RGB codec to try? The checkbox is not able to be selected.

I just tested this Seth and all that is retained are the sub-black and super-white code values, i.e. 0-63 and 940-1023. Nothing is retained above or below that.

I just tested this Seth and all that is retained are the sub-black and super-white code values, i.e. 0-63 and 940-1023. Nothing is retained above or below that.

OK, I just tried it again as well, and I can indeed retrieve some information, but perhaps not as much as I stated earlier. I do indeed see some clipping.

I'm still a little confused though, because it doesn't seem like it's 1:1. In other words, if I use Offset and pull the data way up, render the clip, pull it back in, and then pull it back down with Offset, it's seems like I can get back more than 7% of the visible scale [64/896]. I can get about 10% of the scale back.

Are those super-white and sub-blacks somehow scaled differently than the visible parts of the image?

Maybe the more important question is: what is this feature for? How would this practically enhance your workflow? Since BMD took the time to add the feature, who is the kind of user that requested this, and why?

Maybe the more important question is:[/b] what is this feature for? How would this practically enhance your workflow? Since BMD took the time to add the feature, but who is the kind of user that requested this, and why?

The problem is that in earlier versions sub-blacks and super-whites code values for video level videos were automatically clipped, the notable exception being H.264.

Now obviously for delivery you generally do not want to have sub-blacks and super-whites but there may be reasons you would want to retain those values. For instance for mezzanine codecs, transcoding or archiving.

Some cameras record super-whites as a form of overflow, transcoding these with clipping will remove important values that could have been brought back to legal values in post.

Even adding a simple SMPTE bar will have the sub-black pluge clipped for video levels if this checkbox is not enabled.

Some cameras record super-whites as a form of overflow, transcoding these with clipping will remove important values that could have been brought back to legal values in post.

Right on. So glad this option was added.

Some cameras record super-whites as a form of overflow, transcoding these with clipping will remove important values that could have been brought back to legal values in post.

Right on. So glad this option was added.

But what does this have to do with your own ability to transcode a clip while preserving the sub-blacks and super-whites? When are you grading something without having access to the camera originals?

Some cameras record super-whites as a form of overflow, transcoding these with clipping will remove important values that could have been brought back to legal values in post.

Right on. So glad this option was added.

But what does this have to do with your own ability to transcode a clip while preserving the sub-blacks and super-whites? When are you grading something without having access to the camera originals?

Practical example: Say you have a camera file that contains super-whites and uses long GOP data. You want to transcode this data for performance reasons, now when you transcode wouldn't you want to retain the super-whites?

So, encode 8 Bit stuff into a 10 bit codec and call it a day.

So, encode 8 Bit stuff into a 10 bit codec and call it a day.

That would actually not solve the problem of clipping if the checkbox is not set!

Don’t the formats marked “HDR” for Optimized Media or Cache retain the sub-blacks and super-whites? You could just cache to one of those, no?


Sent from my iPhone using Tapatalk

Just tell Resolve that your incoming footage is full range and it’ll take care of the rest.

(from memory, the Retain checkbox sub-black and super-white data has been added for roundtrip from / to)

I just did a test with a clip:

Clip Input: Color range: Full

Code: Select all

Video
ID: 1
Format: HEVC
Format / Info: High Efficiency Video Coding
Profile format: Main @ L5.1 @ Main
Codec ID: hvc1
Codec ID / Info: High Efficiency Video Coding
Duration: 13s 280 ms
Bit rate: 62.2 Mb / s
Width: 3,840 pixels
Height: 2,160 pixels
Display aspect ratio: 16/9
Frame rate mode: Constant
Frame rate: 50,000 Im / s
Color space: YUV
Chroma subsampling: 4: 2: 0
Bit depth: 8 bits
Bits / (Pixel * Frame): 0.150
Stream size: 98.5 MB (100%)
Title: GoPro H.265
Language: English
Encoded date: UTC 2017-10-30 21:15:44
Tagged date: UTC 2017-10-30 21:15:44
Color range: Full
Color primaries: BT.709
Transfer characteristics: BT.709
Matrix coefficients: BT.709


If Clip Attribute => Data levels is not Full: I have flickering.
I checked and placed the clip on a YRGB REC.709 Gamma 2.4 Project Settings (default) @1080p 50fps

Delivery:
Format: QT
Codec: DNxHR HQX 12-Bit
Advanced:
Data levels = Auto (important)
Retain sub-black and super white data = ON

I reimported the generated clip and placed on the original TL
The original clip (color range full) is "cropped" right 960
The generated clip is "cropped" left 960

In the color => CTRL + F tab
I do not see any difference:

sub-black and super-white data.jpg

Color space: YUV

Code: Select all

Video
ID: 1
Format: VC-3
Commercial name: DNxHR HQX
Version Format: Version 3
Profile format: RI @ HQX
Codec ID: AVdh
Codec ID / Info: Avid DNxHR
Duration: 13s 280 ms
Bit rate mode: Constant
Bit rate: 367 Mb / s
Width: 1,920 pixels
Height: 1,080 pixels
Display aspect ratio: 16/9
Frame rate mode: Constant
Frame rate: 50,000 Im / s
Color space: YUV
Chroma subsampling: 4: 2: 2
Bit depth: 12 bits
Scan type: Progressive
Bits / (Pixel * Frame): 3.540
Stream size: 581 MB (100%)
Language: English
Color primaries: BT.709
Transfer characteristics: BT.709
Matrix coefficients: BT.709


(from memory, the Retain checkbox sub-black and super-white data has been added for roundtrip from / to)

If you're sending a shot out to VFX, and the camera original was in a Y'UV capture codec with information in the super-white and sub-blacks, I guess it could make sense to keep it in Y'UV when you pop out the DI format--something like DNxHR HQX or ProRes 422 HQ.

I guess I'm just curious because typically I think of VFX getting either the camera originals or a Full range RGB codec like ProRes 4444 XQ or DNxHR 444.

I would also like VFX assets be rather RGB based (if not original camera format), not YUV. This is only possible with DNxHR or Cineform, not with ProRes.

I would also like VFX assets be rather RGB based (if not original camera format), not YUV. This is only possible with DNxHR or Cineform, not with ProRes.

ProRes 4444 and ProRes 4444 XQ can be RGB-encoded.

If you mean 444 then yes, but actual data is encoded as YUV, not RGB. In case if DNxHR or Cineform it's encoded as RGB.
Look at my thread about ProRes444 and RGB. If you have ProRes sample which is RGB encoded then I'm happy to see it.
ProRes444 is still YUV encoded in Resolve and you even have option to preserve super white/black which is option only for YUV based codecs.
I'm waiting for confirmation but looks like there is no RGB switch in ProRes SDK, so Apple's wording in their papers is bit misleading. All ProRes files seems to be encoded as YUV data.

Can you link me to your thread?

My understanding is that Apple is a bit opaque about how everything's working into and out of the codec--that ProRes 4444 is a bit of a black box: https://www.liftgammagain.com/forum/ind ... -rgb.8990/

In practice, given that there's no chroma subsampling going on, I don't know if the particular color model even matters. What is the workflow wrinkle with not being able to specify one or the other?

Yes, this thread is the same story (also conclusion).
When you want to use ProRes444 as high quality working format (for VFX etc) you want to stay all the way in RGB.
With current Resolve every export to ProRes444 does keep 444 chroma, but it gets (in 95%) converted to YUV before it gets actually encoded inside ProRes. Then when you import your ProRes internal, YUV encoded data is converted back to RGB, so at this moment we already have two YUV<->RGB conversions. Apparently this is never lossless and also costs you CPU cycles. You also (in both cases) have chance for bad conversion (wrong color matrix). If you analyse whole post-production chain you end up with many such a conversions.
In case of RGB encoded data (DNxHR, Cineform, DPX etc) you have 100% 1:1 pipe. Resolve calculated data goes to codec as RGB, gets encoded as RGB, then gets decoded back to RGB and goes to GPU for new calculations. Going YUV<->RGB is nothing desired at all. High-end finish, grading, compositing should be done in RGB and then you make broadcast master, which should be YUV based. From this moment you should also stay within YUV (this is why Resolve is not a good choice for "broadcast transcoder" as it always goes over RGB), so any conversion from eg. ProRes to h264, h265, XDCAM etc should be done over YUV pipe, not going through RGB yet again. Maybe ideally we would like to stay in RGB always, but this doesn't compress well, so we have YUV which is used in end delivery formats. Fact that Resolve offer setting for super white/black suggest Yup encoded data as well (as the option has no meaning and it's greyed out for RGB based codecs).

viewtopic.php?f=21&t=78257

Apple white paper says:
"It also offers direct encoding of, and decoding to, both RGB and Y’CBCR pixel formats."

but this seems to mean- we can take on encoder internal input RGB based pixel format, encoded and decode later to RGB base pixel format. There is no guarantee (which also few people confirmed to me, including Cineform developer) that internal encoding is done as RGB. So far conclusion is that ProRes (regardless if it's 444 mode) is always encoded as YUV. Resolve option for ProRes444 to keep super white/black is another proof that it's not RGB encoded. I'm looking for a proof that there is RGB based mode also.

Example:
Take v210 (10bit 4:2:2 YUV uncompressed) file and export it back in v210 in Resolve. Now compare them with difference filter (and boosting with curves etc) and with PSNR filter in ffmpeg, They should be 100% the same, but they won't be, because in Resolve v210 when through RGB. PSNR is at about 65dB, with is high, but in the same not that crazy high (DNG RAW 3:1 is at about this level). You see that going YUV<->RGB is not so lossless and desired (if not needed), even if Resolve is working in 32bit float math.
Do the same with ffmpeg or other transcoder which doesn't force RGB pipe and they will be 100% the same as conversion stays in YUV (and we're going to uncompressed format). This is not end of the world (and can't be really avoided in app like Resolve), but it means Resolve is not the best choice as a "generic transcoder" for YUV based formats, which I already pointed out some time ago.

Believe you me, I love optimizing for every little nitty gritty detail in the pipeline, but I really don’t understand what practical performance penalty you’re perceiving with ProRes 4444 in the real world, with regard to either CPU cycles, or color fidelity from fewer decimal points and RGB to YCbCr conversions.

However the data is being stored in 4444 or 4444 XQ, it’s certainly visually lossless. Can you show me an example of an RGB source that looks different when transcoded into ProRes 4444 on a calibrated reference monitor?

Alex Bickel over at Color Collective seemed just fine grading ProRes 4444 from an Arri for Moonlight. If a ProRes 4444 movie can win Best Picture, it’s good enough for me.


Sent from my iPhone using Tapatalk

With eye you definitely won't see it. It's not about this.
Technicality doesn't win Best Picture, so this is not a valid argument for me.

Also- just for fun tried 5 generations going v210 to v210 in Resolve. And we down with PSNR to 51dB for U channel. This is on level of ProResHQ compression itself (more than ProResXQ introduces itself), so I think this is actually quite a big loss! Also- 5 generations for a post-pipe is not that big number, just few different apps and imports/exports. Remember we are going over uncompressed format, so it should be 100% the same even after eg. 1000 generations

More fun: 10 generations and PSNR on U channel is down to 46dB. This is low as for just loss from YUV<->RGB conversions. I can actually easily see difference at 2x zoom by naked eye.
I need to test this with other tool, as Resolve seems to performing quite poor. Not sure if such a big loss should actually happen.