gamut conversions through Avisynth ?

[madshi]

I think it will be more clear with an example. Feel free to correct me if anything is wrong.;)
Let's see how it would be done using the method "same chroma for all pixels":
Let's call CbCr in Y'CbCr as C' and CbCr in YCbCr as C.
In Y'CbCr 4:2:0 we have Y'11, Y'12, Y'21, Y'22, and we have C'11.
The current method is doing C'12=C'21=C'22=C'11;
What I was proposing was:
-Use a Y'CbCr->YCbCr 3D LUT to find:
Y12=3dlut(Y'12,C'11)
Y21=3dlut(Y'21,C'11)
Y22=3dlut(Y'22,C'11)
C11=3dlut(Y'11,C'11)
-do C12=C21=C22=C11
-Use a YCbCr->Y'CbCr 3D LUT to find:
C'12=3dlut(Y12,C12)
C'21=3dlut(Y21,C21)
C'11=3dlut(Y22,C22)
-Use original Y'11,Y'12,Y'21,Y'22,C'11 with calculated C'12, C'21, C'22.
So, we have to perform two chroma upsamplings. One upsampling when converting Y'C' -> YC because to find the Y values through the 3D LUT we need a C' value. Another when doing it in YCbCr.
The problem with this approach is that you're using the worst chroma upsampling filter possible. Using "C12=C21=C22=C11" is really bad. This will definitely look worse than the best we can do right now.

How about this instead:

(1) Create image A (1080p 4:4:4): Do the best quality chroma upsampling we can do on the original unprocessed source to get a Y'CbCr 4:4:4 image.
(2) Create image B (540p 4:4:4): Downsample Y' to quarter resolution, but keep chroma unchanged. This way we get a Y'CbCr 4:4:4 image, too, but with a quarter of the pixels.
(3) Convert both images (1) and (2) to YCbCr.
(4) Combine the Y from image (1) and CbCr from image (2). This should give us 1080p YCbCr 4:2:0.
(5) Do the best quality chroma upsampling we can do to convert (4) to YCbCr 4:4:4.
(6) Finally run this through 3dlut to correct gamut etc...

If possible we should avoid 3dlut until the final step to keep bitdepth as high as possible. Steps (1) to (5) should be done in floating point. Step (6) should use trilinear interpolation, so that we can make full use of the full bitdepth data we ended up with.

Of course this would be quite CPU consuming, but I think that should give the best results?

[yesgrey]

The problem with this approach is that you're using the worst chroma upsampling filter possible.
I used the simplest only to describe the idea more easilly, that was my only intent. We could use whatever filter we want.:)
Now, for the first upsampler, since we will use it just for calculating the Y values, maybe we could use that, and use a better one only for the chroma upsampling in YCbCr.
I'm just thinking lowd.

[madshi]

I used the simplest only to describe the idea more easilly, that was my only intent. We could use whatever filter we want.:)
Now, for the first upsampler, since we will use it just for calculating the Y values, maybe we could use that, and use a better one only for the chroma upsampling in YCbCr.
I'm just thinking lowd.
I don't think your approach works correctly. What do you think about my alternative suggestion (see my edited previous post)?

[yesgrey]

I don't think your approach works correctly. What do you think about my alternative suggestion (see my edited previous post)?
Your suggestion is almost the same as mine. The only difference is that instead of using Y'11 to convert CbCr to the linear domain you prefer using the subsampling of Y'11, Y'12, Y'21, Y'22.
I think there would be almost no difference between the results of our suggestions... mine will be slightly faster because avoids the Y' subsampling, and the quality would depend of the kind of chroma subsampling that was done in the source.
Of course I would prefer using float or double to perform all the calculations, but that would be very heavy to the cpu, unless we start thinking in using the GPU, which is very indicated for this kind of work... CUDA or OpenCL.;) it would also be great for the 3D LUT usage, because the Video card memory is a lot faster than the main memory.:)

[tritical]

This idea doesn't make any sense to me. If you start with a 4:2:0 Y'CbCr source (I'm going to designate this Y'Cb'Cr' to avoid confusion), then Cb'/Cr' were downsampled after having been calculated from R'G'B'. The more accurately you recompute the Cb'/Cr' of each Y', the closer you will get to the original. Why do you think it is better to recalculate those Cb'/Cr' values by transforming into YCbCr (using some method to estimate Y' at each chroma point if chroma placement does not line up with Y'), then upsampling Cb/Cr, and then transforming back to Y'Cb'Cr' using the upsampled Cb/Cr and Y values computed from combining the upsampled Cb'Cr' with stored Y'... as opposed to simply upsampling (interpolating in) Cb'/Cr'?

[madshi]

@tritical, you're probably right. I was thinking that chroma has been downsampled in linear light, while actually it most probably has been downsampled gamma corrected. So if it was downsamples that way, we should probably also upsample it that way.

FWIW, I've emailed the author of the article and asked for his opinion about this and also about his opinion on how to do best quality chroma upsampling. Here's his reply:

The very highest quality would come from either:
a- A pretty blurry reconstruction filter, something like a Gaussian blur/filter. We are not very good at spotting the loss of chroma resolution.
Don't use anything with negative lobes for chroma reconstruction if you are at the very end of the signal chain... this will cause colored ringing and looks bad.

You'd always want to do in-range chroma reconstruction, and for that to work perfectly you have to match your filters when you encode + decode the material (in practice this will never happen... people just do whatever when downsampling the chroma).
b- From a practical POV, I would just use triangle filters. This might get the chroma siting for 4:2:0 MPEG2 wrong... I'm not sure about that.

2- I don't believe you can do the upsampling in linear light if you start off with Y'CbCr data. That information is already thrown away I think.

3- In practice, you will likely have illegal values coming into your decoder. e.g. Y' at white level but Cb and Cr aren't neutral (so some of the channels will exceed white level), or Y' above white level with non-neutral Cb and Cr.

So when doing in-range chroma reconstruction, you have to relax the triangle weighing function as a compromise. That's how I would deal with that.

4- There may be other kinds of signal processing that yields more visual improvement than in-range chroma reconstruction. Very few people notice this stuff. Getting rid of macroblocking and deinterlacing artifacts would be my first priority.

Also see Stacey Spears and Don Munsil's article on the chroma bug... I believe I've linked to it from my article.
I see 2 things worth mentioning:

(1) Bicubic upsampling is probably not better than linear upsampling, because bicubic rings while linear upsampling doesn't ring.

(2) Not sure about the "illegal values". Do you think there's anything we could/should do there?

[yesgrey]

Why do you think it is better to recalculate those Cb'/Cr' values by transforming into YCbCr...
(2) Not sure about the "illegal values". Do you think there's anything we could/should do there?
According to the paper, I think this could be better but only for the out of range values. For all the other values, I think the current upsampling method is better.
Since the out of range values are not many (except in some particular images), I think it's not worthy having all that trouble. If in the future, we have some free time, maybe we could take a look for curiosity, but probably the differences could only be noted in special images created only for showing the problem, like the one in the paper.;)

[yesgrey]

(1) Bicubic upsampling is probably not better than linear upsampling, because bicubic rings while linear upsampling doesn't ring.
Testing it with yv12toyuy2 tritical's function, the bicubic looks better than the linear. To avoid ringing, is just keeping c<0.6 (according to Avisynth's manual description of Bicubic Resize filter). I use b=0 and c=0.5 (tritical, IMHO these should be the default values)

[madshi]

Any news about cr3dlut v2? :)

[yesgrey]

I will try to release it during the weekend...

[yesgrey]

I've just released here (http://yesgrey3.totalh.com/) cr3dlut v2.0.
v2.0 - 2009/03/23
- Added: creation of 3D LUT for R'G'B' -> Y'CbCr conversion chain
- Added: creation of 3D LUT for Y'CbCr -> Y'CbCr conversion chain
- Added: chromatic adaptation method using Bradford Transform (Chromatic_adaptation 2)
- Added: new run parameters "Input_Video_Format" and "Output_Video_Format"
- Added: new run parameters "Input_Bit_Depth" and "Output_Bit_Depth"
- Changed: renaming of the run parameters
- Changed: perform color gamut conversion only when the color gamuts are different (speed gain)


I've tryed to make it a little more user friendly.
Please note that some of the new functionalities are not usable, because are not supported by rgb3dlut. We have to wait for tritical's t3dlut to use it, but I don't know when (or if) it would be released...

Comments/suggestions are welcome.

[leeperry]

looks good I'll look into it, thanks!

BTW, 10 bit might appear sooner than you'd think :
http://www.amdzone.com/index.php/news/37/8998-nvidia-geforce-8200-hdmi-13-compliant

[madshi]

I've just released cr3dlut v2.0.
Thanks!!

[yesgrey]

The first time I've read this (http://www.poynton.com/papers/Discreet_Logic/index.html) Charles Poynton's article was a big surprise to me. I never thought that all our sources that claim to be 8bit per color component were in fact 8bit per color component but with lots of holes inside, kind of a swiss cheese.
When I started developing cr3dlut, this idea came through my mind and now I've decided to use cr3dlut's code to perform some "measures" and give me a better idea of it.
I simply have put some counters inside the code to count the number of colors that we could get when converting between the two representations commonly used: YCbCr and RGB. I also tryed different combinations, with different levels and different bit depths at both sides. I'm sure the results I will post here are nothing new to some of you, but I'm sure they will be for others.;)
I have decided to use the word "color" instead of the correct term "codeword", and the terms RGB and YCbCr instead of the correct R'G'B' and Y'CbCr, to simplify the understanding of the results to the less technical of us.
The "n. of available colors", is all the colors that could be represented using the ranges indicated.
The "n. of valid colors", is all the colors in the source representation that are within the ranges of the target representation.
The "n. of different colors obtained", is all the different colors that are obtainable in the target representaion. Some different colors in the source representation could correspond to the same color in the target representation.
For these tests, I have used BT.709 coefficients for the YCbCr<->RGB conversions.


YCbCr->RGB Standard Conversion

YCbCr(8bit) n. of available colors: 11 137 500 (Y: 16-235; CbCr: 16-240)
RGB (8bit) n. of available colors: 10 648 000 (RGB: 16-235)
YCbCr n. valid colors: 2 689 427
RGB n. of different colors obtained: 2 689 427 (25.3%)
---
YCbCr(9bit) n. of available colors: 88 502 839 (Y: 32-470; CbCr: 32-480)
RGB (8bit) n. of available colors: 10 648 000 (RGB: 16-235)
YCbCr n. valid colors: 21 515 482
RGB n. of different colors obtained: 10 595 662 (99.5%)


YCbCr->RGB Full Conversion

YCbCr(8bit) n. of available colors: 16 777 216 (Y: 0-255; CbCr: 0-255)
RGB (8bit) n. of available colors: 16 777 216 (RGB: 0-255)
YCbCr n. valid colors: 4 058 320
RGB n. of different colors obtained: 4 058 320 (24.2%)
---
YCbCr(9bit) n. of available colors: 134 217 728 (Y: 0-511; CbCr: 0-511)
RGB (8bit) n. of available colors: 16 777 216 (RGB: 0-255)
YCbCr n. valid colors: 32 657 781
RGB n. of different colors obtained: 16 702 766 (99.6%)

From these numbers, we can see that our current sources that use YCbCr(8bit) are our limiting factor. We would need YCbCr(9bit) to be able to use our current displays RGB(8bit) at its full potential...

This could raise one question: If the RGB(8bit) is not used at its full potential, would we really need or benefit of higher bit depths in our displays, like the new RGB(16bit) that we should get with Windows7?
Let's look at some more numbers...

RGB->YCbCr Standard Conversion

RGB (8bit) n. of available colors: 10 648 000 (RGB: 16-235)
YCbCr(8bit) n. of available colors: 11 137 500 (Y: 16-235; CbCr: 16-240)
RGB n. valid colors: 10 648 000
YCbCr n. of different colors obtained: 2 809 180 (25.2%)
---
RGB (10bit) n. of available colors: 674 526 133 (RGB: 64-940)
YCbCr(8bit) n. of available colors: 11 137 500 (Y: 16-235; CbCr: 16-240)
RGB n. valid colors: 674 526 133
YCbCr n. of different colors obtained: 2 828 080 (25.4%)
---
RGB (11bit) n. of available colors: 1 092 017 481 (RGB: 16-235)
YCbCr(8bit) n. of available colors: 11 137 500 (Y: 16-235; CbCr: 16-240)
RGB n. valid colors: 1 092 017 481
YCbCr n. of different colors obtained: 2 831 230 (25.4%)

From these numbers, we can see that no matter the bitdepth of the RGB, if the YCbCr bitdepth is 8bit per component, we will get almost no benefit by increasing the RGB bitdepth.

The question above has more than one answer.
If we watch our sources at its original resolutions and without any kind of processing, the answer is no, we do not need more than 8bit per component in our displays.
If we scale our sources to match our display's resolution or if we perform any kind of processing in YCbCr(<10bit), the answer is no, we do not need more than 8bit per component in our displays.
If we scale our sources to match our display's resolution or if we perform any kind of processing in YCbCr(>9 bit) or in RGB(>8 bit), then the answer may be yes, we could benefit of more than 8bit per component in our displays...

Now a question that is asked so many times: Should we convert from YCbCr->RGB using standard (16-235->16-235) levels or expanding (16-235->0-255) levels?
Let's look at a few more numbers...


YCbCr->RGB Expanding Conversion

YCbCr(8bit) n. of available colors: 11 137 500 (Y: 16-235; CbCr: 16-240)
RGB (8bit) n. of available colors: 16 777 216 (RGB: 0-255)
YCbCr n. valid colors: 2 689 427
RGB n. of different colors obtained: 2 689 427 (16.0%)
---
YCbCr(9bit) n. of available colors: 88 502 839 (Y: 32-470; CbCr: 32-480)
RGB (8bit) n. of available colors: 16 777 216 (RGB: 0-255)
YCbCr n. valid colors: 21 515 482
RGB n. of different colors obtained: 15 997 163 (95.4%)
---
YCbCr(10bit)n. of available colors: 705 642 093 (Y: 64-940; CbCr: 64-960)
RGB (8bit) n. of available colors: 16 777 216 (RGB: 0-255)
YCbCr n. valid colors: 172 122 708
RGB n. of different colors obtained: 16 777 200 (99.9999%)


Comparing the numbers of the Standard and the Expanding conversions, we can see that the n. of different colors is the same, but there is a significative difference between the two conversions, the "color density".
We can see that the standard conversion has the colors confined to a narrower range, so the colors have a smoother transition between them, which will show as less banding in color transitions.

[yesgrey]

I know that it could be a bit shocking that we are getting much less colors (less than 25%) that we usually think. So, to be able to see it this is true, I've created a 3DLUT file that will output as red pixels all the invalid colors specifyed in the numbers above. I've used the Full Conversion, so we could also be able to see if there are any colors outside the standard (16-235) range.

The first picture, was considering only the valid values contained in the standard (16-235) RGB values.
The image has a few red points. These points could be some of the measured invalid colors above that are valid, or could be valid values that are above the 235 range.
9689

The second picture, was considering the valid values contained in the full (0-255) RGB values. The image does not has any red points, so the points that appeared in the first picture were points above the 235 range.
9688

The pictures above prove that it's true.

[madshi]

That's pretty interesting - thanks!

Some thoughts:

(1) Our eyes are more sensitive to brightness than they are to colors. So I'd say: Screw the colors, they're not *that* important. Probably more important is the brightness gradiant representation ability. Is there a way to measure that? Based on your calculations it seems that using 7bit RGB might already be good enough. But just think of a test pattern which shows a simple grayscale ramp. I think you will agree that using only 7bit RGB would result in noticable banding. This already hints that some of the logic you've used might not be correct. More about this in point (2):

(2) You write "If [...], the answer is no, we do not need more than 8bit per component in our displays." I don't think that is correct. Why? Because I think your logic somehow ignors the fact that doing YCbCr -> RGB conversion results in floating point numbers and not in integer numbers. The "n. of different colors obtained" number is very interesting, but it only tells half the truth. Let me give you a simple example:

Let's say we had a 1bit YCbCr full range source and a 1bit full range RGB display. That would result in:

YCbCr(1bit) n. of available colors: 8 (Y: 0-1; CbCr: 0-1)
RGB (1bit) n. of available colors: 8 (RGB: 0-1)
YCbCr n. valid colors: 8
RGB n. of different colors obtained: 8
Probably the number of valid/different colors would be even less than 8, but let's just pretend they'd be 8 to keep the discussion simple. Now based on the logic you're using 1bit RGB would be all we need, right? *Wrong*. Let's say the valid 8 YCbCr colors map to RGB "(0, 0, 0), (0, 0, 1), (0, 1, 0), (0, 1, 1), (1, 0, 0), (1, 0, 1), (1, 1, 0), (1, 1, 1)". In this case you would be right. But the mapping will not be like that. Instead it will be something like: "(0.0, 0.0, 0.0), (0.1, 0.1, 0.9), (0.2, 0.8, 0.0), (0.1, 0.9, 0.85), (0.95, 0.0, 0.08), (0.9, 0.05, 0.8), (0.9, 0.95, 0.02), (1.0, 1.0, 1.0)".

Do you see the problem? Using only 1bit RGB would result in grossly incorrect display. Using e.g. 12bit RGB output would produce a much more exact display - even though there are only 8 valid YCbCr colors to start with! Ok, we could work around the problem by using dithering. But dithering is always only a workaround. Having higher RGB bitdepth means that we can represent the YCbCr data better without having to do any workarounds.

(3) Already hinted by your post: Any (good quality) scaling will result in intermediate chroma and brightness values, which will "increase" source bitdepth.

IMHO a 16bit output 3dlut should be used and the higher the RGB bitdepth is the better. Only this way we can get near the correct display of the YCbCr source. The number of different valid colors doesn't matter. The exactness of the representation does! Even if you only have a low number of valid colors to start with, having to round RGB data might result in banding to appear/increase which would be less visible if more correct RGB colors would be used. Just think of a RGB gradiant of (80.0, 82.5, 85.0). With 8bit RGB you'd have to round that to (80, 83, 85). With 9bit RGB you could properly display the gradiant as (80.0, 82.5, 85.0). The 9bit RGB display would show a more evenly distributed gradiant compared to the 8bit RGB display.

[FoLLgoTT]

Do you see the problem? Using only 1bit RGB would result in grossly incorrect display. Using e.g. 12bit RGB output would produce a much more exact display - even though there are only 8 valid YCbCr colors to start with! Ok, we could work around the problem by using dithering. But dithering is always only a workaround. Having higher RGB bitdepth means that we can represent the YCbCr data better without having to do any workarounds.

Very interesting!

Let me think about this. Let's assume the master was already converted to 8bit RGB (from e.g. 12 bit). So when converting to YCbCr we get floating point numbers which are rounded to integer values. Now the data is getting reduced by the MPEG encoder.
While playing back the video the conversion YCbCr->RGB again results in floating point numbers which have to be rounded to 8 bit integer. Who guarantees that both rounding methods are the same? Maybe the first is a floor and the second a ceiling function as a worst case example. Is it even possible to correctly reconstruct the 8 bit RGB values?

[leeperry]

for what it's worth, the Beliyal MPC HC builds apparently support 10bit on Vista :
http://forum.doom9.org/showthread.php?t=145203

w/ nvidia supporting HDMI 1.3 on their latest IGP, and prolly next PCI-E cards...this might be good news ^^

[73ChargerFan]

Let's look at some more numbers...
Code: RGB->YCbCr Standard Conversion

So YCbCr(8)->RGB(8) is a many-to-one map, and the full resolution of RGB(8) isn't utilized in this conversion.

Could you similarly analyze YCbCr(8)->RGB(10) ? Or do you predict the same 4:1 mapping?

[yesgrey]

So YCbCr(8)->RGB(8) is a many-to-one map
No. That is a one-to-one map. If you look closely, we get in RGB the same number of colors that the YCbCr n. of valid colors.
The many-to-one map will only be true for YCbCr(>8bit )->RGB(8bit)

Could you similarly analyze YCbCr(8)->RGB(10) ?
No, I will need lots of memory for doing it, or I would have to use some kind of linked list, which would be too cpu intensive.
Or do you predict the same 4:1 mapping?
Yes. Remember, the limiting factor is the bit depth used in YCbCr, so, no matter what bit depth you use in RGB, you will always get almost the same number of colors. That's the reason I have used RGB(10)->YCbCr(8), which is almost the same thing, and computable.;)
Look at it this way: YCbCr is a much wider representation of colors than RGB, so, it contains RGB entirely in it and still has a lot of free values without any correspondence within the RGB space. If they use the same bit depth, the YCbCr representation of the RGB values will have lower resolution. That's revealed when we see that YCbCr (at the same bit depth of RGB) only can contain <25% of the colors available in RGB.

[madshi]

Let me think about this. Let's assume the master was already converted to 8bit RGB (from e.g. 12 bit). So when converting to YCbCr we get floating point numbers which are rounded to integer values.
Studios sometimes use rounding and sometimes they use dithering. See this very interesting thread:

http://www.avsforum.com/avs-vb/showthread.php?t=1011359

Now the data is getting reduced by the MPEG encoder.
While playing back the video the conversion YCbCr->RGB again results in floating point numbers which have to be rounded to 8 bit integer. Who guarantees that both rounding methods are the same?
First of all "have to be rounded" is not true. We don't have to use simple rounding. The 3dlut logic which was discussed and defined in this thread can optionally do 8bit YCbCr -> 16bit RGB. In this case the floating point RGB data is rounded down to 16bit integer which should be plenty enough precision for our eyes. Still, if the display is only 8bit, those 16bit have to be brought down to 8bit somehow. You can use rounding for that again. Or you can use dithering.

IMHO dithering is a must if you want really faithful image reproduction, because simple rounding introduces too big deviation from the floating point RGB data. Actually the lower the bitdepth of the display, the higher the rounding errors are! So when using 8bit RGB rendering, using dithering is much more important/helpful than when using e.g. 16bit RGB rendering.

yesgrey3's calculations about how many colors YCbCr can code are (most probably) correct. But how many colors YCbCr can code is one thing. How to accurately convert those limited number of colors to RGB is IMHO a totally separate topic. Even if YCbCr only allowed 5 colors to be coded, we still wanted to display them as accurately as possible. And for that purpose using 8bit integer RGB with simple rounding just doesn't cut it IMHO.

[leeperry]

@yesgrey : that's quite striking to read you saying that outputting 8 or 10bit doesn't make much difference...if any, and that we hardly use 25% of the gamut :o

no wonder I couldn't detect any banding on my green-deficient DLP pj :rolleyes:

anyway, Epson finally offers no-brainer gamut conversion:

http://www.hdsoir.com/wp-content/uploads/2009/03/epson-tw5000-gamut-menu.jpg

I'd guess that it works in 10bit too ;)

it comes from this tw5000 test(french link, sorry) :
http://www.hdsoir.com/?p=5700&page=2

ideally over the next years, some 10bit sources will show up(Bluray Reloaded?), HDMI 1.3 graphic cards(already the case w/ nvidia IGP's) and projectors that do conversions internally :devil:

[tetsuo55]

So is this an accurate conclusion?:

-8bit source should look the same on all 8+ panels, no need for higher rgb bitdepth(and judging from the results a good 6bit panel should be able to display all the required colors also)

-A very VERY good dithering, while using a very high bitdepth YCbCr->RGB conversion (minimising the errors into the 0.0000x%) could result in a slightly more realistic looking/colorfull image, while deviating from bitperfectness

We basically have almost 75% of the space left to do all kinds of fun post-processing stuff.

I doubt the results would be the same for luminance though

[tritical]

t3dlut v1.0 (http://bengal.missouri.edu/~kes25c/t3dlut.zip). Readme is a little sparse, and I haven't had time to test it much.

[yesgrey]

Thanks tritical!:)
I will give it a try.

[yesgrey]

If we scale our sources to match our display's resolution or if we perform any kind of processing in YCbCr(<10bit), the answer is no, we do not need more than 8bit per component in our displays.
After some tests using t3dlut, it seems my quote above is true.
I have used t3dlut with 3dlut files with 8bit output and 16bit output dithered to 8bit. You can get some of the files here (http://www.megaupload.com/?d=283EM50Y).
As you can see, the biggest difference between the pure 8bit output files and the 16bit dithered to 8bit output files is the file size.
Looking into the images, we cannot see any difference. We have to zoom a lot to see some slightly differences, and even then we have to look very carefully. I also created a pic with the difference between both images, applyed to a 50% gray screen (I have used avisynth subtract function). Looking into it, it seems to be a plain 50% gray image, but if we use a tool to see the values of each pixel, we can see that several values are different by +/-1.

Conclusion: unless we have higher bit depth sources, or higher bit depth processing, our best bet is keep using the 8bit output 3dlut's. The 16bit output would be just wasting hard disk space...

[tetsuo55]

After some tests using t3dlut, it seems my quote above is true.
I have used t3dlut with 3dlut files with 8bit output and 16bit output dithered to 8bit. You can get some of the files here (http://www.megaupload.com/?d=283EM50Y).
As you can see, the biggest difference between the pure 8bit output files and the 16bit dithered to 8bit output files is the file size.
Looking into the images, we cannot see any difference. We have to zoom a lot to see some slightly differences, and even then we have to look very carefully. I also created a pic with the difference between both images, applyed to a 50% gray screen (I have used avisynth subtract function). Looking into it, it seems to be a plain 50% gray image, but if we use a tool to see the values of each pixel, we can see that several values are different by +/-1.

Conclusion: unless we have higher bit depth sources, or higher bit depth processing, our best bet is keep using the 8bit output 3dlut's. The 16bit output would be just wasting hard disk space...

I see a very subtle difference between the 2 screenshots.

The 16bit version almost seems to have a darker hue in some area's, especially the skin.
In this sample case i like the 8bit version better.

Could be a complete placebo though.

I compared the images on a CRT

[leeperry]

well I've never been convinced by that "16bit is higher precision, then dither back to 8 will look better than plain 8 bit" myself :o

you can't quite create data that's not there, only create additional distorsion/noise. But it's good that it supports 10bit output...I think? maybe not :D

OK I will follow the infos yesgrey3 gave me in PM, and try to make a simple guide coz it's getting kinda confusing w/ the zillion options in the new cr3dlut/t3dlut(thank you tritical BTW!) versions

[yesgrey]

Based on your calculations it seems that using 7bit RGB might already be good enough. ...
This already hints that some of the logic you've used might not be correct.
No, it's not good enough. RGB(7bit) has 78% of the n. of colors available in YCbCr(8bit), and YCbCr will not map into RGB(7bit) like it maps into RGB(8bit).

Let me give you a simple example:

Let's say we had a 1bit YCbCr full range source and a 1bit full range RGB display. That would result in:

YCbCr(1bit) n. of available colors: 8 (Y: 0-1; CbCr: 0-1)
RGB (1bit) n. of available colors: 8 (RGB: 0-1)
YCbCr n. valid colors: 8
RGB n. of different colors obtained: 8
Probably the number of valid/different colors would be even less than 8, but let's just pretend they'd be 8 to keep the discussion simple. Now based on the logic you're using 1bit RGB would be all we need, right? *Wrong*
No, your example is flawed. YCbCr(1bit) only has 2 valid colors in RGB(1bit), so, RGB(1bit) would continue to exceed all our needs (it has 8 colors available), still the <25% rule.;)
I see what you are trying to say, and I agree with you... for less than 8bit depths.:)
With bit depths of 8 and above, it's not too difficult for us to differentiate between two adjacent colors when looked alone. Imagine a full image at RGB[128,128,128] vs a full image at RGB[128,129,128]. If you compare both images switching between them or side by side, you can notice the difference (not very easy though), but if you watch each of them separatelly, you would not be able to tell the difference.
With RGB(1bit), it's easy to spot that difference.
The number of different valid colors doesn't matter. The exactness of the representation does! Even if you only have a low number of valid colors to start with, having to round RGB data might result in banding to appear/increase which would be less visible if more correct RGB colors would be used.
I don't agree with this. Banding is the result of using the same color to represent different colors. The exactness of the representation does not affect this, because it will always exist some "space" between the adjacent colors due to the low number of different valid colors. Also, the exactness of the representation is already damaged by the original conversion from RGB->YCbCr.:(

[yesgrey]

well I've never been convinced by that "16bit is higher precision, then dither back to 8 will look better than plain 8 bit" myself :o
We cannot rule out yet the dither because currently there is no way to see if it's useful or not. Currently, all software that we are using reduces the bit depth to 8bit, so the dithering of 16bit to 8 bit is not used at its full potential, it's only being used in t3dlut for the YCbCr->RGB conversion, nothing more, and as I showed with my previous posts, it could only be useful with other types of processing.

[leeperry]

We cannot rule out yet the dither because currently there is no way to see if it's useful or not.
well I took the analogy of upsampling 44.1 to 96 Khz > process w/ EQ then downsampling to 44.1 again....no added value, only distortion.

but if I understand, what we crave for badly is of course 10bit input, but more importantly 10bit output so the gamut conversion from 8bit wouldn't be so destructive anymore :)

anyway Win7 supports it and the latest nvidia IGP do too, so it should be even usable as we speak :eek: ....too bad I'll be sticking to XP until the end of days, and my HC3100 is not 1.3 compliant anyway :devil:

[madshi]

I don't agree with this. Banding is the result of using the same color to represent different colors. The exactness of the representation does not affect this, because it will always exist some "space" between the adjacent colors due to the low number of different valid colors.
My understanding of the term "banding" is: >> Visible steps in a gradiant. <<

Such banding can be in the original studio master. It can be caused by the encoding. It can be caused by the decoding. It can be caused by the processing, by the color conversion or by the display. I think our eyes are quite sensitive to even small errors in gradiants.

If the YCbCr source has a gradiant which maps to the RGB values e.g. "80.0", "81.5" and "83.0", then each banding step is "1.5" steps away from the next. If you round that, the gradiant steps will be "1" and "2" instead of "1.5" and "1.5". I think such a situation might show as increased banding to our eyes.

But maybe we should stop discussing this topic for now because we don't really have a good way to actually test/proof this. Yet (!).

[madshi]

well I took the analogy of upsampling 44.1 to 96 Khz > process w/ EQ then downsampling to 44.1 again....no added value, only distortion.
That is a very bad analogy.

We are *not* trying to increase the bitdepth of YCbCr data. The part you seem to be missing is that the inevitable YCbCr -> RGB conversion automatically ends up in floating point RGB data. So all Blu-Rays, DVDs and also all broadcasts don't have a bitdepth of 8bit RGB. They have a bitdepth of 8bit YCbCr. The native RGB bitdepth of all these sources is floating point. Say it together with me to make the message sink in: "Decoding and converting Blu-Rays, DVDs and broadcasts to RGB colorspace means we end up with floating point RGB data". And it's a simple mathematical fact that you can't convert floating point data to 8bit integer data without doing violence to the data. Using a higher RGB output bitdepth doesn't mean that we're trying to "upsample" anything. Instead we're trying to minimize the mathematical error caused by converting the floating point RGB data to a format we can transport to the display.

yesgrey3 and I do agree that it's mathematically more correct to use e.g. 10bit RGB output than 8bit RGB output. The only thing we do not agree on is the question whether the mathematical difference will be visible to our eyes.

[leeperry]

Say it together with me to make the message sink in
hehe, OK I tried to say it w/ you, but I dunno if we were in sync :confused:

well you can go "10bit>8 bit" or ">8bit" directly, it won't make the slightest visible difference....or maybe even worsen the roundings(like going 16>14>12>10>8 sure would make things worse :o )

but I'm glad you took the time to correct me, thank you for that!

[yesgrey]

Imagine a full image at RGB[128,128,128] vs a full image at RGB[128,129,128]. If you compare both images switching between them or side by side, you can notice the difference (not very easy though), but if you watch each of them separatelly, you would not be able to tell the difference.
If the YCbCr source has a gradiant which maps to the RGB values e.g. "80.0", "81.5" and "83.0", then each banding step is "1.5" steps away from the next. If you round that, the gradiant steps will be "1" and "2" instead of "1.5" and "1.5". I think such a situation might show as increased banding to our eyes.
yesgrey3 and I do agree that it's mathematically more correct to use e.g. 10bit RGB output than 8bit RGB output. The only thing we do not agree on is the question whether the mathematical difference will be visible to our eyes.
madshi, I agree with stopping the discussion for now until we have a method of testing our claims.;)

I only want to note that we do not disagree. You can see at my quote that it's the same as in yours. When the colors are side-by-side we could notice the difference.
The only thing that I say is that (considering your example) if you look to an image with only the RGB value "81.5" or only the value "82.0", we could not notice any difference in both colors.
Rephrasing it: I agree that the mathematical difference will be visible to our eyes if in a gradient of color. If it's an isolated color, we would not notice it. If we have RGB values "100.0", "81.5" and "63.0", we could not distinguish it from "100.0", "82.0" and "63.0".

[leeperry]

Rephrasing it: I agree that the mathematical difference will be visible to our eyes if in a gradient of color. If it's an isolated color, we would not notice it. If we have RGB values "100.0", "81.5" and "63.0", we could not distinguish it from "100.0", "82.0" and "63.0".
so as long as the source will be 8 bit, there'll be too many pieces of the puzzle missing? but why would 10bit output help then? you don't plan on "debanding" stuff AFAIK

plus some dithered(from the uncompressed source) 8bit would have more pieces than plain 8 bit I think :confused:

oh well, you already answered me on that point, I think it has to do w/ the available "headroom" after the gamut conversion or sumthing :D

well, anyway 8 bit is cool w/ me considering my pj is not 1.3 compliant....I'll recalibrate all my displays and try to get the whole thing to sing :devil:

[madshi]

hehe, OK I tried to say it w/ you, but I dunno if we were in sync :confused:
:)

well you can go "10bit>8 bit" or ">8bit" directly, it won't make the slightest visible difference....
How do you know that? Have you tested it? With a good test pattern (ideally a "slow" gray ramp)?

Rephrasing it: I agree that the mathematical difference will be visible to our eyes if in a gradient of color. If it's an isolated color, we would not notice it. If we have RGB values "100.0", "81.5" and "63.0", we could not distinguish it from "100.0", "82.0" and "63.0".
Agreed.

[leeperry]

@tritical: hi, I was using a test pattern video in ddcc(realtime) and in rgb3dlut() and they definitely don't match :o

it's available here : http://rapidshare.com/files/221027650/rec709.mkv.html

and the results are here : http://forum.doom9.org/showpost.php?p=1273996&postcount=288

am I doing something wrong? I get the same burned up green w/ yesgrey's app in madVideoRenderer and 16bit LUT's..

this is the PS script :

sampler s0 : register(s0);
float4 p0 : register(c0);

static float4x4 r2r =
{
1.15934746091817,-0.152088743917486,0.0260432549966361,0,
0.0250652234853865,0.974389775516909,-0.00709869095234219,0,
0.0100702399922673,0.0548005860451516,0.93638237486273,0,
0, 0, 0, 0
};

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0 = tex2D(s0, tex);
c0 = pow(c0, 1/0.45);
c0 = mul(r2r, c0);
c0 = saturate(c0);
c0 = pow(c0, 0.45);

return c0;
}


and HC3100.txt :

0.151
0.071
0.342
0.610
0.656
0.332
0.311
0.330
1
0.0
0.45
0.0
0.0

:thanks:

How do you know that? Have you tested it? With a good test pattern (ideally a "slow" gray ramp)?
I'm colorblind :D

[yesgrey]

tritical,
I've found what's the problem. I will make some tests and then will post the results here...

[yesgrey]

I've just released here (http://yesgrey3.totalh.com/) cr3dlut v2.1.
v2.1 - 2009/04/17
- Added: new run parameter "Out_Of_Gamut_Clipping"
- Added: chromatic adaptation method using von Kries model in XYZ (Chromatic_Adaptation 3)
- Changed: basic parameter Video_Format settings were renamed
- Changed: basic parameter Video_Format do not clip anymore BTB and WTW when using RGB_Video
- Fixed: RGB->YCbCr was always considering Input_RGB_Black_White 0 255.


This time I've just released the executable. The source code is still v2.0.
This was just an interim version due to a problem described by leeperry. I'm currently working in adding custom gamma curves to cr3dlut, so the source code is still a bit messy. In the next release, I should have time to clean up the source code...

Comments/suggestions are welcome.

[yesgrey]

am I doing something wrong? I get the same burned up green w/ yesgrey's app in madVideoRenderer and 16bit LUT's..
I will make some tests and then will post the results here...
There is no bug.
The problem is that leeperry projector's color gamut is not large enough to contain entirelly the SMPTE-C color gamut, so, when converting between color gamuts, some colors are not representable, because there is no valid mapping inside leeperry's projector color gamut.
When ddcc is working without a 3D LUT, it simply clips the out of gammut colors by rounding the rgb values to the nearest possible. When ddcc works with a 3D LUT, it uses a clipping method that calculates a new color mantaining the hue and saturation of the original color, because the eye is more sensitive to hue variatons than to saturation or luminance variations.
Here are 4 images that show this effect:

The first two are using leeperry projector's color gamut, which is not capable of outputting all colors contained in the SMPTE-C color gamut, more specifically, in the green region. As you could see, the two clipping methods give very different greens corresponding to the most saturated green possible.
9778
9779

The other two, are using my projector's (JVC M15) color gamut, which has a color gamut larger than the SMPTE-C color gamut, so it can maps the entire SMPTE-C color gamut during the conversion. Both clipping methods give the same results.
9780
9781

[leeperry]

ah, so I'm stuck to ddcc in realtime/the PS script? they output perfect colors on my green deficient HC3100.

in the past, you've proved that 8bit movies were hardly using 25% of the gamut anyway, so these most saturated green tints are hardly ever used IRL..I haven't noticed any banding anyway, and clipping's fine(most DLP's exhibit a lack of green) :o

even the interim cr3dlut version you gave me gives too saturated red against ddcc/the PS script, but that's OK! because I'm color blind on the red, I'm very happy w/ the colors actually :cool:

to answer your PM, no I wasn't kidding...I'm truly color blind. there's many types of color blindness, mine is mostly red-based, basically my gamut is a lot less refined than "normal" people.
I see colors differently, just for fun I should add that the Army uses color blind ppl to see camouflage normal ppl can't see...we have a complete different perception of colors. growing older, my brain has learned to "compensate" somehow for the lack of red cones in my eyes :devil:

that's why I'm very sensitive to colorimetry, "proper" colors look natural, slightly wrong colors look artificial...it's a case of all black/all white, no "in between" if you get my drift

anyway I'll try the new build http://forum-images.hardware.fr/images/perso/athome.gif

PS: I only see 25 and 56 on this url: http://www.toledo-bend.com/colorblind/Ishihara.asp

I can hardly guess 29, but can't really see it..

[cyberbeing]

The gamma clipping setting is broken.

Error! Invalid Keyword setting: Out_Of_Gamut_Clipping 1

[yesgrey]

The gamma clipping setting is broken.
Error! Invalid Keyword setting: Out_Of_Gamut_Clipping 1
No, it's working; it was just the testing that was broken - the dangers of the "Copy & Paste"... ;) You were using Chromatic_Adaptation 2.

I've made a silent update. Please re-download the pack again.

Thanks.

[yesgrey]

even the interim cr3dlut version you gave me gives too saturated red against ddcc/the PS script, but that's OK!
Let me know if with the new version this still happens, so I could look into it to see what's happening...

to answer your PM, no I wasn't kidding...I'm truly color blind.
...
that's why I'm very sensitive to colorimetry, "proper" colors look natural, slightly wrong colors look artificial...it's a case of all black/all white, no "in between" if you get my drift

I think this is the reason why you dislike the "keep hue" kind of clipping. Being colorblind, the hue of a color does not have to you the same meaning that for people with regular color sensitivity. So, I've just added to cr3dlut a new option that let the user specify the clipping method to use when handling out of gamut colors. This way, you (and probably other color blind people) could achieve the results that look more appealing to their vision.:)

[leeperry]

Let me know if with the new version this still happens, so I could look into it to see what's happening...

I think this is the reason why you dislike the "keep hue" kind of clipping. Being colorblind, the hue of a color does not have to you the same meaning that for people with regular color sensitivity. So, I've just added to cr3dlut a new option that let the user specify the clipping method to use when handling out of gamut colors. This way, you (and probably other color blind people) could achieve the results that look more appealing to their vision.:)
well ddcc works fine in realtime, and burns up the green in a LUT....I don't really see how this is related to my color blindness..
I just would like to get the ddcc "realtime" colors in a LUT :o

OTOH if I can get the red slightly more saturated, the better :)

and not that ugly black bar in the middle of the green patterns like in CA0 in the "interim" build would be cool too...I'll try again and report back, thanks!

[yesgrey]

well ddcc works fine in realtime, and burns up the green in a LUT....I don't really see how this is related to my color blindness.
Let me try to explain... ddcc uses two clipping methods for out of gamut colors. Let's consider an example tritical and IanB talked some posts back...
R=0.72; G=1.07; B=0.42
The valid values should be between 0.0 and 1.0.
The first clipping method, used without the 3DLUT, just set the rgb values to be inside the valid range:
R=0.72; G=1.00; B=0.42
The second clipping method, used within the 3DLUT, set the rgb values in a way that maintains the hue of the original rgb value. The values would then be:
R=0.72/1.07, G=1.07/1.07, B=0.42/1.07
R=0.673, G=1.000, B=0.393
Since the hue perception for color blind people is different than the hue perception for people with regular color vision, probably the method above is not very friendly to them...
It would be a good test if you could bring anyone with regular color vision to watch your projector, and then show him/her a movie using both clipping methods to see what would he/she prefer... A woman would be more safe, because they are less prone to be color blind...
OTOH if I can get the red slightly more saturated, the better :)
You can try undersaturating the source red primary coordinates to see if it would help...;)

[leeperry]

ok I understand color blind ppl don't see the "hue" the same way normal ppl do, but I'm happy w/ ddcc in realtime, which does NOT give the same results in a LUT(burning the green)...if I got it right it doesn't use the same algorithm for out of gamut colors in a LUT, which you have fixed in your latest cr3dlut build :confused:

even "normal" ppl can see that :
http://forum.doom9.org/showpost.php?p=1273996&postcount=288

oh these questions are banned in my house, I'm not allowed to ask anyone "so what do you say, does the red look better like this <click> or like that?" :D

[yesgrey]

if I got it right it doesn't use the same algorithm for out of gamut colors in a LUT, which you have fixed in your latest cr3dlut build :confused:
Yes, but I have not fixed it, because there is nothing to fix. I've only added the option of selecting the algorithm used for handling out of gamut colors, to let people try and choose which they prefer.

even "normal" ppl can see that :

I haven't said that "normal" people could not see the difference, what I said was that, probably, "normal" people would find the colors by the the "maintain hue" algorythm more appealing than the simple clipping algorythm...;)

[leeperry]

so provided that you had a DLP w/ a lack of green(like mine), SOME ppl could/would prefer to have the green burned up over the regular "realtime" ddcc() algorithm? I don't see it happening as it really makes everything green to death, but OK :)

so to get the "realtime" algorithm, I have to select CA3 right?