PC scale color range doesn't seem to work as expected

[rlaphoenix]

The Problem

d2v_source YUVRGB_Scale=1 (PC) with ffmpeg -color_range pc (PC) returns a limited/TV color range output, not the expected full/PC color range.

You may be thinking, "Oh, maybe the source is just limited/TV range then?", if that's the case, then choosing the value for YUVRGB_Scale and -color_range in FFMPEG doesn't seem to matter and it just ignores the manually specified value, otherwise it should have given me an FFMPEG output where the blacks and whites are washed out, it shouldn't look "normal" if the source isn't PC color range.

Left: YUVRGB_Scale=1 ffmpeg -color_range pc | Right: YUVRGB_Scale=1 ffmpeg -color_range default (default is TV?)

Left has saturated blacks and saturated whites. Right has correct colors outputting at presumably PC range, yet ffmpeg used default color_range switch which is presumably tv and the D2V used YUVRGB_Scale=1 (PC). What?

Edit: It's been discovered that it essentially needs the -color_range of the opposite that YUVRGB_Scale is, because d2vsource sets _ColorRange to be the opposite of what YUVRGB_Scale is. See #41 for more information and why it may or may not have initially been intentional.

Here are the results of the combinations possible:

YUVRGB_Scale	ffmpeg -color_range	Correct color?
0 (TV)	default (TV?)	true
0 (TV)	pc	false
1 (PC)	default (TV?)	true
1 (PC)	pc	false

Here's a reminder that according to the d2v file and DGIndex manual, YUVRGB_Scale's options are 0 for TV and 1 for PC.

VapourSynth-Editor's Preview Window also only had the correct colors for YUVRGB_Scale=1.

None of the options where I matched YUVRGB_Scale and -color_range did the color output work correctly.

[dubhater]

I'll leave the ffmpeg part to you to figure out, but here's the explanation about YUVRGB_Scale: it doesn't describe the video's colour range. YUVRGB_Scale describes the desired output range when converting to RGB. It's explained in this part of the manual: http://rationalqm.us/dgmpgdec/DGIndexManual.html#YUVtoRGB

So when the manual says

YUVRGB_Scale
(0) TV Scale
(1) PC Scale

what it means is

assuming the video's range is limited, do you want to convert it to
(0) TV Scale RGB
or 
(1) PC Scale RGB

Huh?

If you want VapourSynth filters to assume the video has limited range, use YUVRGB_Scale=1 (PC). If you want them to assume the video has full range, use YUVRGB_Scale=0 (TV).

[rlaphoenix]

I understand its the matrix co-efficient for YUV->RGB operation, but it does have a valid effect when simply loading it with this source plugin, with no RGB conversion taking place on my script. It seems to change the color in some way unless this is something to do with VapourSynth Editor's Preview converting it to RGB.

Edit: VapourSynth Editor converts to RGB, which is why the value seemed to be taking effect.

[dubhater]

Yes, limited range is also known as TV range, full range is also known as PC range.

I know, it's confusing. YUVRGB_Scale is basically backwards compared to what one might reasonably expect. Read the explanation and that part of the manual again until it makes sense.

And yes, if you're displaying the video on your computer screen there is YUV to RGB conversion happening somewhere even if you didn't write that in the script. VapourSynth Editor does it for you, taking into account the _ColorRange frame property, which D2V Source sets according to YUVRGB_Scale. That's why changing YUVRGB_Scale has an effect on what you see in the Preview window.

[rlaphoenix]

I was a bit confused originally reading about it being "backwards" considering all documentation and code has 0 for TV, and 1 for PC, so I looked into how VapourSynth uses _ColorRange and can see it does use it in the opposite order.

So in my opinion, this is in fact a bug, _ColorRange should be swapped when set by core.d2v.Source, which is actually a fairly simple fix.

It's not backwards/flipped. The issue here was the understanding of how YUVRGB_Scale should be used. It isn't an INPUT scale switch, it's an OUTPUT scale switch. YUVRGB_Scale does absolutely nothing until you want to convert YUV to RGB, as the name suggests. 1 (full/PC) means you want to convert the YUV input from YUV [16, 235(Y)/240(UV)] to RGB [0, 255]. 0 (limited/TV) means you want to convert the YUV input from YUV [16, 235(Y)/240(UV)] to RGB [16, 235].

This is why it feels like it's backwards because it's for the output, not the input. Let's say the input was limited/TV (e.g. The IT Crowd) and you wanted to load that in and convert it to full/PC? You would do YUVRGB_Scale=1, not YUVRGB_Scale=0.

It also did not help that VapourSynth Editor previewer (and other decoders) would convert to RGB, following the YUVRGB_Scale behind the scenes, without knowing it only applied because of that.

If you wanted that same source converted to RGB as limited/TV (RGB [16, 235]) you would do YUVRGB_Scale=0. However, if you then decode that in software/player expecting RGB [0, 255], then the blacks will be brighter and the whites will be darker. If you decode it in software/player that can detect it as limited/TV (either by ffmpeg's -color_range flag, manual means, or such) then it would look correct.

	full/PC (1)	limited/TV (0)
Possible Shades	256 (0-255)	225 (16-235)
Absolute Black	0	16 shades brighter than full RGB
Absolute White	255	15 shades darker than full RGB

[dubhater]

It was wrong before this commit: 3a1b750

It's correct now. Maybe you have an old version (1.0 or older)?

[rlaphoenix]

-snip-
just entirely wrong

[dubhater]

Please read again: http://rationalqm.us/dgmpgdec/DGIndexManual.html#YUVtoRGB

[videoh]

We're reading what you write. You seem to think this option specifies the range of the input video. No! It defines the range you want for the RGB conversion. Consider a black in YUV. It has value 16. Now the question is do you want that mapped to 16 in the RGB (TV range) or to 0 (PC range). Suppose you pick PC and map it to 0. Then the black will be darker than if you had picked TV. Same goes for white. Is it clear?

[rlaphoenix]

Yes, that explanation does clear it up a bit. I always assumed that the mapping for 16,235 to 0,255 is the one that causes the brighter blacks and darker whites, but it is the other way around, hence the inverted sense.

Am I correct in saying all YUV videos are Y(16,235) UV(16,240) (TV/limited range) input? Meaning no matter what, I would want to use -color_range tv on ffmpeg?

[dubhater]

Am I correct in saying all YUV videos are Y(16,235) UV(16,240) (TV/limited range) input? Meaning no matter what, I would want to use -color_range tv on ffmpeg?

In practice you'll find all sorts of videos, so you'll have to check with a histogram filter every time.

[videoh]

• Am I correct in saying all YUV videos are Y(16,235) UV(16,240) (TV/limited range) input? Meaning no matter what, I would want to use -color_range tv on ffmpeg?

If it is a DVD then yes, the source is encoded per 601, so the YUV has limited range. Beyond that dubhater is correct -- you better check. (I omit consideration of blurays, etc., because you are talking about DGIndex et al.)

[dubhater]

Even with DVDs you can't assume anything. I've seen a few where the luma went all the way to 255 in most scenes. I had some screenshots, but it looks like I deleted those. 25 out of 26 episodes of a certain anime series needed something like this:

adjusted=smoothlevels(24, 1, 255, 16, 235, chroma=0, limiter=0)
trim(0, 2713-1) + adjusted.trim(2713, 39179) + trim(39179+1, 0)
trim(0, 40828-1) + adjusted.trim(40828, 43922) + trim(43922+1, 0)

From another anime:

trim(1803, 38909).smoothlevels(32, 1, 255, 16, 230, chroma=0, limiter=0) + trim(38910, 0).smoothlevels(16, 1, 255, 16, 235, chroma=0, limiter=0)

[rlaphoenix]

Even with DVDs you can't assume anything. I've seen a few where the luma went all the way to 255 in most scenes.

I see, how would I check though? I see you have a vapoursynth-histogram plugin, which I have now installed and taken a look at, but now entirely sure how to use this to check.

[dubhater]

You'll see lots of white pixels in the purple parts: