Limited and full color range mixup

Version 5.1.1
Source: full color range (you call it JPEG) + BT.709.
Model Proteus with default settings.
When JPEG is selected in input (for color range) - output is limited color range.
When MJPEG is selected in input - output is full color range (as input).
When autodetect is selected it switch to JPEG after preview and output is limited.

Looks like you’v mixed them up in the code.

Btw in my opinion it’s better to call them “limited” and “full” and not “MJPEG” and “JPEG”.

1 Like

I’v tested it again.
Input is full range video.
No matter what is selected in input setting (JPEG or MJPEG):
Preview is always in limited range.
Output is always in limited range.
Maybe it treats input right. But output is always limited.
Means when you convert from RGB to YUV you use formula for limited range.
Looks like you use coefficients for limited range YUV output.
For example at the start of the video its just a black screen. In full range Y channel is minimum 0.
When converted to YUV limited it should be minimum 16.
But preview output contains minimum 15 at first black frames. Sometimes later even 0 - that is even more strange to see in limited range video…
Hope model does not process video directly in YUV?
YUV is not designed for it. Its just an intermediate transport format.

You can read “Argaricolm” post about yuv full range formulas from here (11th post)

Could you submit a sample that shows this issue here?

You can securely submit your file(s) to our Dropbox using the link below. Please be sure to send me a note to let me know you sent something.

Submit to Dropbox

Thanks!

Here is a small mkv file with black image in all frames. It is encoded in full range. Full range is specified in metadata + rec709.
Video AI correctly identifies source as rec 709 and JPEG color range.
But if you will process it with proteus you will get limited range video.
You can check it using avisynth showchannels() plugin.

In source video you will see:
Y = 0, U & V = 128.
In output video you will see Y = 16, U & V near 128.
So output is limited.
I think Video AI should output full range if source is full.

And I have one tech question - there is option auto in source settings. How Video AI determines YUV rec used (601,709,2020)? Is it just reads metadata, or select it from height/width, or it analizes YUV values?

https://en.wikipedia.org/wiki/Rec._709

Digital representation

Rec. 709 defines an R’G’B’ encoding and a Y’C BC R encoding, each with either 8 bits or 10 bits per sample in each color channel. In the 8-bit encoding the R’, B’, G’, and Y’ channels have a nominal range of [16…235], and the C B and C R channels have a nominal range of [16…240] with 128 as the neutral value. So in limited range R’G’B’ reference black is (16, 16, 16) and reference white is (235, 235, 235), and in Y’C BC R reference black is (16, 128, 128) and reference white is (235, 128, 128). Values outside the nominal ranges are allowed, but typically they would be clamped for broadcast or for display (except for Superwhite and xvYCC). Values 0 and 255 are reserved as timing references (SAV and EAV), and may not contain color data (for 8 bits, for 10 bits more values are reserved and for 12 bits even more, no values are reserved in files or RGB mode or full range YCbCr digital modes like sYCC or opYCC). Rec. 709’s 10-bit encoding uses nominal values four times those of the 8-bit encoding, to ease the conversion it uses simple padding for reference values, for example 240 is just padded by two trailing zeroes and gives 960 for 10 bit maximum chroma.[22] Rec. 709’s nominal ranges are the same as those defined in ITU Rec. 601.[23]

Maybe 0 and 255 were reserved for limited color range YUV, but not for full. Get this black video I gave and open it on any tv. And you will see black screen. Not some error about reserved 0 or weird colors. So 0 can be used. Same for 255. I can encode pure white (255,255,255) to 255,128,128 YUV. And it will open correctly.
It happened so that I have Skyworth TV. And it does not convert limited color range to full (maybe should, but don’t). Maybe your TV does the same, and you think that limited color range video you see is normal. But it is not. And I’v seen that this problem is not for just Skyworth TV’s. Its possible to “fix” this problem by decreasing brightness + increasing contrast. But it’s a wrong fix. Video should be reranged to full before output. Limited color range is just an intermediate transport cheat that is used to decrease data transfer (it also compresses better), same as 4 times UV drop from YUV444 to YUV420.
I don’t understand why it is still used when all TVs are full range and transfer speed is at the sky…
Maybe the idea is to sell “HDR”.

My point is that TVAI exports should stick as close to the standards as possible by default, and not what we think the standards should be. Non-standard video is more likely to cause problems for broadcasters and consumers alike.

What people do for their own personal use is upto them, but software that purports to be “pro”, has to stick to the standards. If you need full range video, there are other standards for that. Hopefully, TVAI will give broader export options in the future.

YUV already have full range support. So it is standard now.
Plus - if source is full range and output is limited range - then source quality is decreased.

Not for rec709.
Yes for rec2020 (with caveats).
If you were to give full range rec709 video to a broadcaster like the BBC they’d throw it back to you.

This is when an option to override should be given for users who know what they’re doing, but it shouldn’t be the default behaviour.

We are talking here not about broadcasters.
By default Video AI should not change video color range. It is an upscale software. Not a software to convert content for broadcasters.

We’'ll have to agree to disagree then.

Just tested 5.1.3 version. Same as before - always limited range in output.
Don’t understand what this was about:
"Changelog from 5.1.2

  • Fixed render in-to-out range."

That fix refers to the time range for trimmed inputs.