AVS Softlight

[DTL]

"Here is example."

Computer displays and OS (bitmap processing) were designed for RGB full range mapping. Typically for static imaging like photo. So to watch industry standard encoded moving pictures with narrow range mapping you need special software (or software + driver for video card to support all required conversions and levels re-mapping) and you will got all your blacks correct and some not clipped and not very bad super-whites. It is topic for '(software) video players' section of forum - https://forum.doom9.org/forumdisplay.php?f=15

[Julek]

Originally Posted by Argaricolm

When you view it on tv as it is - nothing is converted to full range.

That's just wrong.
There is metadata for this, check a WEBDL with mediainfo for example.

And if you can't see 100% black on your TV, maybe it's because your TV isn't OLED, in which case it's physically incapable of making true black.

[wonkey_monkey]

Originally Posted by DTL

So to watch industry standard encoded moving pictures with narrow range mapping you need special software

I wouldn't say you need special software. I've never seen a video player that doesn't expand from limited range by default.

[DTL]

"And new TV's can't determine automatically that source is limited color range."

It may be broken TV or badly configured from defaults. After RCA/SCART analog cunsumers connections between Disk Players and Display devices new standard is HDMI. And typical display should expect HDMI data in narrow range by default. Some displays have control how to treat HDMI data - narrow or full (for the case of Computer connection via HDMI). Also HDMI may have some metadata signalling on range mapping used (is some version and depends on transmitter and receiver compatibility ?).

So in the case you use standard consumer Disk Player and standard consumer Media Display Device and connect via RCA/SCART or HDMI everything expected to runs fine with correct blacks and super-whites.

If you trying to use Media Display Device with media file playback - there are many points of failure like badly created file rip or wrong display playback firmware (or incompatible with some hand-crafted file rip etc). If you try to use general purpose consumer Computer to playback some file rip there are even more places to fail.

If you use some network streaming it is also may or may not be correctly decoded in playback device (depend on codec/protocol/etc settings at source side and firmware at playback device). So it is the subject to post issues to streaming provider or manufacturer of playback device about possible errors in range mapping treatment.

With AVS it is possible to change levels mapping using Levels so simulate Computer Playback transform of narrow range RGB like Levels(16,255,1,0,255) (and in system transform domain or linear (?)) into Computer full range RGB 0..255. Yes - in 8bit it will adds some quantization noise (banding) so may be good to add some dithering after this range mapping (expansion) if source natural noise levels are too low to do self-dithering.

It is not one and always correct range remapping - it only some example to keep super-white unclipped. To get more contrast with clipping of possible super-whites you can use Levels(16,235,1,0,255) or you can go into RGBPS and apply some LUT or AI/NN plugin to do some nice super-whites expansion to HDR and convert result back into some standard HDR transfer domain to feed to HDR-capable display device.

[Argaricolm]

Well I have a cheap TV Skyworth. And it does not have any switch between TV / Full color range and looks like it shows everything in full range.
Yes it has some feature called "adaptive brightness control", but it is adaptive. Its is not a static convertion from tv to full range.
Also I watch some content from TV box Beelink, that is flashed with android tv custom firmware. It also does not have any switch for TV / Full range. It has only settings to choose between YUV444, YUV422, RGB. But this switch does not affect color range.
And also I'm not some guru, so as a normal user when I see some settings about full range or limited range I think that "full" is better than "limited". And I think most other normal TV users think like so.
And in result we see limited color range without convertion. So we watch data in its intermediate state designed to be converted to full range before output. And I think it's a strange design for our days when we have fast transfer speeds and space - no need for limited color range anymore.

And here is example of what we see and what we should see.

And especially strange to see such content on youtube. For example most tv records are published there without convertion to full range. And we watch it on our tablets/computers also without any convertion. And we think that it is "normal".

[Julek]

Originally Posted by Argaricolm

And here is example of what we see and what we should see.

Can you post the script used to convert limited->full, you seem to be doing it the wrong way, when you convert the YUV video to RGB it is already adjusted to full, so there should be no difference, and your “full” is clipping dark areas.

[wonkey_monkey]

It might be worth pointing out here that humans have a tendency to automatically associate brighter/louder/higher contrast/higher saturation with "better". That doesn't mean "full" is always the proper choice.

[Argaricolm]

Originally Posted by Julek

Can you post the script used to convert limited->full, you seem to be doing it the wrong way, when you convert the YUV video to RGB it is already adjusted to full, so there should be no difference, and your “full” is clipping dark areas.

Before I was using YUV <-> RGB conversion formula from here.
But result was always YUV with limited range.

Now I use formula from here.

It does not care for color space resulting the same range.
Example: RGB(5,5,5) <=> YUV(5,128,128)
So from limited YUV I get limited RGB and then limited YUV back (or from full I get full).

Softlight(8) rerange limited range to full this way:

1. YUV is converted to RGB (if input is YUV)
2. RGB is reranged
3. Back to YUV.

Rerange is done this way:

(R - 16) / 220 * 255 + 0.5

So each level from 16 to 235 will become from 0 to 254.
When it is converted to YUV - I get full range YUV.

So far the best combination I use for myself is:
ConvertToRGBNV() <- this is from ImageSourceNV plugin
softlight(8)
softlight(3)
ConvertToYUVNV()

Here I use BGR32 input because I use one plugin between softlight(8) and softlight(3) that requires BGR32 input.

If you use only softlight combination then its better to convert to RGB planar input. This way softlight functions will not convert YUV <-> RGB each time.
In above my example they convert BGR32 <-> RGB planar in each softlight call (but using CUDA).

Think I will add just convertion functions the next release.

[Argaricolm]

Originally Posted by wonkey_monkey

It might be worth pointing out here that humans have a tendency to automatically associate brighter/louder/higher contrast/higher saturation with "better". That doesn't mean "full" is always the proper choice.

Better choice to view surely.
Looks more 3D and with higher saturation.
Yes you see fewer details in dark areas. But I think its a small tradeoff not to see some dark details for deeper 3D and not brightened colors (and that's how you should view it anyway - if your hardware/software will correctly identify source as limited).

[wonkey_monkey]

Originally Posted by Argaricolm

Better choice to view surely.
Looks more 3D and with higher saturation.
Yes you see fewer details in dark areas. But I think its a small tradeoff not to see some dark details for deeper 3D and not brightened colors.

That's your personal choice. It doesn't mean your TV is doing something wrong just because you can override it to a setting that you think looks better.

[Argaricolm]

Originally Posted by wonkey_monkey

That's your personal choice. It doesn't mean your TV is doing something wrong just because you can override it to a setting that you think looks better.

In my case I can't override it.
Also i'v not mentioned it here:
If you watch video on PC using MPC-HC - its default renderer "MPC Video Renderer" will output video in limited range even if your video is full range and even if video has full range tag.
To watch full range video you need to select EVR renderer in options.

Also if you want to process limited range input and get limited range output - I think its better to convert it to full before and then back to limited.
Because neutralization functions are designed for full range. They get negative average sum this way: 255 - average.
I have not tested it with (235 - average) for limited input. And it will be more complicated, because limited input technically can have noise levels > 235. So for proper average calculations I need to cut those levels before sum.
Will try it later but not soon.

[hello_hello]

Originally Posted by Argaricolm

And also I'm not some guru, so as a normal user when I see some settings about full range or limited range I think that "full" is better than "limited". And I think most other normal TV users think like so.

TVs generally expect limited range for YUV and expand it to full range to display it. Likewise they should/could expect RGB to be full range and therefore shouldn't expand it.

My old Samsung TV doesn't have a setting labelled full/limited range either. Samsung decided to label it "HDMI Black Level", where "Normal" means the TV expects full range and "Low" means it expects limited range. It only applies when the input is RGB over HDMI though. Any other time it's greyed out as it expects YUV to be limited range, and it expects RGB at it's VGA input to be full range.

The LCD monitor connected to this PC does have a setting labelled RGB full/limited range for it's HDMI inputs.

Originally Posted by Argaricolm

And in result we see limited color range without convertion. So we watch data in its intermediate state designed to be converted to full range before output. And I think it's a strange design for our days when we have fast transfer speeds and space - no need for limited color range anymore.

As long as the output and input match in respect to levels the picture should look correct, and any input/output settings probably only apply to RGB over HDMI anyway. Here's a screenshot showing how to change the levels in the Nvidia control panel. https://i.redd.it/x44a5pwwned51.png

Originally Posted by Argaricolm

And here is example of what we see and what we should see.

I'd place a bet on the limited range version being the correct one, although if your TV has a really horrible black level I can see why the full range picture might look better.

It's fairly easy to check when you're using a PC with MPC-HC, as it has pixel shaders for changing the levels. If you play a video with black borders encoded and you tell MPC-HC to expand the levels with a pixel shader.... if the picture gets darker but the borders don't then they were already black and the levels were already being expanded. Like this:







However if the black borders do get darker then the levels are wrong.

Here's a small YV12 video you can try. There's a histogram on top.
The first 500 frames have the correct levels. Black=16.
The next 500 frames have those levels expanded. If it's being displayed correctly the black borders won't/can't get any darker even though the picture will.
For the last 500 frames a PC to TV conversion was applied so the black borders should be dark grey rather than black and the picture will look a bit washed out. If the borders still look black rather than dark grey it means the levels are being expanded unnecessarily, maybe due to a mismatched input/output.

Black Test.mkv

[Argaricolm]

I'm making an update with support for lossless yuv<-> rgb convertion. And also I'v added rec 601 & rec 709 so far (not published).
What will be better:
1) Use based on height: Rec601 when height <= 576; Rec709 for 577-1080; Rec2020 for > 1080
2) Or use rec 709 always by default.
It will be possible to select input rec and output rec separately.

[Argaricolm]

Originally Posted by hello_hello

Black Test.mkv

Tried this video from TV and from TVbox.
My TV shows it same way as on PC.
I see limited range in first part (with bad blacks), PC range in middle (ideal) and bright last.
No settings in TV about color range, no settings in any android video player about it. Only "adaptive lightness control" in TV - but it does a little different work and it change full range too.

Looks like I'm stuck with converting video or playing it from PC.

[DTL]

Originally Posted by Argaricolm

I'm making an update with support for lossless yuv<-> rgb convertion. And also I'v added rec 601 & rec 709 so far (not published).
What will be better:
1) Use based on height: Rec601 when height <= 576; Rec709 for 577-1080; Rec2020 for > 1080
2) Or use rec 709 always by default.
It will be possible to select input rec and output rec separately.

For fail-safe operation it may be better to disable any auto-estimation and force user to provide required param.

You can set init value to -1 for example and if it is left as default at class constructor - throw an error about required param not set.

Also if you want to try new AVS+ features you can read frame/clip property of the colour matrix (if set). So possible ways are:
1. Force user input only.
2. Auto-estimate based on the frame height.
3. Read input frame/clip properties.

[Argaricolm]

Example of OETF function.
It makes all movie bright like on the Sun...

[Argaricolm]

Version 1.15 is out.

[Selur]

yuvin & yuvout options are used for modes where yuv <-> rgb conversion is used and they define formula used for decode and encode 0 = Default is Rec.709. Or you can select 601, 709, 2020. Like Softlight(yuvin=601,yuvout=601)

okay, 0 = Rec.709 What are 601 and 2020?

[DTL]

It looks current version uses direct numbering - https://github.com/ArturAlekseev/AVS...ernel.cu#L2892

So 0 and 709 are the same and others are 601 and 2020 integers for rec.601 and rec.2020 matrices. Any other integer numbers except 601 and 2020 will cause default to rec.709 matrix ?

[Selur]

@DTL: Thanks.

Any other integer numbers except 601 and 2020 will cause default to rec.709 matrix ?

yes.