gamut conversions through Avisynth ?

[pitch.fr]

well even BD's are 8bit, there's nothing further on the market at this point AFAIK..

oh really 14bit ? I had no idea

well I've run some tests this evening, and EVR/VMR9 still can't compete with HR's smoothness...

maybe I'm willing to give up some smoothness to get perfect colors

lucky you, your projector has a Xenon lamp so you get massive reds, due to my UHP lamp mine are orangey now

[tritical]

Whether avisynth is the right place or not, I created a filter to do the conversions. ddcc v1.2. It takes in rgb24 or rgb32, and does the following conversion:

gamma corrected RGB -> linear RGB -> CIE XYZ -> CIE XYZ -> linear RGB -> gamma corrected RGB

Chromaticity coordinates and transfer functions of the source and output are fully adjustable... some presets are built in. If white points of chromaticity coordinates differ, then a chromatic adaptation is done using Bradford matrix. More details are in the readme. I tested some, but not enough to really be sure it is correct (I simply implemented the conversions as I understand them). For this to run real time on HD video you're gonna need a processor with SSE3 support (I didn't write SSE or SSE2 routines, so its either SSE3 or the C routine), and probably more than 1 core (using only 1 core on my 2.8Ghz Q6600 doesn't quite make it). Hopefully someone can comment on whether the results are anywhere near correct .

[yesgrey]

tritical,
I will take a look and update my AVSForum thread if it's working. It's nice to have other options.

Have you think about doing it using the GPU instead of the CPU? Since this is a highly parallelizable task the GPU could speed it up a lot!... The mplayerc Pixel Shader version works great without any cpu overhead...

Thanks for your work!

[pitch.fr]

cool thanks tritical, gonna give it a shot!

wow 32float, hope this will work in realtime

I've spoken to a friend of mine who's a PS script coder, and he said PS scripts also work in 32bit float :
http://msdn.microsoft.com/en-us/libr...46(VS.85).aspx

EDIT : ooh, your plugin is highly technical stuff

all I wanna do is map SMPTE-C to my DLP projector gamut, which is

Your Display xy

Red Green Blue White
x 0.656 0.339 0.151 0.311
y 0.329 0.611 0.068 0.328
z 0.015 0.05 0.781 0.361

maybe you could give some real life examples in the readme for the Avisynth challenged amongst us

well I can check very easily if the conversion is done properly, by doing a Color.HCFR calibration using the official test patterns DVD in MPC

I could even compare the MPC PS script and your plugin.

I'm gonna try to see if it works in realtime, but some little help on the syntax would be much appreciated

[pitch.fr]

well it's actually very usable in realtime with HR

man, 32bit gamut correction with HR and Reclock, this is too awesome

at this point I'm decoding h264 w/ ffdshow, then it enters the AVS filter in YV12, for 1) LSF 2) multithreaded ConvertToRGB32 conversion and 3) your colorimetry plugin.

[pitch.fr]

oh btw yesgrey3, tritical is using 6 digits after the coma for the xyz coeffs, may wanna update your script ?

for BT470-2 you have more digits after the coma than he does.......but you simply call it "NTSC" so I dunno if it's the same exact matrix.

and for "Offset" which is set to 24 in the XLS script, what's a good value ? what does it stand for ?

[tritical]

@yesgrey3
I'll look into it. Unfortunately, I don't have any experience using pixel shaders... so it may be unlikely.

@pitch.fr
Not sure if you figured this out already, but to map to a custom set of chromaticity coordinates you'll have to use the ofile parameter:

ddcc(ofile="file.txt")

file.txt would contain your values as follows:

0.151
0.068
0.781
0.339
0.611
0.050
0.656
0.329
0.015
0.311
0.328
0.361

You also need to specify the 5 values for the transfer function. You can just take one of the sets of values out of the readme, or to match the transfer function of the pixel shader code use the following five values:

1.0
0.0
0.45
0.0
0.0

I set the defaults of the filter to assume SMPTE-C input primaries and BT.709 input transfer function... so you'll probably also need to change the input transfer function depending on what values you use for the output transfer function.

Also, I put up v1.1... it fixes one small bug, and adds one new built in transfer function (gam_i/gam_o = 5) which matches the transfer function of the pixel shader code.

[pitch.fr]

great, thanks!

actually I've spent quite some time trying to find a way to run this thing in realtime in ffdshow

I've had to cut quite a lot of my audio enhancements in ffdshow audio(96KHz resample and stuff), because it sucks a lot more CPU to use your script + RGB32 conversion in the AVS filter, than to let ffdshow do the RGB32HQ conversion + using the PS script to fix the gamut

what do you think is a good/best transfer function to choose ?
any theoritical improvement over the way the PS script works ?

and what do you guys think of that SAMSUNG pj that can auto-detect whether the YCbPr input is receiving BT.601 or BT.709 ?!

they've got to use some sort of auto-detection algorithm I guess ? or maybe they actually found a way to do that ?

AFAIK this is not possible

there is already a PS script parser for AVS :
http://www.google.com/search?hl=en&q...tnG=Search&lr=

maybe there is room for improvement ?

only the GPU works on these scripts, that's a good thing because I've always heard ppl saying that CPU's were pretty lousy DSP's

[yesgrey]

Originally Posted by tritical

I'll look into it. Unfortunately, I don't have any experience using pixel shaders... so it may be unlikely.

I was not thinking exclusivelly in PS. CUDA would be too complicated? Haven't you tried something with the gpu for your NNEDI?

[tritical]

@yesgrey3
A CUDA implementation would be easy to do, but I was thinking that it would be pretty limiting (in terms of supported video cards) compared to a pixel shader.

@pitch.fr
The best choice of transfer functions would be the one corresponding to what was originally used to produce the gamma corrected RGB, and the one corresponding to the transfer function of your display. Of course, finding those out may be impossible. The one in the pixel shader code is just a generic one with ~2.222 display gamma and no linear segment... it's a reasonable choice if the true one is not known. I have no idea how autodetection of BT.601 vs BT.709 would work.

[pitch.fr]

yeah, I prefer the PQ of ATi cards........please no nvidia proprietary stuff

so what do u think of the PS AVS plugin, maybe a good starting point ?

I'm not sure I understand what you call the "Transfer Function", but it's 4AM here

you mean that it's a wild guess at what the gamma curve was before they encoded their RGB master to YV12 ?

I know what the gamma curve looks like on my DLP pj, it start at 2.3 and ends at 2.1

BUT the professional broadcasting equipment runs 2.5 gamma, that's the rule.......only consumer equipment is 2.22

do you know what I should change in the PS script generator to reflect this please ?

there's also many ways to compute gamma, and there's 2 formulas being used the most.

I've spoken about that with the HCFR color engineers, the most widely used formula seems to be this one :

y' = (y - black) / (white - black)
gamma = log (y') / log (x)
or y' = x ^gamma

which can also be written as follow
we agree that
Y = Ymin when V = 0
Y = Ymax when V = 1
gamma = log ((Y - Ymin) / (Ymax - Ymin)) / log (V)
for 0<V<1

if we wanna take the offset in account, we need to use the following formula :

Y = ((V+offset)/(1+offset))^gamma

if V = 1 then Y = 1
if V = 0 then Ymin = ( offset / (1 + offset)) ^ gamma

it's the one used by Colorfacts, X-Rite, Color.HCFR, Calman etc...

[tritical]

When I say 'transfer function' I just mean the function which maps linear RGB to gamma corrected RGB. The inverse of the transfer function maps gamma corrected RGB to linear RGB. In ddcc they are implemented as:

x = lv*C                           if C < thresh1
    (1.0+av)*pow(C,pv)-av          otherwise

x = C/lv                           if C < thresh2
    pow((C+av)/(1.0+av),1.0/pv)    otherwise

Here, x is the output value, C is a linear or gamma corrected RGB value in the range [0,1], and lv, av, pv, thresh1, and thresh2 are the variables. This is the same as the function you describe, if thresh1 and thresh2 are set to 0 (i.e. no linear segment around 0), offset = av, and pv = 1.0/gamma. All of the presets that I put into ddcc (with the exception of the one to match the pixel shader code, and the srgb one which I got from http://en.wikipedia.org/wiki/SRGB) I took from the mpeg2 specs ('transfer_characteristics', Table 6-8).

[pitch.fr]

humm OK, I will read that slowly again I'm not quite a coder

BTW, what happens to off-gamut colors ?

white is my DLP pj, black is SMPTE-C :



what happens to the green colors that my pj can't output ? they're clipped ?

so they don't appear(banding?), or it still shows yellow instead like it does w/o correction ?

and are you sure this can't be done through the CLUT ?!

ARGYLLCMS has pretty advanced CLUT capabilities, and it's GPL software.

considering you know the formula part, why would that be impossible to generate CLUT entries ?

then we can "capture" it with powerstrip, and we're free from any ressource hogging process.

of course I will test it in every possible way with my colorimeter

DESCRIPTOR "Argyll Device Calibration State"
ORIGINATOR "Argyll dispcal"
CREATED "Tue Jun 17 13:01:45 2008"
KEYWORD "DEVICE_CLASS"
DEVICE_CLASS "DISPLAY"
KEYWORD "DEVICE_TYPE"
KEYWORD "TARGET_WHITE_XYZ"
TARGET_WHITE_XYZ "47.889141 50.384253 54.837810"
KEYWORD "TARGET_GAMMA"
TARGET_GAMMA "2.200000"
KEYWORD "BLACK_POINT_CORRECTION"
BLACK_POINT_CORRECTION "1.000000"
KEYWORD "QUALITY"
QUALITY "high"

KEYWORD "RGB_I"
NUMBER_OF_FIELDS 4
BEGIN_DATA_FORMAT
RGB_I RGB_R RGB_G RGB_B
END_DATA_FORMAT

NUMBER_OF_SETS 256
BEGIN_DATA
0.0000 0.084613 0.0000 2.0434e-003
3.9216e-003 0.087834 0.0000 6.7763e-003
7.8431e-003 0.091075 1.0884e-003 0.011527
0.011765 0.094334 8.1334e-003 0.016295
0.015686 0.097613 0.015385 0.021081
0.019608 0.10091 0.022857 0.025885
0.023529 0.10423 0.030658 0.030707
0.027451 0.10757 0.038978 0.035546
0.031373 0.11092 0.047935 0.040408
0.035294 0.11430 0.057523 0.045302
0.039216 0.11771 0.067448 0.050240
0.043137 0.12117 0.077293 0.055230
0.047059 0.12466 0.086703 0.060272
0.050980 0.12820 0.095542 0.065369
0.054902 0.13178 0.10384 0.070522
0.058824 0.13540 0.11162 0.075722
0.062745 0.13906 0.11897 0.080956
0.066667 0.14275 0.12592 0.086205
0.070588 0.14647 0.13252 0.091446
0.074510 0.15019 0.13878 0.096661
0.078431 0.15392 0.14473 0.10184
0.082353 0.15765 0.15039 0.10697
0.086275 0.16136 0.15583 0.11205
0.090196 0.16507 0.16107 0.11710
0.094118 0.16877 0.16614 0.12210
0.098039 0.17246 0.17107 0.12706
0.10196 0.17616 0.17589 0.13197
0.10588 0.17986 0.18059 0.13685
0.10980 0.18357 0.18519 0.14168
0.11373 0.18728 0.18972 0.14646
0.11765 0.19100 0.19416 0.15121
0.12157 0.19471 0.19853 0.15589
0.12549 0.19843 0.20279 0.16054
0.12941 0.20214 0.20699 0.16514

and many more lines.......

[yesgrey]

Originally Posted by pitch.fr

BTW, what happens to off-gamut colors ?
what happens to the green colors that my pj can't output ? they're clipped ?
so they don't appear(banding?), or it still shows yellow instead like it does w/o correction ?

The final color gamut will be the intersection of the two triangles; a display cannot output colors out of it's own color gamut. What this correction does is remapping the "original" colors into the display gammut so they are the same. It does this changing the RGB values sent to your display in a way that the resulting colors would be the same as the "original".

As I told you before, in theory could exist banding, in practice, I've never noticed it. As you see, the colors clipped are the more saturated ones, which don't appear too often in a movie...

There are two kinds of possible banding, one avoidable and the other not:
1-colors out of display gammut: there is nothing to do, due to the clipping, some colors will be the same. Not many and not very frequent in a movie.
2-colors inside of display gammut: If you perform the correction and have a display with >= 10 bit per color, you could avoid this kind of banding, but in the pc we are currently "limited" by 8 bit per color. Maybe there is any hardware solution...

[yesgrey]

Originally Posted by tritical

A CUDA implementation would be easy to do, but I was thinking that it would be pretty limiting (in terms of supported video cards) compared to a pixel shader.

Well, it would be a start... and much of the people who will use this probably have a Nvidia card.
The ATI "CUDA version" is too complicated?
I understand that currently it's not very appealing working with these new GPU/CPU APIs, because probably only one will survive or even none of them will survive (a Microsoft one maybe?...)

Also, we cannot forget that the currently existing alternative to this, using mplayerc with PS, works in all of them and gives pretty good results. I believe you're solution in theory is better, because you are using the correct gamma functions, but at the end, the result should be very similar...

I left the decision in your ends (as it should be).

[pitch.fr]

Originally Posted by yesgrey3

As I told you before, in theory could exist banding, in the practice, I've never noticed it. As you see, the colors clipped are the more saturated ones, which don't appear too often in a movie...

There are two kinds of possible banding, one avoidable and the other not

ok, gracias for the explanation

well CLUT is 30 bit, so no banding

I've spoken to Graeme Gill(the author of www.argyllcms.com) and he said this could be achieved through the CLUT.

then I could use it on top of Haali's Renderer.............this would be awesome for me coz this is the smoothest renderer ever

here's what he told me :

do you think that would be doable through the CLUT ?

Yes. It's been done many times. See the example code in the openEXR package and their exrdisplay utility. Rather than doing simple matrix arithmetic, you set up a texture to hold the CLUT, and have the fragment shader do a texturelookup for each pixel.

the issue is that the smoothest video renderer on PC(Haali's Renderer) doesn't support Pixel Shaders......and I was hoping to get SMPTE-C corrected colors with it, but I guess it's just a wild dream at this point...

The code here http://www.avsforum.com/avs-vb/showthread.php?t=912720 is already using a shader, it's just a matter of converting it to use a text3D and loading the ICC device link into the texture, instead of the pow/mul etc. functions.

so are you saying that once the CLUT is built, it could work w/o further realtime pixel manipulations ?

Yes, it only needs initializing if you change the device link it represents.
The OpenEXR utility was written to preview motion picture effects in real time,that's why they use a shader program to do it.

if any of you two code gurus could do that, that'd save a helluvalot of CPU time

as I understand it, this should be possible to output an .ICC/.ICM file instead of a realtime correction through PS or AVS ?

maybe this PDF would help ?
http://www.inventoland.net/imaging/JEI/159.PDF

OTOH, I'm trying your AVS plugin in ffdshow....as nothing's as smooth as HR on my box with Reclock in 24/48Hz

I've copied this to C:\PJ_SMPTE.txt :

0.151
0.068
0.781
0.339
0.611
0.050
0.656
0.329
0.015
0.311
0.328
0.361
1.0
0.0
0.45
0.0
0.0

and I'm using :

MT("""ConvertToRGB32(matrix="rec709")""",4)
ddcc(chr_i=3,ofile="C:\PJ_SMPTE.txt",threads=4,opt=1)

all I get is a black screen, ddcc(chr_i=3,chr_o=0,threads=4,opt=1) works fine.

[IanB]

@Tritical,

One very minor issue, you min(max(X, 0.0f), 1.0f) in 3 places. The input gamma table, the result of the matrix multiply and again for the output gamma table. I would have expected only the output gamma table which generates the 8bit output pixels needed to be clamped, all the other cases could be free to have temporary head room excursions outside the nominal range.

i.e.

1.001*0.55 + 0.7*0.20 + 0.9*0.25 = 0.91555
1.000*0.55 + 0.7*0.20 + 0.9*0.25 = 0.91500

I guess it's a style thing, allow headroom on intermediate results or clamp rigorously at every stage.

[tritical]

@IanB
Well, only one of those three clamps is actually doing anything. The first clamp (on building the igamma table) shouldn't ever trigger since the inverse transfer function maps [0,1]->[0,1], and at that point it will only get [0,1] input. The second clamp, after the linear RGB -> XYZ -> linear RGB conversion, will trigger for out-of-gamut colors (i.e. a color in the input gamut is outside of the output gamut). I believe this is the right place to clamp because the final RGB values should be in the range [0,1], and the transfer function is defined as taking [0,1] input. The final clamp (on building the fgamma table) will again never trigger since it maps [0,1]->[0,1] and because of the previous clamp it will only be getting [0,1] input. I put those clamps in the gamma table creation mainly to remind myself that those values should be in the range [0,1], and since it is run only in the constructor the cost is negligible.

@pitch.fr
Having the filter output a 3D LUT is possible, just need to know the format to use. Also, the dark screen when using the ofile parameter was due to a bug I introduced in v1.1 (a missing multiply if the white points differed causing chromatic adaptation to be used). I put up a fixed version.

[pitch.fr]

well, Graeme Gill's told me that an .ICC file would do the trick! possibly v4 ?

the LUT is 30 bit on ATi cards, dunno with nvidia ?

If you could generate an .ICC file, this would be really awesome........as the Avisynth support in ffdshow is too slow(or maybe it's ConvertToRGB32's fault), and this PS script isn't working with HR..

at this point, nothing could be better than a way to generate .ICC profiles

I'm actually very happy to hear that it's possible, because getting 1:1 colors with Haali's Renderer and Reclock would be just TOO AWESOME

OK I'm gonna try again with the new version

there is another slight detail, though.
a friend of mine believes that gamut color conversion can only be done on the original 16-235 signal........applying the gamut conversion on 0-255 expanded content would require different coeffs ?!

when we do REC.xxx conversions to RGB32 in ffdshow, luma goes from 16-235 to 0-255 and chroma from 16-240 to 1-255.....so are you still able to map the 0-15 and 241-255 colors

or should we output in full range and let your ICC do the PC>TV conversion ? or a custom range ?

also, here's a very interesting thread about these gamut stories :
http://www.avsforum.com/avs-vb/showp...22&postcount=1

and another one on doom9 :
http://forum.doom9.org/showthread.php?t=132745

and a PDF about ICC corrections in the movie industry :
http://www.color.org/ICC_Chiba_07-06..._DMP_Float.pdf

thanks for your help tritical !

[tritical]

I don't know anything about ICC profiles... How exactly would that solve the problem (assuming you had one, how would you use it)? Also, is there a document which describes the format of icc profiles, i.e. how to create one?

a friend of mine believes that gamut color conversion can only be done on the original 16-235 signal........applying the gamut conversion on 0-255 expanded content would require different coeffs ?!

when we do REC.xxx conversions to RGB32 in ffdshow, luma goes from 16-235 to 0-255 and chroma from 16-240 to 1-255.....so are you still able to map the 0-15 and 241-255 colors

All of the equations in this filter work on values in the [0,1] range. The conversion to and from [0,1] currently assumes the min/max values of the RGB channels are 0 and 255. I could allow the user to specify different min/max values if desired (for instance if the RGB channels had a range of [16,235]), but usually RGB is [0,255]. The range question is usually related to whether YUV is [16,235],[16-240] or [0-255]. Depending on which it is, you need different scalings of the YUV->RGB conversion coefficients.