Colorspace vs. Contrast Ratio - Page 7 - AVS Forum
Forum Jump: 
Reply
 
Thread Tools
post #181 of 246 Old 03-06-2007, 12:19 AM
AVS Addicted Member
 
krasmuzik's Avatar
 
Join Date: Oct 1999
Location: NewPort, VA
Posts: 11,270
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Yn = (Y - 16)/219

If Y is restricted to 8b integer ranging from 16 to 235 representing 219 values - and you cast Y to a floating point "integer" on any computer I am aware of such that you can subsequently do a floating point divide - you get 219 floating point values between 0 and 1. Prove me wrong with a spreadsheet that shows otherwise - that you create 256 values.

Here let me get you started

Y=>Yn
16->0
17->.004566210
18->.009132420

each subsequent step up will be 1/219=.004566210 apart in floating point (within floating point rounding errors since the format cannot represent an infinity of fractions like analog system can)

Finish it and prove there are 256 steps 1/219 apart with the series ending in 1.

If I start with an array of 219 numbers - I end up with an array of 219 integers in this linear system out of the 256 possible integers - not 256 out of 256.... Maybe you have some new integer math I am unaware of....
krasmuzik is offline  
Sponsored Links
Advertisement
 
post #182 of 246 Old 03-06-2007, 12:50 AM
AVS Special Member
 
dlarsen's Avatar
 
Join Date: Mar 2001
Location: Beaverton, OR, USA
Posts: 1,908
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by Krasmuzik View Post

If I start with an array of 219 numbers - I end up with an array of 219 numbers in this linear system. Maybe you have some new math I am unaware of....

You are correct for the pure grey-scale cases. (Considering only Y with CbCr=128) there would only be 220 discrete, unique levels of pure grayscales, where CbCr are neutral and not weighted and will yield only 220 RGB codewords where R=G=B. There would NOT be 256 unique pure grayscale values for sRGB and there would be non-monoticity for those 220 pure grays. On those 220 specific levels where CbCr=128, I stand corrected. One the other ~2.7 million valid YCbCr codewords...

Dave
dlarsen is offline  
post #183 of 246 Old 03-06-2007, 02:13 AM
AVS Special Member
 
dlarsen's Avatar
 
Join Date: Mar 2001
Location: Beaverton, OR, USA
Posts: 1,908
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
While looking for the YCbCr-RGB equations the MS guys posted, I came across this old post from Don on the subject of reference voltages, StudioRGB, and doing it with a PC. Some of the same stuff we've been discussing

Quote:
Originally Posted by dmunsil View Post

Jeff, you're correct about the voltage levels - using studio RGB on a current model video card will not produce the reference black and white at the reference voltages. My comment about Faroudja is only apropos in terms of bit depth - Faroudja uses 8-bit studio RGB, and thus only has 219 output levels within the reference range. But they do map 16 to 0mV and 235 to 700 mV. Apologies. As Stacey mentioned, they have a dual-rail power supply so they can go negative on voltage, which current PC video cards cannot.

Dave
dlarsen is offline  
post #184 of 246 Old 03-06-2007, 08:54 AM
Senior Member
 
Charles Black's Avatar
 
Join Date: Sep 2003
Location: Lopez Island, Washington
Posts: 340
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Here is a table I made that shows each Rec. 709 video level after converting to PC levels. The missing levels worked out as per Poynton in his highly recommended "Digital Video and HDTV". The Last column is just an example of the luminance that an 104cd/m^2 monitor would create. This is meant to be handy for manual calibrations with a photometer or Spyder2. Just multiply the value in column four by your D65 white point reference luminance to get the theoretical luminance output at that PC level. I have a small series of these tables for un-expanded video and Gamma 2.5 monitors. Usually I have a L* column just for reference but I omitted it for this one. All levels are per Rec. 709 so the "Noise Reduction" at low levels can be studied.

Charlie

Edit: The third column in the table should read Normalized Input Luminance.

 

Rec709G2_22220to255.txt 11.5283203125k . file
Charles Black is offline  
post #185 of 246 Old 03-06-2007, 10:39 AM
Senior Member
 
Charles Black's Avatar
 
Join Date: Sep 2003
Location: Lopez Island, Washington
Posts: 340
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
L* is back! This is the above table with L* included to help in evaluation. L* is a measure of perceptual "distance". A distance of unity between any two L* values is generally imperceptible. Paraphrased from Poynton. Have fun!

Charlie

Edited: The third column of the table had the wrong header so I uploaded it again.

 

Rec709G2_22220to255Lstar.txt 13.6806640625k . file
Charles Black is offline  
post #186 of 246 Old 03-06-2007, 12:58 PM
 
ChrisWiggles's Avatar
 
Join Date: Nov 2002
Location: Seattle
Posts: 20,730
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 15
Quote:
Originally Posted by dlarsen View Post

Krasmuzik-

Here's the math as posted by the MS dudes way back when


For StudioRGB Levels
First Y, Cb and Cr have to be converted to normal range (0..1 for Y, -0.5..0.5 for Cb,Cr):

Yn = (Y - 16)/219
Cbn = (Cb - 128)/224
Crn = (Cr - 128)/224

Then convert to RGB in normal range (0..1 for all components).

Rn = Yn + (1.402 * Crn)
Gn = Yn - (0.344136 * Cbn) - (0.714136 * Crn)
Bn = Yn + (1.772 * Cbn)

Finally convert normal RGB to RGB in studio (16-235) range:

R = Rn*219 + 16
G = Gn*219 + 16
B = Bn*219 + 16

---------------------------------------------------------------------------------------------------
For sRGB Levels
First Y, Cb and Cr have to be converted to normal range (0..1 for Y, -0.5..0.5 for Cb,Cr):

Yn = (Y - 16)/219
Cbn = (Cb - 128)/224
Crn = (Cr - 128)/224

Then convert to RGB in normal range (0..1 for all components).

Rn = Yn + (1.402 * Crn)
Gn = Yn - (0.344136 * Cbn) - (0.714136 * Crn)
Bn = Yn + (1.772 * Cbn)

Finally convert normal RGB to RGB in PC (0-255) range:

R = Rn*255 + 0
G = Gn*255 + 0
B = Bn*255 + 0

Note that both step use the same normalization to the 0-1 range. This is where Chris will say that the normalization step is only an abstraction and not real. That normalization step seems to REALLY alter the levels from Y16-235 and CbCr16-240 to R(0-1) B(0-1) G(0-1) Also note the only difference is the gain and offset applied to the normalized data. That last step.

I'd guess it's my 32bit CPU that's doing those calculations. With FP. I dunno for sure. This is a shortcut from the true matrix operations but it appears these are commonly used shortcuts. As I said, this is how MS said they do the transforms. All the published methods I've see do included normalization to the (0-1) range however. Again, a pretty massive level' shift from what was on your disk. I have an excell spread-sheet somewhere that runs through all this. I can try to dig it up if your interested but it's pretty well spelled out above.

Dave

Yes, but you can easily see that if you run the numbers if you maintain the levels range you maintain the transform completely and end up with integer results.

That is to say, if you hold Chroma at neutral you can see easily that Y maps direcly to RGB values. A Y value of 'X' maps directly to an integer RGB value of 'X.' If you expand the range you miss codes because you have to round somewhere, so you'll end up with two-step gaps. This will cause banding/contouring if you're only doing this operation in 8-bit or have to go through an 8-bit bottleneck such as DVI.

I have attached a figure from Poynton that visually illustrates the results of this re-map and the missing codes that will introduce visible banding problems.
LL
ChrisWiggles is offline  
post #187 of 246 Old 03-06-2007, 02:02 PM
Senior Member
 
Charles Black's Avatar
 
Join Date: Sep 2003
Location: Lopez Island, Washington
Posts: 340
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:


I have attached a figure from Poynton that visually illustrates the results of this re-map and the missing codes that will introduce visible banding problems.

Chris,

The illustration you presented is correct but your interpretation is not supportable - at least for real sources. Using level 124 as an example all we need to do is subtract the L* value of level 123 from the L* value of level 125 using the table I just posted.

That's 52.241 - 51.768 = 0.473.

Since 0.473 is less that unity the difference in lightness between level 125 and level 123 will be less that the threshold of discrimination. See Poynton Page 209.

Charlie
Charles Black is offline  
post #188 of 246 Old 03-06-2007, 02:25 PM
AVS Special Member
 
dlarsen's Avatar
 
Join Date: Mar 2001
Location: Beaverton, OR, USA
Posts: 1,908
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by ChrisWiggles View Post

if you hold Chroma at neutral

Agreed. This is along the line that Kras pingged me on. Only the pure gray scales. If all you look at is 219 step grey-scale ramp, (or exclusively BW images.) You may have a valid mathematical argument. As Charles noted, I think the argument wouldn't hold with the practically of real-world color images and the limitations of the HVS. Any non-monotonic steps should be well below the HVS threshold. (IMO)

Quote:
Originally Posted by ChrisWiggles View Post

If you expand the range you miss codes because

You won't miss codes relative to what is on the source. All the unique 220 codes in the source will find a home in sRGB/PC. They will all still be there and none will be duplicated.

I'll buff up my spread sheet and run though all those cases and show that. To me, to qualify for visible banding, codewords must collapse or be duplicated such the difference between two levels is above the HVS threshold.

I believe you have shown non-monoticity. I don't believe that a non-monotonic progression automatically = banding.

Quote:
Originally Posted by ChrisWiggles View Post

completely and end up with integer results.

You wont have integer results (except pure black and white) in the normalized data range. Rounding precision errors will be present in either case where CbCr does not = 128 and therfore IS weighted in the (non-integer) computations.



Dave
dlarsen is offline  
post #189 of 246 Old 03-06-2007, 02:53 PM
AVS Special Member
 
dlarsen's Avatar
 
Join Date: Mar 2001
Location: Beaverton, OR, USA
Posts: 1,908
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by CharlesBlack View Post

The missing levels

Charles-

As I noted above, it appears to me that there aren't any missing codewords relative to what is encoded on the source. They are all still there and have a home in sRGB/PC. They are only missing relative to the 256 valid codewords that can be represented validly in sRGB/PC not relative to the 220 valid codewords that can be represented validly in StudioRGB. Agreed?

Dave
dlarsen is offline  
post #190 of 246 Old 03-06-2007, 04:22 PM
AVS Addicted Member
 
krasmuzik's Avatar
 
Join Date: Oct 1999
Location: NewPort, VA
Posts: 11,270
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by dlarsen View Post

You are correct for the pure grey-scale cases. (Considering only Y with CbCr=128) there would only be 220 discrete, unique levels of pure grayscales, where CbCr are neutral and not weighted and will yield only 220 RGB codewords where R=G=B. There would NOT be 256 unique pure grayscale values for sRGB and there would be non-monoticity for those 220 pure grays. On those 220 specific levels where CbCr=128, I stand corrected. One the other ~2.7 million valid YCbCr codewords...

Dave


You can do the similar math (just different CbCr value, same Y) for a primary or secondary color gradient from black to max RGBCMY- you will find you have banding in those patterns as well. ditto for tertiary colors. And if you did the same math for all the bazillion of possible color combinations - I think you would find that expanding to sRGB from YCbCr creates similar gaps throughout the color space. StudioRGB pushes those gaps out to the headroom and footroom area - leaving a smaller color cube but without color gradient banding. On digital display you do the expansion to sRGB internally anyways as that is what the panels want to see for max contrast - but you do it with more bits - no gradient issues (aside from technology specific problems - like LCD vertical banding)
krasmuzik is offline  
post #191 of 246 Old 03-06-2007, 04:32 PM
AVS Addicted Member
 
krasmuzik's Avatar
 
Join Date: Oct 1999
Location: NewPort, VA
Posts: 11,270
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by Charles Black View Post

Chris,

The illustration you presented is correct but your interpretation is not supportable - at least for real sources. Using level 124 as an example all we need to do is subtract the L* value of level 123 from the L* value of level 125 using the table I just posted.

That's 52.241 - 51.768 = 0.473.

Since 0.473 is less that unity the difference in lightness between level 125 and level 123 will be less that the threshold of discrimination. See Poynton Page 209.

Charlie

But that threshold is based on seperated patches - put the patches together with a long boundary and your HVS edge detection sees the banding (it really just sees the edge not the lightness difference) Dither the boundary line and HVS edge detection does not work - you will not see the banding because you cannot see the lightness difference. A two step up edge is easier to see than a one step up edge. This is why you need AVIA PRO to test - it is not a dithered pattern - consumer AVIA is dithered (dunno about AVIA II).

I cold not download either file - guess I will have to spreadsheet myself to see what the level jumps end up being.
krasmuzik is offline  
post #192 of 246 Old 03-06-2007, 04:35 PM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,942
Mentioned: 39 Post(s)
Tagged: 0 Thread(s)
Quoted: 389 Post(s)
Liked: 414
So the alleged banding generated on the display side will be due to interpolation errors, correct? Has anyone just calculated these for various scenes and shown that the errors are perceivable, i.e. L* > 1?
zoyd is online now  
post #193 of 246 Old 03-06-2007, 04:39 PM
AVS Addicted Member
 
krasmuzik's Avatar
 
Join Date: Oct 1999
Location: NewPort, VA
Posts: 11,270
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Not so much interpolation errors - that is more properly used in the spatial domain - these are quantization errors. Increase the bit depth and you will get closer to the fractional values.
krasmuzik is offline  
post #194 of 246 Old 03-06-2007, 04:41 PM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,942
Mentioned: 39 Post(s)
Tagged: 0 Thread(s)
Quoted: 389 Post(s)
Liked: 414
Quote:
Originally Posted by krasmuzik View Post

Not so much interpolation errors - that is more properly used in the spatial domain - these are quantization errors. Increase the bit depth and you will get closer to the fractional values.

Oh, I thought you guys were talking about spatial banding in an image, how does this banding manifest?
zoyd is online now  
post #195 of 246 Old 03-06-2007, 04:46 PM
AVS Addicted Member
 
krasmuzik's Avatar
 
Join Date: Oct 1999
Location: NewPort, VA
Posts: 11,270
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
If the pattern is a horizontal ramp then it would look like spatial banding. But the gradient could go up or down or diaganol or curved or whatever. Interpolation error results from scaling filters - similar problem - you could have 219 discrete pixels that need to map to 256 discrete pixels

Quantization error is when you try to map 219 pixel values to 256 pixel values - you cannot - you can only map them to 219 different pixel values within a range of 256.
krasmuzik is offline  
post #196 of 246 Old 03-06-2007, 05:34 PM
AVS Special Member
 
dlarsen's Avatar
 
Join Date: Mar 2001
Location: Beaverton, OR, USA
Posts: 1,908
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by Krasmuzic View Post

You can do the similar math (just different CbCr value, same Y) for a primary or secondary color gradient from black to max RGBCMY- you will find you have banding in those patterns as well. ditto for tertiary colors.

I agree. (but not with the term banding) This same phenomena will probably (I haven't cranked through it) occur on the primaries and secondaries. The mathematical fundamentals if you will. On the 1540 mathematical fundamentals, There will NOT be 256 unique, discrete codewords representing the normalized range in sRGB/PC There will only be 220 just like StudioRGB. I stand corrected again. One the other ~2.7 million valid YCbCr codewords...

Quote:
Originally Posted by Krasmuzic View Post

And if you did the same math for all the bazillion of possible color combinations - I think you would find that expanding to sRGB from YCbCr creates similar gaps throughout the color space.

I don't belief so. Only for those mathematical fundamentals (and perhaps a few mathematical harmonics of those fundamentals) It looks to me that over most of the valid YCbCr triads, sRGB/PC would allow the opportunity for 256 unique, discrete codewords representing the valid normalized data range. The best StudioRGB can ever do is 220. In those pure fundamentals your have noted, sRGB would still have 220, just like StudioRGB.

Quote:
Originally Posted by Krasmuzic View Post

But that threshold is based on seperated patches - put the patches together with a long boundary and your HVS edge detection sees the banding

I don't see how this argument applies. These should be no discernment difference between a sRGB/PC step size and a StudioRGB step size. A sRGB step is SMALLER (1/255) than a StudioRGB step (1/219) over the valid normalized data range. Patches edges, or otherwise. In either case 8 bits has been established to provide step sizes smaller than the HVS threshold. Otherwise, video wouldn't really work for us.

I'll note that sRGB/PC plays with the full 8 bit deck it has been dealt. StudioRGB plays with a 7.79 bit deck.

Again, these gaps' and missing' codes seem only missing' from perspective of what would have been possible if the source had 8bits over the valid information range. It doesn't- it only has 7.79 bits. None of the information that was captured in those 7.79 bits that are encoded on the DVD go missing when expanded to 8 bits.

Quote:
Originally Posted by krasmizic View Post

put the patches together with a long boundary and your HVS edge detection sees the banding

This is the mach band phenomena, No? It is an HVS optical illusion. I mentioned that I suspected this is a source for much of the banding ballyhoo earlier. No difference between StudioRGB and sRGB that I can reason. Do the larger and coarser steps of StudioRGB somehow suppress this illusion?

Dave
dlarsen is offline  
post #197 of 246 Old 03-06-2007, 05:40 PM
Senior Member
 
Charles Black's Avatar
 
Join Date: Sep 2003
Location: Lopez Island, Washington
Posts: 340
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
But that threshold is based on seperated patches - put the patches together with a long boundary and your HVS edge detection sees the banding (it really just sees the edge not the lightness difference) Dither the boundary line and HVS edge detection does not work - you will not see the banding because you cannot see the lightness difference. This is why you need AVIA PRO to test - it is not a dithered pattern - consumer AVIA is dithered (dunno about AVIA II).

I cold not download either file - guess I will have to spreadsheet myself to see what the level jumps end up being.

krazmuzik,

I have seen the separate patch experiment in Wyszecki but the experiment I was using used a background Y sub 0 and circle in the center that represents about 20% of the total area. The circle is divided vertically and the left half is luminance Y and the rght half is luminance Y + Delta Y. The experimental data reveiled a logarithmic responce discrimination threshold over a 300 to 1 ratio of luminance. The luminance threshold of vision is said to be about 1% in this experiment over that range. Threshold of dicrimination dropped off above and below the logarithmicly linear part of the graph. My source was Poynton Page 198 and he got the study from Schreiber, Fundamentals of Elecrtronic Imaging.

Others are downloading it with no problem but if the board is balky I can email it to you.

I've already found a column label that is in error so I need to fix it.

Charlie
Charles Black is offline  
post #198 of 246 Old 03-06-2007, 05:47 PM
AVS Addicted Member
 
krasmuzik's Avatar
 
Join Date: Oct 1999
Location: NewPort, VA
Posts: 11,270
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
A sRGB step is LARGER than a StudioRGB step on the occasion when the math don't work to stuff lesser number of values into more values. Mostly because of the uneveness of the stepping in the edge detection - the gradient will not look smooth. There are many natural images that consist of smooth gradients - and it is the uneven gradient that feels unnatural that the eye is testing.

You indeed can see the larger steps in ramp patterns - maybe not on a tiny analog CRT - but throw up single chip DLP 10' wide - you can absolutely see it. Most people running digital projection are using StudioRGB with their HTPC for this very reason. We have done local testing at AVS meets on properly calibrated sRGB vs. StudioRGB - you most certainly can see the differences (with YCbCr sources)

Of course sRGB gradients generated by computer graphics will be "better" - but the point is that when you start with YCbCr media - what is the best 8b output to use - given that SMPTE requires headroom/footroom in their YCbCr standards - and thus in StudioRGB.
krasmuzik is offline  
post #199 of 246 Old 03-06-2007, 05:50 PM
AVS Addicted Member
 
krasmuzik's Avatar
 
Join Date: Oct 1999
Location: NewPort, VA
Posts: 11,270
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by Charles Black View Post

krazmuzik,

I have seen the separate patch experiment in Wyszecki but the experiment I was using used a background Y sub 0 and circle in the center that represents about 20% of the total area. The circle is divided vertically and the left half is luminance Y and the rght half is luminance Y + Delta Y. The experimental data reveiled a logarithmic responce discrimination threshold over a 300 to 1 ratio of luminance. The luminance threshold of vision is said to be about 1% in this experiment over that range. Threshold of dicrimination dropped off above and below the logarithmicly linear part of the graph. My source was Poynton Page 198 and he got the study from Schreiber, Fundamentals of Elecrtronic Imaging.

Others are downloading it with no problem but if the board is balky I can email it to you.

I've already found a column label that is in error so I need to fix it.

Charlie

But not a full screen half and half test? The longer the edge is - the easier it gets. Display size and viewing angle will be a big difference in this test - as well as display technology. If the step is not abrupt as with a CRT due to the gaussian spot - or three chip/beam misconverge - harder to see. But use single chip DLP - you get a nice sharp abrupt edge that is easier to see.

One should also presume psychovisual studies use normal people - not critical videophiles!

I seem to recall Chris quoting sources with specific numbers about discrimination improving at the edge. Your eye basically adds its own edge enhancement ring - goes a bit darker than the dark patch and rings a bit lighter than the light patch at the edge. The longer the edge the bigger the step - the greater the eyes EE.
krasmuzik is offline  
post #200 of 246 Old 03-06-2007, 06:06 PM
AVS Special Member
 
dlarsen's Avatar
 
Join Date: Mar 2001
Location: Beaverton, OR, USA
Posts: 1,908
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by Krasmuzic View Post

but throw up single chip DLP 10' wide

This is another area I've mentioned specific to DLP. DLP has it's own build it banding issues relation to the PWM sequences. They move (as does your perception of it) as levels change. To say you are veiwing StudioRGB levels on a DLP (or any digital) can be kinda an oxymoron to me as well. You may be feeding it only the 7.79 bits but it doing a similar bit expansion internal. Those levels aren't gonna be maintained (unless you severky throttle back B/C). It going to get expaned to more bits and the same non-monotinic level steps will occur. If you perceive banding on a DLP, I suggest you'll perceive similar banding even when viewing a true, monotic step pattern and they will move as you change levels.

Dave
dlarsen is offline  
post #201 of 246 Old 03-06-2007, 06:06 PM
 
ChrisWiggles's Avatar
 
Join Date: Nov 2002
Location: Seattle
Posts: 20,730
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 15
Quote:
Originally Posted by dlarsen View Post

Agreed. This is along the line that Kras pingged me on. Only the pure gray scales. If all you look at is 219 step grey-scale ramp, (or exclusively BW images.) You may have a valid mathematical argument. As Charles noted, I think the argument wouldn't hold with the practically of real-world color images and the limitations of the HVS. Any non-monotonic steps should be well below the HVS threshold. (IMO)

You are simply mistaken about this. Banding can easily be illustrated as visible in a decent system that does not otherwise have banding present. Whether you deem that significant or not is a different question. It is factually certain, however, that you are going to skip codes however. If we assume that 8-bit video is the minimum sufficient bit-depth to avoid visible banding, having a gap in the code is a significant problem and would fall above the visibility threshold.

Any experience with video and bit-depth limits will illustrate this to be a challenge.

Quote:
You won't miss codes relative to what is on the source. All the unique 220 codes in the source will find a home in sRGB/PC. They will all still be there and none will be duplicated.

That is correct. But their relationships have been changed, and because you have gaps in the new range you will have luminance deltas that are extremely likely to become visible, if not necessarily so.

Quote:
I'll buff up my spread sheet and run though all those cases and show that. To me, to qualify for visible banding, codewords must collapse or be duplicated such the difference between two levels is above the HVS threshold.

That is what is occurring, except that is not a "collapse." It is a gap. That's what the increase in delta is. If it were a collapse or duplication it wouldn't necessarily be a problem if the new range were still of sufficient bit-depth to keep single code-differences below the visible threshold.

Quote:
I believe you have shown non-monoticity. I don't believe that a non-monotonic progression automatically = banding.

Well, I'm not dealing with global statements like that. We have a specific situation of 8-bit re-mapping. In that case, because 8-bit is just barely sufficient to avoid banding, you definitely are likely to see banding if you have two-step gaps.

Quote:
You wont have integer results (except pure black and white) in the normalized data range. Rounding precision errors will be present in either case where CbCr does not = 128 and therfore IS weighted in the (non-integer) computations.

Dave

That is simply not the case. If you're not re-mapping the values you're not going to have gaps in the range. This is mathematically true.
ChrisWiggles is offline  
post #202 of 246 Old 03-06-2007, 06:07 PM
 
ChrisWiggles's Avatar
 
Join Date: Nov 2002
Location: Seattle
Posts: 20,730
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 15
Quote:
Originally Posted by Charles Black View Post

Chris,

The illustration you presented is correct but your interpretation is not supportable - at least for real sources. Using level 124 as an example all we need to do is subtract the L* value of level 123 from the L* value of level 125 using the table I just posted.

That's 52.241 - 51.768 = 0.473.

Since 0.473 is less that unity the difference in lightness between level 125 and level 123 will be less that the threshold of discrimination. See Poynton Page 209.

Charlie

I don't see where you are getting those numbers, nor do I see where Poynton is making any statements on p209 that back your claim.

My claim is absolutely supportable, and is easily tested. Do some testing yourself.
ChrisWiggles is offline  
post #203 of 246 Old 03-06-2007, 06:11 PM
 
ChrisWiggles's Avatar
 
Join Date: Nov 2002
Location: Seattle
Posts: 20,730
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 15
Quote:
Originally Posted by dlarsen View Post

I don't see how this argument applies. These should be no discernment difference between a sRGB/PC step size and a StudioRGB step size. A sRGB step is SMALLER (1/255) than a StudioRGB step (1/219) over the valid normalized data range. Patches edges, or otherwise. In either case 8 bits has been established to provide step sizes smaller than the HVS threshold. Otherwise, video wouldn't really work for us.

The step size if you skip a code is twice as large. That is extremely likely to become visible. One might even say with certainty that it necessarily WILL become visible. I can't fathom how you can ignore this. Wait, I can fathom it. You don't care at all about what's really going on, you just want to continue to jerk people around.

Quote:
This is the mach band phenomena, No? It is an HVS optical illusion. I mentioned that I suspected this is a source for much of the banding ballyhoo earlier. No difference between StudioRGB and sRGB that I can reason. Do the larger and coarser steps of StudioRGB somehow suppress this illusion?

I already covered this. Thank you for completely ignoring it.

If you re-map to a slightly larger range but stay in 8-bit, YOU END UP SKIPPING CODES IN THE NEW RANGE. This causes luminance deltas TWICE as large as they normally would be with smooth step-by-step changes, and 8-bit being the bare minimum to keep these things below the visible threshold simply is not enough when you start skipping codes. This causes visible banding/contouring in the image.

Trying to pass this off as some kind of optical illusion only is the height of ignorance and misinformation.
ChrisWiggles is offline  
post #204 of 246 Old 03-06-2007, 06:13 PM
Senior Member
 
Charles Black's Avatar
 
Join Date: Sep 2003
Location: Lopez Island, Washington
Posts: 340
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
But not a full screen half and half test? The longer the edge is - the easier it gets.

Krasmuzik,

Why? If it takes a very special circumstance to see this effect and the effect is hidden by dithering how would you design a study that used common DVD/HD movie scenes to show the problem? Common video from a DVD/HD movie would seem to be the ultimate ditherer after all!

Charlie
Charles Black is offline  
post #205 of 246 Old 03-06-2007, 06:14 PM
 
ChrisWiggles's Avatar
 
Join Date: Nov 2002
Location: Seattle
Posts: 20,730
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 15
Quote:
Originally Posted by krasmuzik View Post

A sRGB step is LARGER than a StudioRGB step on the occasion when the math don't work to stuff lesser number of values into more values. Mostly because of the uneveness of the stepping in the edge detection - the gradient will not look smooth. There are many natural images that consist of smooth gradients - and it is the uneven gradient that feels unnatural that the eye is testing.

You indeed can see the larger steps in ramp patterns - maybe not on a tiny analog CRT - but throw up single chip DLP 10' wide - you can absolutely see it. Most people running digital projection are using StudioRGB with their HTPC for this very reason. We have done local testing at AVS meets on properly calibrated sRGB vs. StudioRGB - you most certainly can see the differences (with YCbCr sources)

Kras is absolutely correct. Indeed the delta is almost TWICE as large. This is a serious problem because 8-bit has almost no fudge room, if you start skipping codes like this, you WILL get banding problems, I can guarantee it.
ChrisWiggles is offline  
post #206 of 246 Old 03-06-2007, 06:19 PM
AVS Special Member
 
dlarsen's Avatar
 
Join Date: Mar 2001
Location: Beaverton, OR, USA
Posts: 1,908
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by krasmizic View Post

We have done local testing at AVS meets on properly calibrated sRGB vs. StudioRGB - you most certainly can see the differences (with YCbCr sources)

Were the comparisons done on DLP's viewing mathematically pure step-ramp test patterns or with real-world images on non banding-inherent display technologies. Double-Blind? If that's that case, then I really don't understand why Charles and I don't see banding problems in our real world images.

Dave
dlarsen is offline  
post #207 of 246 Old 03-06-2007, 06:21 PM
AVS Addicted Member
 
krasmuzik's Avatar
 
Join Date: Oct 1999
Location: NewPort, VA
Posts: 11,270
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by dlarsen View Post

This is another area I've mentioned specific to DLP. DLP has it's own build it banding issues relation to the PWM sequences. They move (as does your perception of it) as levels change. To say you are veiwing StudioRGB levels on a DLP (or any digital) can be kinda an oxymoron to me as well. You may be feeding it only the 7.79 bits but it doing a similar bit expansion internal. Those levels aren't gonna be maintained (unless you severky throttle back B/C). It going to get expaned to more bits and the same non-monotinic level steps will occur. If you perceive banding on a DLP, I suggest you'll perceive similar banding even when viewing a true, monotic step pattern and they will move as you change levels.

Dave

As I said - DLP typically has 10b panel - this does not have a 1step error like 8b - it will be a 1/4step error. The closer you are to a true gradient rather than a staircase with uneven steps - the better. I am a damn good calibrator - I get the same max contrast ratio regardless of sRGB or StudioRGB or YCbCr or VGA or YPbPr as my source.

Do the same L* math with 8b-10b-12b sRGB vs. StudioRGB from 8b YCbCr. Reviewers have noted on the cheapest DLP that appear to have an 8b digital path to the panel - that they saw banding they do not see on spendier DLP with a 10b path.
krasmuzik is offline  
post #208 of 246 Old 03-06-2007, 06:27 PM
AVS Special Member
 
dlarsen's Avatar
 
Join Date: Mar 2001
Location: Beaverton, OR, USA
Posts: 1,908
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by ChrisWiggles View Post

Kras is absolutely correct. Indeed the delta is almost TWICE as large. This is a serious problem because 8-bit has almost no fudge room, if you start skipping codes like this, you WILL get banding problems, I can guarantee it.

Again, you don't skip any codes that were encoded in the source. They all find a home and are represented. None are skipped.

Dave
dlarsen is offline  
post #209 of 246 Old 03-06-2007, 06:27 PM
AVS Addicted Member
 
krasmuzik's Avatar
 
Join Date: Oct 1999
Location: NewPort, VA
Posts: 11,270
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by Charles Black View Post

Krasmuzik,

Why? If it takes a very special circumstance to see this effect and the effect is hidden by dithering how would you design a study that used common DVD/HD movie scenes to show the problem? Common video from a DVD/HD movie would seem to be the ultimate ditherer after all!

Charlie

Inherently film grain is dither as well - it is most noticeable on PixelWorks CGI releases if you use sRGB 8b input instead of StudioRGB 8b.
krasmuzik is offline  
post #210 of 246 Old 03-06-2007, 06:34 PM
 
ChrisWiggles's Avatar
 
Join Date: Nov 2002
Location: Seattle
Posts: 20,730
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 15
Quote:
Originally Posted by dlarsen View Post

Again, you don't skip any codes that were encoded in the source. They all find a home and are represented. None are skipped.

Dave

No, you skip codes in the NEW range.

I speak other languages. If you would prefer, I could explain this to you in a different language.
ChrisWiggles is offline  
Reply Display Calibration

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off