Was only 8 bit color a mistake? - Page 5

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.


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.


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).


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)...

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.


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.

Where did I say that?

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


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.

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.

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.


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?

You didn't.


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.

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.

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

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.