Log in

View Full Version : Why can't I see the color range difference in this comparison?


PRAGMA
3rd November 2021, 15:32
In the following example: https://slow.pics/c/pWhOBm5V
Original source in case the re-upload made some kind of difference: https://github.com/dwbuiten/d2vsource/issues/40#issuecomment-617362250

On my monitor, I cannot notice any difference in the color range between the limited/TV and the full/PC images, yet others can.

Two other people have noticed an "obvious" difference, yet me and other people I've asked cannot notice a single difference.

I can only notice one difference now, and that's only after changing the black equalizer setting on my display from 17 to 13. The difference is just the black of the Histogram area being brighter (more gray) on the full/PC image.

I am on RGB Full Range 10bit as seen in my Nvidia Control Panel.

poisondeathray
3rd November 2021, 16:02
In the following example: https://slow.pics/c/pWhOBm5V
Original source in case the re-upload made some kind of difference: https://github.com/dwbuiten/d2vsource/issues/40#issuecomment-617362250

On my monitor, I cannot notice any difference in the color range between the limited/TV and the full/PC images, yet others can.

Two other people have noticed an "obvious" difference, yet me and other people I've asked cannot notice a single difference.



There should be very minors difference in the RGB converted image preview (you're not looking at the actual data, it's an RGB converted representation of the underlying YUV data). That's the key to understanding.

The waveform on the right is looking at YUV data. The RGB image preview on the left has been converted differently for each image.

Full range YUV is is being converted to full range (computer) RGB with full range Y 0-255 => RGB (0,0,0 - 255,255,255)

Limited range YUV is being converted to full range (computer) RGB with limited range Y 16-235 => RGB (0,0,0 -255,255,255)



I can only notice one difference now, and that's only after changing the black equalizer setting on my display from 17 to 13. The difference is just the black of the Histogram area being brighter (more gray) on the full/PC image.

I am on RGB Full Range 10bit as seen in my Nvidia Control Panel.

If you're looking at the RGB converted images, there should not be any difference in the full black level. Check out the pillarbars. They should be RGB 0,0,0 at any bit depth

PRAGMA
3rd November 2021, 16:07
There should be very minors difference in the RGB converted image preview (you're not looking at the actual data, it's an RGB converted representation of the underlying YUV data). That's the key to understanding.

The waveform on the right is looking at YUV data. The RGB image preview on the left has been converted differently for each image.

Full range YUV is is being converted to full range (computer) RGB with full range Y 0-255 => RGB (0,0,0 - 255,255,255)

Limited range YUV is being converted to full range (computer) RGB with limited range Y 16-235 => RGB (0,0,0 -255,255,255)




If you're looking at the RGB converted images, there should not be any difference in the full black level. Check out the pillarbars. They should be RGB 0,0,0 at any bit depth

Yes, to be clear, I understand here about the YUV to RGB conversion being taken place. What I don't understand is how those 2 people have stated a clear difference in the pictures to do with the range (shades) yet there is none to see other than in the histogram and text label (top left) areas. The actual image data (the data that was YUV) has no noticeable difference. So either they were on about the difference of black shading in the histogram and text label area, or there's something else at play.

The following is an image diff of the original images. As you can see there's no difference in the actual image, yet people in the image source stated an obvious difference in the two images. Either they lied, or are assuming based on a placebo effect of the text boxes on the top left and the histogram.
https://user-images.githubusercontent.com/17136956/140087264-442cdd06-6d6b-4f2a-be0e-9691f7e8ebdd.png

poisondeathray
3rd November 2021, 16:45
Yes, to be clear, I understand here about the YUV to RGB conversion being taken place. What I don't understand is how those 2 people have stated a clear difference in the pictures to do with the range (shades) yet there is none to see other than in the histogram and text label (top left) areas. The actual image data (the data that was YUV) has no noticeable difference. So either they were on about the difference of black shading in the histogram and text label area, or there's something else at play.


ChythonVII' s comment was likely based on the histogram (waveform)


There is no material difference in the RGB converted image on the left. There are differences.


ChythonVII wrote:

As for the images, I think maybe your monitor needs adjustment/replacement. It's 110% visually obvious to me that the top image has had its range squashed.


If you clipped the right waveform off, could he say the same thing ? A blind test in RGB ? I doubt it.

How would you come to that conclusion? Look at an RGB picker . Black is RGB 0,0,0 in both images. Put a color picker on the sky, they might differ by +/-1 value. eg. 250,250,250 vs. 250,250,249. A midtone might differ by +/-2 .

The only evidence you might have of "range squashing" is with a gradient image, and you didn't dither the image (applied levels with dither=False instead of smoothlevels). You would expect more banding on a gradient

And how could you come to that conclusion based on this image alone? Why not range expanded instead of range compressed ? How would you know which was "first" ?


The following is an image diff of the original images. As you can see there's no difference in the actual image, yet people in the image source stated an obvious difference in the two images. Either they lied, or are assuming based on a placebo effect of the text boxes on the top left and the histogram.


Yes, as I stated earlier, there are only minor differences in the 8bit PNG RGB converted images, you can amplify them to see them

d = core.std.MakeDiff(a,b)
da = core.std.Levels(d, min_in=127, max_in=129, gamma=1, min_out=0, max_out=255, planes=[0,1,2])
s = core.std.StackVertical([d, da])
s.set_output()

https://i.postimg.cc/wxGjK0jQ/diff.png[/url]

Reclusive Eagle
3rd November 2021, 19:34
In the following example: https://slow.pics/c/pWhOBm5V
Original source in case the re-upload made some kind of difference: https://github.com/dwbuiten/d2vsource/issues/40#issuecomment-617362250

On my monitor, I cannot notice any difference in the color range between the limited/TV and the full/PC images, yet others can.

Two other people have noticed an "obvious" difference, yet me and other people I've asked cannot notice a single difference.

I can only notice one difference now, and that's only after changing the black equalizer setting on my display from 17 to 13. The difference is just the black of the Histogram area being brighter (more gray) on the full/PC image.

I am on RGB Full Range 10bit as seen in my Nvidia Control Panel.

Check the different displays you have in your house. I.E send the image to your phone, a different computer etc. You might have lower contrast ratio on your monitor.

Or if you are actually in the creator space and have a 10 bit or color calibrated monitor, its because there is 0 standardization when it comes to displays.

Its an issue in photography too. No matter what you edit your image to look like, it will look different on every other screen unless you color calibrate your monitor to your environment which only 1% of people will ever do.

I don't see a difference with this image.
However learn to trust your histogram and not your eyes.

In photography it can be super bright outside but because my screen doesn't match the brightness of the sun, it gets washed out and even though the photos on my screen "Look" correct at the time.
Reviewing the photos they can be 1-2 stops under exposed.

Either way, you see a change in histogram or waveform, trust it.
Not your eyes.

_Al_
3rd November 2021, 20:28
I just want to add this, trying to be simple, because it was a stopper for a while. Something is not right if working with vapoursynth and d2vwitch, I had to just use experience to have desired result:

if loading m2t video with ffms2.Source, indexing it, (from HDV camcorder, thats mpeg2), vapoursynth sets _ColorRange to 1 limited and rgb colors look the same as if playing with mpv player

if loading m2t video using d2vwitch and using defaults, which is --index-range "limited", indexing it, rgb colors are washed out and vapoursynth shows _ColorRange 0 which suppose to be full,

if I set --index-range "full" using d2vwitch , it loads rgb to the same values as ffms2 and vapoursynth shows _ColorRange as 1 limited

It should be straightened out somehow, for it causes some headaches when using mpeg2 files, not sure what or who is wrong here, just mentioning it, not knowing really, maybe source plugin is at fault, which one? Or dv2which or vapoursynth flag setting? Which one? :scared:

_Al_
3rd November 2021, 20:42
perhaps I rather belongs to that github link, I post it there

videoh
3rd November 2021, 21:18
It should be straightened out somehow, for it causes some headaches when using mpeg2 files, not sure what or who is wrong here, just mentioning it, not knowing really, maybe source plugin is at fault, which one? Or dv2which or vapoursynth flag setting? Which one? :scared: What source filter are you using for the D2V? d2vsource? If so there is a strange path to _ColorRange that does not include the source stream details. You should manually set _ColorRange as needed in your script after the d2vsource invocation. It's discussed in the github thread. ffms2 works because it sets _ColorRange directly from the stream info.

_Al_
3rd November 2021, 21:40
d2vsource, thanks, that sets it up again to limited: clip = core.std.SetFrameProp(clip, prop="_ColorRange", intval=1)

videoh
3rd November 2021, 21:50
Yes, that is good, but requires you to manually look at the stream and then set things. Better, though, would be to use a source filter, such as ffms or DGSource() that automatically sets _ColorRange from the stream info. I need to add that to mpeg2source().