Was only 8 bit color a mistake? - Page 5 - AVS Forum
Forum Jump: 
Reply
 
Thread Tools
post #121 of 128 Old 10-26-2009, 08:17 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,482
Mentioned: 9 Post(s)
Tagged: 0 Thread(s)
Quoted: 70 Post(s)
Liked: 140
Quote:
Originally Posted by yesgrey3 View Post

Your example does not apply to what I was saying for two reasons:
1) In what I was saying, the idea of using format (b) to store the data from (a) is to later convert it back to (a).

The idea of converting back and forth between two formats in a lossless way is nice, but this is not the situation we're talking about here:

(1) Original content is RGB.
(2) Studio converts to YCbCr.
(3) Studio subsamples Chroma.
(4) Studio applies lossy compression.
(5) Playback device uncompresses.
(6) Playback device upsamples Chroma.
(7) Playback device converts to RGB.

There's so much processing going on between formats (a) and (b) that this can never be even near to lossless. Which means that it's crucial that every processing step is done as good as possible, in terms of the *cumulative error*. Which means, dithering MUST be used, if you care about quality at all, even if RGB bitdepth is 8bit and YCbCr bitdepth is 10bit.

The situation might be different if you convert back and forth between (a) and (b) without ever doing any actual processing on the data. But there's no sense in doing that. And as soon as you process in format (b) and then convert back to format (a), you are in danger of losing quality if you have used rounding instead of dithering.

Quote:
Originally Posted by yesgrey3 View Post

If you use dither, there is a chance that you could never get back to (a).

Which is not a problem at all, since this is all not lossless, anyway, due to lossy compression and chroma subsampling. We only have to keep the cumulative error as small as possible.

Quote:
Originally Posted by yesgrey3 View Post

Do you see that you could just produced a gigantic distortion of (a)

Nope. With my example, you have to use dithering both ways. Which means that 1/3 would become either 0.0 or 0.5. And 2/3 would become either 0.5 or 1.0. In other words, the final result would have about 25% 0.0 pixels, 50% 0.5 pixels and 25% 1.0 pixels. The cumulative error would still be near zero. Just the noise has increased. Which is exactly how dithering works. Ok, with my example the dithering noise is so high it's not funny. But this example is intentionally chosen with extreme values to make things clearer. Of course in real life dithering noise is so low that it's not visible to the naked eye.

Now let's get one step further: Imagine the data gets processed in format (b) by an algorithm which raises brightness of each value by one step. 0.0 becomes 1/3. 1/3 becomes 2/3. 2/3 becomes 1.0. 1.0 clips to 1.0. If you go (a) -> (b), then run this brightness increase algorithm, then go back to (a), if you use rounding, you'll end up with all pixels definitely being 1.0. If you use dithering, exactly the right amount of pixels would be 0.5 instead of 1.0, so that the overall brightness of the data would be 0.5 + 1/3 = 0.833333. (Or slightly higher than that, due to clipping).

Quote:
Originally Posted by yesgrey3 View Post

2)Your example does not mimic which happens in RGB->YCbCr conversion. The values in (a) are the same as in (b), but in RGB->YCbCr the values in both spaces are completelly different.

Doesn't matter at all. We don't disagree on how to do RGB -> YCbCr conversion. We only disagree on how to convert floating point YCbCr to 10bit integer YCbCr. You want to use rounding. I advertize dithering. And there IMHO my example fits quite well (although of course it's grossly simplified)...
madshi is offline  
Sponsored Links
Advertisement
 
post #122 of 128 Old 10-26-2009, 09:35 AM
Senior Member
 
yesgrey3's Avatar
 
Join Date: Jul 2004
Posts: 331
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by yesgrey3 View Post

The conversion from 8bit RGB -> 10bit YCbCr does not create any new values, is simply a 1:1 mapping between different spaces.

Quote:
Originally Posted by madshi View Post

There's so much processing going on between formats (a) and (b) that this can never be even near to lossless. Which means that it's crucial that every processing step is done as good as possible, in terms of the *cumulative error*. Which means, dithering MUST be used, if you care about quality at all, even if RGB bitdepth is 8bit and YCbCr bitdepth is 10bit.

I agree that dithering MUST be used in every processing step that "creates" new data that did not exist in the previous step, or when the following step does not have enough precision to hold completelly the previous data.
This only happen for sure in steps (3), (4) and (6). In steps (2), (5) and (7), if the following step has enough resolution to hold the processed values dithering must not be used, instead we must use 1:1 mapping.
If the entire processing chain was lossless, only 1:1 mapping would be used.
It's not, so, let's use dithering only where 1:1 mapping cannot be used, or we will make it worse.

Quote:
Originally Posted by madshi View Post

We only disagree on how to convert floating point YCbCr to 10bit integer YCbCr. You want to use rounding. I advertize dithering.

No. As I explained above, we disagree because you want to consider the 8bit RGB to 10bit YCbCr conversion as any other kind of processing that "creates" new data, and I do not. This process only converts a group of values into another group of values of the exact same dimension, a 1:1 mapping, and if we use dithering in a 1:1 mapping process, then it's not a 1:1 mapping process anymore.
What you are saying is the same as dithering a 1920x1080 8bit RGB image right before sending it to a 1920x1080 10bit display. You will only add noise.
yesgrey3 is offline  
post #123 of 128 Old 10-26-2009, 09:59 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,482
Mentioned: 9 Post(s)
Tagged: 0 Thread(s)
Quoted: 70 Post(s)
Liked: 140
Quote:
Originally Posted by yesgrey3 View Post

you want to consider the 8bit RGB to 10bit YCbCr conversion as any other kind of processing that "creates" new data

Where did I say that?

Look, dithering theory is really simple: Whenever you reduce bitdepth, you use dither. It's as simple as that.

Quote:
Originally Posted by yesgrey3 View Post

What you are saying is the same as dithering a 1920x1080 8bit RGB image right before sending it to a 1920x1080 10bit display. You will only add noise.

Going from 8bit RGB to 10bit RGB means we're increasing bitdepth. By definition dither isn't needed in that case.

But if you go from floating point YCbCr to 10bit integer YCbCr, you do reduce bitdepth. The proof is simple: If you convert the 10bit integer YCbCr back to floating point, you will end up with different floating point numbers than you started with. Ergo: Bitdepth reduction -> dither.
madshi is offline  
post #124 of 128 Old 10-26-2009, 10:41 AM
AVS Addicted Member
 
amirm's Avatar
 
Join Date: Jan 2002
Location: Washington State
Posts: 18,375
Mentioned: 4 Post(s)
Tagged: 0 Thread(s)
Quoted: 981 Post(s)
Liked: 547
FYI, I was going to pick on the same point Madshi did yesterday but let it go . Net, net, he is right and the rule is much simpler than you are assuming as he explained. See more below.
Quote:
Originally Posted by yesgrey3 View Post

No. As I explained above, we disagree because you want to consider the 8bit RGB to 10bit YCbCr conversion as any other kind of processing that "creates" new data, and I do not. This process only converts a group of values into another group of values of the exact same dimension, a 1:1 mapping, and if we use dithering in a 1:1 mapping process, then it's not a 1:1 mapping process anymore.

Again, looking at whether we have enough input our output sample points it not the only deciding factor as to whether we dither or not (my clarification to your previous argument). But rather, whether at any time during conversion, you wind up with more accuracy than you are representing in the output.

Let's look at a simple example. Let's say I have an audio system which has integer levels from 0 to 100. I then add a digital volume control to it and set that to 0.3 and the input value is 3.0. The gain stage multiplies 0.3 by 3 and gets 0.9. Do you think you should dither or not? Note that I have not changed anything as far as the number of inputs and outputs. We still have a scale of 0 to 100 regardless.

The answer is of course we have to dither. Otherwise, you get the bad sound that digital volume controls are known for.

So to the extent you are going to generate fractional results as you showed in your example to me, you must dither. 87.67488737487 or whatever the value is, cannot be represented in 10 bits any more than it is in 8 bits. Both are whole integer numbers and can't hold the fractions in that floating point value.

Quote:


What you are saying is the same as dithering a 1920x1080 8bit RGB image right before sending it to a 1920x1080 10bit display. You will only add noise.

Let's look at this example.

Assume we have a ramp in the smaller space that goes from 0 to 10: That would give us:
0 1 2 3 4 5 6 7 8 9 10

Now let's say we double the number of steps in a new space. If we just map them as is, here is what we get:

0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10

Does this look right to you? If the display properly shows all the new levels, do you think you still have a smooth ramp?

Amir
Retired Technology Insider
Founder, Madrona Digital
"Insist on Quality Engineering"
amirm is online now  
post #125 of 128 Old 10-26-2009, 10:47 AM
Senior Member
 
yesgrey3's Avatar
 
Join Date: Jul 2004
Posts: 331
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by madshi View Post

Where did I say that?

You didn't.

Quote:
Originally Posted by madshi View Post

We only disagree on how to convert floating point YCbCr to 10bit integer YCbCr. You want to use rounding. I advertize dithering.

I've found the flaw on my logic, and it wasn't that. I was forgetting that 8bit RGB does not map exactly to 10bit YCbCr.
We can have all the number of colors representable by 8bit RGB represented in 10 bit YCbCr, without loosing any of it, but they will not represent the exact same colors, because that would be lost during the rounding process. If no further processing ocurred in the 10 bit YCbCr before we converting back to 8bit RGB, then it would be better not dithering, because due to the rounding being performed the same way back, the exact colors would be retrieved, but that's not what's happening, so we should dither.

I'm very sorry if I have confused anyone...

Edit: amirm, as you probably will see, I already discovered where was my flaw before your post... Thanks anyway.
yesgrey3 is offline  
post #126 of 128 Old 10-26-2009, 11:41 AM
Senior Member
 
yesgrey3's Avatar
 
Join Date: Jul 2004
Posts: 331
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by amirm View Post

Let's look at this example.
Assume we have a ramp in the smaller space that goes from 0 to 10: That would give us:
0 1 2 3 4 5 6 7 8 9 10
Now let's say we double the number of steps in a new space. If we just map them as is, here is what we get:
0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10
Does this look right to you? If the display properly shows all the new levels, do you think you still have a smooth ramp?

When I said 1:1 mapping, I was not saying bit:bit mapping, like you are doing in your example. In your example, you decrease the dynamic of the original signal. The bigger bit depth increases level resolution, not the highest and lowest values.
yesgrey3 is offline  
post #127 of 128 Old 10-26-2009, 03:01 PM
AVS Addicted Member
 
trbarry's Avatar
 
Join Date: Jan 2000
Location: Gainesville FL USA
Posts: 10,138
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by madshi View Post

Where did I say that?

Look, dithering theory is really simple: Whenever you reduce bitdepth, you use dither. It's as simple as that.

Sort of agreed but really dither is useful any time the answer cannot be represented exactly in the target system. For instance working in 16 bit color doing a simple average of two adjacent pixels values for whatever reason the answer could come out to something and a half and it could be beneficial to dither it. Doing so would both decorrelate errors (hide banding) and also reduce the error of the average in any area.

I'm not sure whether your wording was already intended to cover that case.

- Tom

Why don't we power our electric cars from greener, cheaper Liquid Fluoride Thorium Reactors?

Tom Barry - Find my video filters at www.trbarry.com
trbarry is offline  
post #128 of 128 Old 10-26-2009, 03:11 PM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,482
Mentioned: 9 Post(s)
Tagged: 0 Thread(s)
Quoted: 70 Post(s)
Liked: 140
Quote:
Originally Posted by trbarry View Post

Sort of agreed but really dither is useful any time the answer cannot be represented exactly in the target system. For instance working in 16 bit color doing a simple average of two adjacent pixels values for whatever reason the answer could come out to something and a half and it could be beneficial to dither it. Doing so would both decorrelate errors (hide banding) and also reduce the error of the average in any area.

You're right, of course. Personally, I like the idea of running all processing algorithms in the highest bitdepth your hardware can handle, ideally 32bit or even 64bit floating point, and then to dither down to the target bitdepth as the last step. This way you don't have to dither during processing, but only once at the end of the processing chain.
madshi is offline  
Reply HDTV Software Media Discussion

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