DVD Rebuilder PRO and ColorMatrix

[AGKnotUser]

I read the following in the ColorMatrix thread http://forum.doom9.org/showthread.php?t=82217: "mpeg2 clips encoded by TMPGEnc/CCE using AviSynth or VirtualDub are displayed with slighty off colors"

Is this true? Should I be using ColorMatrix the get the colors "right"?

If true, is this the way to use it?

Put "c:ColorMatrix(hints=true, opt=0)" in AVS Filter Editor.

Put "MPEG2SOURCE_OPTS=info=3" in Rebuilder.ini file under options.

[kumi]

I use
C:P:ColorMatrix(dest=0, hints=true)
C:I:ColorMatrix(dest=0, hints=true, interlaced=true)

(requires version 2.2 of the plugin.)

[AGKnotUser]

I use
C:P:ColorMatrix(dest=0, hints=true)
C:I:ColorMatrix(dest=0, hints=true, interlaced=true)

(requires version 2.2 of the plugin.)

Thanks for your response.
What does the C:, P:, I: mean? Where is it documented?

[JohnGalt]

From the Changelogs:


- Added a new feature for prefix recognition to the filter
processor. These are meant to help descriminate on the
usage of filters. Now you can add "E:", "F:", "I:", or
"P:" as a prefix to a line added in the filter editor.
The prefixes represent "Extras", "Feature", "Interlaced",
and "Progressive" respectively. When specified, the prefix
will limit that filter to usage only when the source to be
encoded matches the prefix. For example, if specifying
"E:filter1()" the filter "filter1()" would only be applied
to segments that are determined to be extras. Setting
"e:i:filter2()" limits use of "filter2()" to segments that
are extras -- and are also interlaced. (v1.20.4)


- Added an additional filter prefix "C:". If the "C:" is
present as a prefix in the filter line, the line will be
added only when the colorimetry of any part of the
original source is anything other than Rec.709.

- Added an additional "M:" filter prefix. If the "M:" is
present the filter line will only be added when
a segment associated with a menu.

- Changed algorithm so that filters are now also applied to
menus. Please note, though, that filters using the "E:"
or "F:" prefix will (naturally) not be applied to menus.

[AGKnotUser]

Thanks so much. It's all clear now.

[AGKnotUser]

In fact, I liked what you have suggested and what I saw in another post so I combined the two and added something I saw in the documentatoin and came up with this:

C:P:ColorMatrix(dest=0, hints=true, opt=0, threads=0)
C:I:ColorMatrix(dest=0, hints=true, opt=0, interlaced=true, threads=0)

[jdobbs]

This is what I use:

c:LoadPlugin("c:\program files\AviSynth 2.5\plugins\colormatrix.dll")
c:i:ColorMatrix(mode="Rec.601->Rec.709",interlaced=true)
c:p:ColorMatrix(mode="Rec.601->Rec.709")The "hints=true" isn't effective in your example unless you also add this to the "[Options]" area of the REBUILDER.INI (to enable hints) as AGKnotUser suggested:

MPEG2SOURCE_OPTS=info=3

[Boulder]

In fact, I liked what you have suggested and what I saw in another post so I combined the two and added something I saw in the documentatoin and came up with this:

C:P:ColorMatrix(dest=0, hints=true, opt=0, threads=0)
C:I:ColorMatrix(dest=0, hints=true, opt=0, interlaced=true, threads=0)I wouldn't use opt=0. It'll slow the filter down unnecessarily, the difference between the outputs of C and MMX/SSE versions won't be visible.

From the documentation: "The maximum difference between the simd and c routines is +-1 on the Y/U/V planes".

[AGKnotUser]

You're right. There is a big difference in speed. I'll use what you suggested. Thanks jdobbs and Boulder.

[JohnGalt]

Should this ColorMatrix stuff perhaps be a default value in DVD-RB then? Or perhaps a checkable item in one of the menus?

[jdobbs]

1. I try to avoid adding requirements for external filters.

2. For most main-movies the filter isn't even used (they are already Rec.709). It's more common in menus and series, though.

3. The difference isn't especially noticable IMHO. It's a "I want perfection" kind of thing. Although I must admit I personally leave it enabled all the time.

But, I'll look at the license for ColorMatrix() and see if there are any restrictions that might prevent distributing it with DVD-RB (above the GNU Public License). At the very least I'd have to keep the source downloadable on my website for a couple of years, even with the GNU license.

[Boulder]

If you do end up adding ColorMatrix as an item in the menu, I advise using the d2v option instead of hints. It'll be a tiny bit faster that way.

[JohnGalt]

Ah, I see. Well, I've used DVD-RB for years without the ColorMatrix filter, and I've never noticed any color problems, so I'm quite happy to carry on business as usual. But if ColorMatrix's license permits it and you're willing to support it, well, perfection seems like a laudable goal. :)

[Wilbert]

But, I'll look at the license for ColorMatrix() and see if there are any restrictions that might prevent distributing it with DVD-RB (above the GNU Public License). At the very least I'd have to keep the source downloadable on my website for a couple of years, even with the GNU license.
Added a link to the source (tritical's site) is fine with me :)

[jdobbs]

Much appreciated, Wilbert. :)

[AGKnotUser]

If you include it can you fine tune the options as you like. For instance, I use "threads=0" to take advantage of a dual core speed up.

[fjhdavid]

just to understand:

I have a PAL DVD coded with 601 coeff (checked with DGindex, in fact it is a DVD recorded from a Satellite box with a DVD recorder)).

I use the following avisynth filters (to corect a red shift):

ConvertToRGB()
RGBAdjust(1,1,1,1,-3.3,0,0,0,1,1,1,1)
ConvertToYUY2()

Then I frameserve to CCE.

Then I will read the recoded DVD with my DVD player oppodigital hd981

Question1: Do I have to use colormatrix? where in the script (at the beginning, just before the end) and how?
Question 2: May I use, instead, convertToYUY2(matrix=709) ?


thanks
Francois

[Pulp Catalyst]

would be cool if ColorMatrix was added as the norm, many Appz use this now as default, and now it can be dual cored, comes highly recommended from many who i know that do a lot of there films,

and a option in DVDRebuilder would be great aswell, as this is one of those filters that can pretty much be left on all the time,
and i've never read anything saying that it actually hurts, may not make a difference, but never hurts the image either,

[manono]

would be cool if ColorMatrix was added as the norm
Why, since most of the time it's not needed? All it'll do is slow the encoding in the majority of cases, since nothing has to be done.

[Boulder]

Why, since most of the time it's not needed? All it'll do is slow the encoding in the majority of cases, since nothing has to be done.If the d2v option is used, it will only cause an unnoticable slowdown when the script is loaded in the encoder. ColorMatrix will parse the d2v file and check whether it is needed or not. The actual encoding process is not affected if ColorMatrix is not applied.

[manono]

If the d2v option is used...
Meaning with info=3 and hints applied? Admittedly I haven't used it when it wasn't needed. However, I have noticed that with the hints option it's much slower than just using ColorMatrix without hints. So I figured that it was somehow checking each frame to see if it was needed, while the encoding was taking place, and if not, that check still significantly slowed the encoding. I find it a little difficult to believe that it can check 150,000-200,000 frames more or less instantly upon loading the script into the encoder.

But there's a good chance I'm not understanding what's going on with it. Or maybe something's changed since my version 1.9 from 2005.

[Boulder]

Hints are not needed when the d2v option is used in ColorMatrix. It says in the ColorMatrix thread that the whole d2v is parsed at one go so it doesn't check frame by frame while the encoding proceeds (I myself asked that question ;))

I haven't done any testing but will do so tonight to see the difference between "no ColorMatrix", "CM with the d2v option" and "CM with hints".

[Boulder]

Here are the results of a little test, 5000 frames encoded with HC, two-pass VBR.

no ColorMatrix 318.84s
d2v=true, clamp=false, no-op 317.97s *)
hints=true, clamp=false no-op 326.52s *)
hints=true, clamp=false 338.05s
d2v=true, clamp=false 331.56s
regular CM, no d2v or hints 331.92s

*) no-op means that ColorMatrix didn't have to do anything, the source and destination colorimetries were the same.

These results tell that the choice between hints and d2v option does make a difference. It should be kept in mind that I only did one test encode so the results might have been a bit different had I done multiple ones. Still, I'd say that using d2v is better than hints, but it is currently not possible in DVD-RB.

[jdobbs]

If you use the C: prefix on the filter line, as I did in my example, then the filter is only included in the AVS when it is needed (when the source is not already Rec.709). I think that gives you at least as much flexibility and speed as the D2V option.

[manono]

Here are the results of a little test...
Before coming back to this thread, I also did some testing, and came up with results similar to yours. At first, forgetting to update my ColorMatrix, I encoded a chapter from LOTR-ROTK (5:49). It's already in BT.709, and didn't need ColorMatrix. Using ColorMatrix with hints applied, it took 64 seconds. Removing ColorMatrix entirely, it took only 40 seconds. Then I remembered about checking for a new version, found Ver.2.2 and tried again using the same 2 scripts:

LoadPlugin("D:\AviSynth Stuff\Dlls\DGDecode.dll")
LoadPlugin("D:\AviSynth Stuff\Dlls\ColorMatrix.dll")
MPEG2Source("E:\Test1\Test1.d2v",Info=3)
Colormatrix (mode="Rec.601->Rec.709",Hints=true)
ConvertToYUY2()

And:

LoadPlugin("D:\AviSynth Stuff\Dlls\DGDecode.dll")
MPEG2Source("E:\Test1\Test1.d2v")
ConvertToYUY2()

Exact same results. It caught my eye that the MPV produced by the ColorMatrix script was considerably smaller sized than the one that didn't use ColorMatrix at all, and I dove into the doc to find the reason. And it was the Clamp parameter. I guess you already knew about that one, but it was news to me. Setting Clamp=False gave me the same encoding times (40 seconds) and same file sizes.

Then I took a couple of chapters from a Star Wars DVD which uses SMPTE 170M, and really does need the filter, and repeated the tests. The results were similar, but not identical. With Clamp on, it took longer and the file size was smaller, but the differences weren't as great as the earlier tests which didn't need the filter. It stands to reason, I guess, since this time the filter was actually doing something.

Then I came back here and learned what the D2V setting was from you, read about it in the doc, and tried it out. My samples were small enough that the times didn't seem to improve over using hints instead. Or something.

I tried the Threads=2 setting for my Core2 Duo and it only slowed me down. I tried SetMTMode(2) in the multithreaded version of AviSynth, and it only slowed me down.

So, I learned some things, the main one being that Clamp has to be set to False. Why it's on by default I don't understand, as I haven't ever seen any DVDs that weren't 0-255.

I apologize to Pulp Catalyst for contradicting him. And thanks, Boulder, for running the tests which confirm the same things I found a bit later, and for mentioning the D2V option. And for DVD-RB, jdobbs' method is probably the way to go (with Clamp=False also added in)

[jdobbs]

Hmmm... I think I need to read up on the "clamp=false" parameter.

[Boulder]

DVDs should be restricted to the TV scale, that is 16-235/16-240 (luma/chroma). Clamp simply calls Limiter() which clamps anything above/below those boundaries to 16 or 235/240. I don't use clamping in ColorMatrix but I do use Limiter() as the last call in my scripts.

The "show" option in Limiter can be used to easily see what pixels are outside the boundaries.

[jdobbs]

Cool. Thanks.

[manono]

DVDs should be restricted to the TV scale, that is 16-235/16-240 (luma/chroma).
Why, since, as I said, I have yet to see a commercial DVD that uses anything other than 0-255.
The DVD is encoded in digital values from 1-254. Reference black is encoded at digital 16, with nominal reference white at 235. Codes 0 and 255 are illegal for image data. Codes 1-15 represent data that is below reference black, hence it is called blacker-than-black (BTB). Codes 236-254 are peak whites. I will refrain from calling them ‘whiter than white’ because this implies that they shouldn’t normally be present or visible in the final picture. They should be, unlike BTB(BTB should not regularly be visible in the final calibrated image)! It is important to maintain the full range of encoded data through your video chain for the best image. (emphasis mine-manono) When the digital image data is converted into an analog waveform at an analog output, only then does IRE enter the picture. BTB data will simply fall below whatever the IRE output level for black is. In a system that outputs black at 7.5 IRE, BTB data will be output at voltages slightly below 7.5 IRE. In a system that outputs black at 0 IRE, BTB data will be output at voltages slightly below 0mV (simply negative volts). If you’ve digested that correctly, you realize that BTB data can be maintained in BOTH situations.
http://www.avsforum.com/avs-vb/showthread.php?t=494606
The range of levels from 16 - 235 is where the bulk of the picture information is placed. The extra 34 levels are there for head and room toe room. Real world images contain scattered blacks (Levels 1-15) and whites (Levels 236-254).

We believe that a digital representation of a 'natural' image requires a signal range beyond the nominal 'black' and 'white' points to look 'natural'. (emphasis mine-manono)
http://www.hometheaterhifi.com/volume_10_1/dvd-benchmark-guide-to-progressive-scan-shootout-1-2003.html

(The "Blacker-Than-Black section about 3/4 of the way down) If you'd like to confirm for yourself what retail DVDs use, just add "ColorYUV(Analyze=True)" to the bottom of a script (without clamping or limiting) and scroll around.
http://i163.photobucket.com/albums/t308/Tommydan1/DVDPics/StarWars.jpg
LoadPlugin("D:\AviSynth Stuff\Dlls\DGDecode.dll")
MPEG2Source("E:\Star Wars\StarWars.d2v")
LanczosResize(624,352)
ColorYUV(Analyze=True)

[Video Dude]

Would clamp=false preserve the values from the original DVD?

So the minimum 6 in the frame would remain a 6?

[Boulder]

Yes, clamp=false means no limiting is done.

I did ask about this under 16, over 235/240 values in the ColorMatrix thread some time ago. Looking at the pixels shown by Limiter with show=true, it seems that these pixels are quite rare. It would be nice if manono could check that frame unresized and with Limiter showing where the values outside the TV scale boundaries are :)

[Boulder]

Read from this page on: http://forum.doom9.org/showthread.php?t=82217&page=3 . The images I uploaded are long gone though, but the discussion is interesting. Maybe Wilbert should be asked to respond to this thread as well.

[manono]

I didn't see much of interest in that page, unless I missed it. Except for the part about CCE. But doesn't CCE assume Rec.709, whether or not it adds it to the header? And if the source is something other than Rec.709, don't you want to use the filter if encoding with CCE? You get more saturated, or higher contrast, or more garish colors if you don't.

Anyway:
http://i163.photobucket.com/albums/t308/Tommydan1/DVDPics/ShowLuma.jpg
I resized it earlier to keep the size down and to put it in proper AR. I assume the red dots are blacks formerly below 16, and the green dots are whites formerly above 235.
ColorMatrix(D2V="E:\Star Wars\StarWars.d2v",Clamp=False)
#LanczosResize(624,352)
Limiter(Show="Luma")
ColorYUV(Analyze=True)

[Boulder]

What about the original frame, that is, without ColorMatrix? When I tried checking many dark scenes, I found much less areas below 16.

[manono]

Hi-

The original frame without ColorMatrix is, as near as I can tell, identical to the pic above. This time, rather than clog up this thread with a pic, I'll just link it:

http://i163.photobucket.com/albums/t308/Tommydan1/DVDPics/ShowLumaNoColorMatrix.jpg

MPEG2Source("E:\Star Wars\StarWars.d2v")
Limiter(Show="Luma")
ColorYUV(Analyze=True)

And those 2 chapters, most of which are pretty dark, have many frames where it seems the majority of the frame (inside the black borders) consists of red dots:

http://i163.photobucket.com/albums/t308/Tommydan1/DVDPics/ShowLumaNoColorMatrixPlentyDots.jpg

These are from the R1 The Empire Strikes Back. Maybe it's something peculiar to these DVDs, I don't know.

[Boulder]

I asked Wilbert if he could respond to this thread, maybe he has some ideas. I'll also try a couple of DVDs that I have on my HD as soon as I get home. It could be that the Star Wars DVDs contain more information in the 0-255 range thanks to Mr. Lucas's efforts in "digital enhancing".

[Wilbert]

I will refrain from calling them ‘whiter than white’ because this implies that they shouldn’t normally be present or visible in the final picture. They should be, unlike BTB(BTB should not regularly be visible in the final calibrated image)! It is important to maintain the full range of encoded data through your video chain for the best image. (emphasis mine-manono)
I've not much useful to add. I just disagree with the bolded conclusion.

I think we all agree that, usually (if the dvd is created "properly"):
Reference black is encoded at digital 16, with nominal reference white at 235.
Now, there are two possibilities:
1) There is nothing useful outside [16,235], and hence the conversion: clamping and YCbCr [16,235] -> RGB [0,255] is recommended.
2) There is something useful outside [16,235] (let's assume the useful info is located in [8,250], but that will be different for each dvd). If you want this to be visible in your final encoding, you should stretch differently: YCbCr [8,250] -> RGB [0,255] (or keep the full range as they suggest). The drawback is that black is not at RGB=(0,0,0) and white is not at RGB=(255,255,255) anymore. Whether you can live with this is subjective, but for me it's not desirable.

Unlike DV, i'm not aware of DVDs which contain sometimes useful outside [16,235]. (Well, a few years ago i was given one sample of an anime DVD which was encoded at YCbCr [0,255]. But in that sample, black was at located at 0 and white at 255, so i guess the encoding was done incorrectly.)


So, for all the "clamp=false" fans, i would say, show me an example were useful information is located outside YCbCr [16,235] :) That should settle the discussion.

[manono]

Hi-
I just disagree with the bolded conclusion.
There's no reason you should know those people that post at the AVS Forums. But they're not amateur enthusiasts like us (well, me anyway). These guys are the leaders in the industry. When they speak, it's the truth. The data outside of 16-235 in a properly mastered DVD is there for a reason. Chris Wiggles sums up the reasons why:
Mastering fudge room
Highlight details and undershoot
Minimizing analog waveform anomalies at D/A converters
Compensation for the inability of CRTs to clamp black levels perfectly
Determining dithering patterns on DLPs
Any image processing applied
That's in the first post of the same thread from which I quoted earlier:

http://www.avsforum.com/avs-vb/showthread.php?t=494606

And farther down the page, in post #12, Bob Pariseau explains what can happen if you clip off the data below 16:
But the most common symptom that people see when BTB is clipped is "black crush" to varying degrees. This is a feeling that low black detail is being lost no matter how careful you are at trying to set black levels properly. This is due to two things. First, if the black levels on your TV float up and down depending on what's being displayed (usually based on the average brightness of the image) then when the BTB range temporarily floats up to become visible there's no detail there -- it's all been rounded to one value. Second, if the image processing in your TV is sensitive to (i.e., depends upon or takes advantage of) the BTB data, then near-black details ABOVE "Black" may get incorrectly rounded to the same level, and/or the absolute "Black" level may get rounded up a bit yielding dark gray instead of black on screen.

So the most common reported symptom associated with improper clipping of BTB data is loss of detail in low light scenes on various DVDs. Usually if you've got this problem, it will be seen in most ALL of your DVDs that feature detail-rich, low light scenes.

Now "black crush" can come from other errors in processing and calibration than just improper clipping of Blacker than Black data. But if you've got visible "black crush", checking for proper passing of BTB data is one of the first things to do.

The second most common symptom of BTB clipping is "noise" in low light level scenes. Again this is due to signal processing that happens after the BTB data is clipped. But in this case, instead of improperly rounding true detail to the same level (thus blurring the detail), random variations are introduced in that detail. Think of it as a type of "ringing" as the signal processing tries to deal with the fact that the light sampling has a sharp cutoff at "Black" -- something that wouldn't occur in "real" images.
http://www.avsforum.com/avs-vb/showpost.php?p=4997915&postcount=12

Near the bottom of the page, Chris quotes Stacy Spears from a different thread:
Similarly, I can and do demonstrate that clipping at 16 and 235 is visible. It's not just a little bit visible, it's awful. Your white detail goes all to hell. Clouds look like white plastic cutouts in the sky. Snow scenes lose all their detail. People wearing dark clothing look like silhouettes.
I know we've all seen examples of stuff like that. I know I have - all too much, unfortunately - in the Indian movie DVDs I like to watch. Blown out whites and crushed blacks. That's what you get when you clip to 16-235. Maybe just a little bit, and maybe a lot.

In that thread, you can easily spot the pros (Chris Wiggles, Bob Pariseau, Joe Murphy) among the enthusiasts reacting to what they've read and asking questions.
Well, a few years ago i was given one sample of an anime DVD which was encoded at YCbCr [0,255]. But in that sample, black was at located at 0 and white at 255, so i guess the encoding was done incorrectly.)
Maybe, but not necessarily. In Japan NTSC, their black is 0, and not 16. If that anime was from a Japanese source, that might explain it. Or perhaps it was SMPTE 170M, which is the same:
In 1990 there was a push in the program production industry to change it back to 0 IRE. That change actually took place in Japan but didn't happen here in the United States. Part of the push for the change came from the fact that a lot of program material was being produced in the SMPTE component video domain which uses 0 Volts for black.
http://www.videoessentials.com/ve_d_faqplayer.php

Edited to fix a link.

[Wombler]

@ Manono

That's a fantastic post Manono!

Very enlightening.


Wombler

[Boulder]

Yes, thanks manono :) These things have never been thoroughly discussed here at Doom9, at least I don't remember reading as detailed information before.

[kumi]

Yes, many thanks manono, especially for your cogent summary (the thread is difficult to untangle for complete novices like myself.)

[tom942]

Thank you manono for this explanatory post and the interesting links that you posted.

Regards.

[Wilbert]

Hi-
I just disagree with the bolded conclusion.
There's no reason you should know those people that post at the AVS Forums. But they're not amateur enthusiasts like us (well, me anyway). These guys are the leaders in the industry. When they speak, it's the truth.
Oh, c'mon. Sure, some of them are professionals and most of us are not, but there no such thing as "the truth". "The truth" is always debatable to some extend. I thought i presented a clear argument about how i thought about these things, and i haven't seen anything what contradicts it.

Let me respond to some points in the stuff you quoted:


And farther down the page, in post #12, Bob Pariseau explains what can happen if you clip off the data below 16:


But the most common symptom that people see when BTB is clipped is "black crush" to varying degrees. This is a feeling that low black detail is being lost no matter how careful you are at trying to set black levels properly. This is due to two things. First, if the black levels on your TV float up and down depending on what's being displayed (usually based on the average brightness of the image) then when the BTB range temporarily floats up to become visible there's no detail there -- it's all been rounded to one value. Second, if the image processing in your TV is sensitive to (i.e., depends upon or takes advantage of) the BTB data, then near-black details ABOVE "Black" may get incorrectly rounded to the same level, and/or the absolute "Black" level may get rounded up a bit yielding dark gray instead of black on screen.

So the most common reported symptom associated with improper clipping of BTB data is loss of detail in low light scenes on various DVDs. Usually if you've got this problem, it will be seen in most ALL of your DVDs that feature detail-rich, low light scenes.

Now "black crush" can come from other errors in processing and calibration than just improper clipping of Blacker than Black data. But if you've got visible "black crush", checking for proper passing of BTB data is one of the first things to do.

The second most common symptom of BTB clipping is "noise" in low light level scenes. Again this is due to signal processing that happens after the BTB data is clipped. But in this case, instead of improperly rounding true detail to the same level (thus blurring the detail), random variations are introduced in that detail. Think of it as a type of "ringing" as the signal processing tries to deal with the fact that the light sampling has a sharp cutoff at "Black" -- something that wouldn't occur in "real" images.
http://www.avsforum.com/avs-vb/showpost.php?p=4997915&postcount=12

Near the bottom of the page, Chris quotes Stacy Spears from a different thread:
Similarly, I can and do demonstrate that clipping at 16 and 235 is visible. It's not just a little bit visible, it's awful. Your white detail goes all to hell. Clouds look like white plastic cutouts in the sky. Snow scenes lose all their detail. People wearing dark clothing look like silhouettes.

I translate the arguments above as (assuming a [16,235] YCbCr source):

Black is centered around 16 (let's say it deviates from 8 to 24), and white around 235 (227 to 243). Now, if you clip it to [16,235], some details get lost, and this effect is often visible. Thus, i agree with this. I don't agree with his point that it would be "awful" though.

I also explained what the downside is if you don't clip. Ie, you keep the full range or you stretch it a bit from, say [8,243] YCbCr [0,255] RGB. The downside is that black is not centered around RGB=0, and white is not centered around RGB=255. Of course, you can adjust your monitor for this, but then some parts will be clipped. Ie, something what you wanted to avoid.

So, imo, you either have to live with some clipping, or you have to live with the clip being to bright in dark scenes, and to dark in bright scenes.


I know we've all seen examples of stuff like that. I know I have - all too much, unfortunately - in the Indian movie DVDs I like to watch. Blown out whites and crushed blacks. That's what you get when you clip to 16-235. Maybe just a little bit, and maybe a lot.
Ok, so perhaps in this case, black is centered around RGB=8 and white around RGB=243 after converting from YCbCr when leaving the lumarange intact. Resulting in "the clip being to bright in dark scenes, and to dark in bright scenes".