gamut conversions through Avisynth ?

[pitch.fr]

@yesgrey3 : this is not going to happen. Haali won't support PS scripts in his renderer, he clearly said it several times in his thread.

you can only achieve 3D LUT's in ICC v4, but this only works in windowed mode with HR, so it's useless to us.

@tritical : wow, the mad scientist is at work again :D

a friend of mine was explaining me that the CIE chart doesn't mean much because CIExy is a 3D space.....from the view we see the CIE from there's an unlimited number of heights.

the PS scripts prefers to get closer to the source, even if the Delta-E gets worse.

your explanation is going a bit over my head, I will need to read it several times again :D

so there's no way to measure what DDCC does ?

it doesn't clip colors like the PS script does, it's smarter than that then ? :eek:

for SMPTE-C/EBU conversion on an HDTV'ish display, the DDCC settings and the text file settings seem "optimal" to you ? is it better to go gam_i=2 or 5 ?

Thanks,

[yesgrey]

this is not going to happen. Haali won't support PS scripts in his renderer, he clearly said it several times in his thread

But he doesn't need to support PS scripts, he could only add this correction to his renderer, which should be a very simple task to do...

The other solution seems to be if tritical write ddcc with some kind of gpu support. PS would be better because will work with all gpu. CUDA would be easier to him, but will only work with NVidia. I vote for the later. (I have a nvidia card :D)

[yesgrey]

tritical,
Where did you get your D65 white point coordinates? (0.312713,0.329016,0.358271)
In Rec. ITU-R BT.709-5 the coordinates are: (0.3127,0.3290,0.3583)

In the begining I also used yours, but aparently they are wrong...

[tritical]

@yesgrey3
If you go through all the calculations based on how D65 is defined, 0.312713,0.329016,0.358271 are closer to the true values. BT.709 just rounds to 4 decimal places. I guess the BT.709 chromaticity coordinates definition in ddcc should be changed to the truncated values, but I don't think the difference is enough to matter (i.e. release a new version just for that). Especially if you are simply going to use pow(x,0.45) as the transfer function, when you consider that BT.709 actually defines the transfer function as:
x = 4.5*C if C < 0.018
(1.0+0.099)*pow(C,0.45)-0.099 otherwise

Again, I think most of these differences are too small to worry about.

@pitch.fr
Chromatic adaptation tries to adjust for changes in illuminant (between the source and destination) such that the image after conversion will appear to a person to look as much like the original as possible. Basically, CATs (chromatic adaptation transforms) are adjusting for a phenomena of the HVS, and like psychovisual methods in codecs, CATs are primarily based on human viewer tests. Using a CAT means that the XYZ values of each pixel will be different than if you just did a straight conversion while ignoring the CA phenomena. Most major photo/image editors like photoshop use CATs during conversions, so I assume it is desirable (photoshop uses the Bradford method).

On the gam_i=2 or 5 question, I'm not sure. SMPTE-C only defines chromaticity coordinates, not a transfer function.

[pitch.fr]

But he doesn't need to support PS scripts, he could only add this correction to his renderer, which should be a very simple task to do...

The other solution seems to be if tritical write ddcc with some kind of gpu support. PS would be better because will work with all gpu. CUDA would be easier to him, but will only work with NVidia. I vote for the later. (I have a nvidia card :D)

oh yeah GPU support would be awesome, but no proprietary stuff please.
nvidia cards don't work with Powerstrip, so no spot-on 48Hz for you.....and their PQ contrast and sharpness-wise it's nothing like the ATi's IMHO.

and what happens to the off-gamut green with the PS script in my case ? it clips to the most saturated green I can get ? strangely enough, I haven't seen any banding

On the gam_i=2 or 5 question, I'm not sure. SMPTE-C only defines chromaticity coordinates, not a transfer function.

well SMPTE-C is supposed to be in watched in the SMPTE RP 145 gamut I think, so how does that look ? and what about EBU Tech. 3213 for EBU ?
gam_i=5 seems to offer more contrast, because the low IRE gamma of 2 seem too bright.

what about the last 5 figures of the text file, do they look "optimal" to you ?

and does the DDCC algorithm offer improvements over the PS script ? or do they basically go different ways but achieve the same end result ? like off-gamut colors for instance ?

I'm getting a new CPU on thursday, hopefully a 4GHz C2D will help with real time use in ffdshow and HD content :D

[yesgrey]

I guess the BT.709 chromaticity coordinates definition in ddcc should be changed to the truncated values, but I don't think the difference is enough to matter (i.e. release a new version just for that).
I agree. I did not referred the chromaticity coordinates difference to justify what is happening, I know the difference is too small, I was just noting it.

nvidia cards don't work with Powerstrip, so no spot-on 48Hz for you...

and what happens to the off-gamut green with the PS script in my case ? it clips to the most saturated green I can get ? strangely enough, I haven't seen any banding

I have spot-on 47.952Hz with my geforce 8600gt. See my thread in powerstrip forum on how to achieve it. In fact, I also have spot on 50.000Hz and 59.940Hz. I wrote a little program to calculate the resolutions to achieve this. Maybe when I get the time I will create a thread about it. I have to test the new powerstrip functionallity to see if it overrides my little program...

Yes, your green and all the other off-gamut colors are clipped to the nearest most saturated colors you could get.
Remember that a movie is not full of highly saturated colors, and our eyes color perception is also non-linear, so don't worry about that and simply enjoy your movies!:)
For me, would be more of a concern the possibillity of banding inside the color gammut, when converting from one to another,
but I also never noticed it.
One of this days I will create a few test images to see if we could really notice the banding...;)

[pitch.fr]

I can't find any posts from yesgrey3 on the pstrip forum, do you have the link please ?

well quite frankly I've tried 2 8600GT(MSI & PNY), they looked really bad compared to the Sapphire 2400Pro/2600XT on both my CRT and my HC3100 in DVI.

like some ugly EE even on the windows desktop, and very bad contrast.

many friends have also switched after I told them, IMO the ATI are far ahead as far as PQ is concerned.

a friend of mine tried the new "auto search" feature of pstrip on a 9600GT, it didn't work at all!

I personally prefer 48.000Hz to get the real 24fps cinema speed, I find 47.952 too slow :D

[yesgrey]

Search for yesgrey33. I lost the password of the yesgrey3...

I prefer 47.952. If you set an exact refresh in your graphic card you don't need to resample the audio with reclock. I currently only use it to output bit perfect with my RME Fireface. For PAL movies, the pitch correction could be done lowering the audio card clock, without any resampling...

[pitch.fr]

well I don't see any tool ?!

Use powerstrip timings with GeForce 8 custom resolutions
yesgrey33 6 5125 Fri Mar 21, 2008 3:58 am

Custom resolution feature request
yesgrey33 10 2570 Fri Sep 28, 2007 9:33 pm

well I don't mind resampling, I'm outputting analog anyway.

and pstrip has that new feature that does automatic searches until the graphic card says "48.0000000000000000000 Hz"

so together with Reclock set to "24fps", it's a winner....very low jitter in HR 8)

[yesgrey]

I haven't posted the tool yet, and I believe the new pstrip function works very similar to mine, so maybe I will never post it.

When you resample the sound it's quality will be worse than without resampling... even when you use the Excelent quanlity, and this is very slow... and if you don't resample, you will have more cpu power for processing the color correction.

[pitch.fr]

the auto-search feature doesn't work at all on the 9600GT.
a friend of mine was searching for 48.000000 but all he got was 59Hz :D

maybe he could try your app ?

yes you have a point, if Reclock doesn't suck 20% of my CPU time to do "Excellent" resampling, this can be put to good use with DDCC :)

I'll see how it goes with my new E7200 tomorrow :D

[pitch.fr]

to get back on topic, would that be possible to fix the saturations of the display upfront in DDCC ?

that's a chart of my HC3100 saturations :

http://pix.nofrag.com/0/2/8/a990a92dce9da10f80a7f76c10e18.png

ideally, they should all be on the 0% line and at worse ±5%

you can see that at 75% the green primary is +12% and yellow +10%, which has a very bad effect on people faces.

and cyan is falling down, which increases the red saturation.

very few displays allow to set each color saturation(the Sanyo pj are very good at that).

could you set an offset or something in DDCC for the primaries/secondaries saturations ? because it's a major point not to be missed to get accurate colors on the whole IRE scale.

and a friend of mine is asking again if the luminance is taken in account ? considering we've done a TV>PC levels conversion.



PS : here's another thread that says that HD is mastered with REC.709 matrix and SMPTE-C primaries :
http://www.avsforum.com/avs-vb/showthread.php?p=14072175#post14072175

actually there's a very good reason why all the US telecine studios use this exact SONY 20" 4:3 CRT :
http://catalogs.infocommiq.com/avcat/CTL901/index.cfm?mlc_id=203&mrc_id=901&prodid=398485

that because it's built like a tank(2.5 gamma like all the broadcast equipment), and it already has less dynamic than a telecine, but LCD and plasma can't match its native contrast and also have other major drawbacks...

I just don't understand why they don't convert gamut from SMPTE to HDTV when they do BT.601>BT.709 transcoding :o

[pitch.fr]

I think I've killed tritical with all my questions :eek: :D

anyhow, I just got my new CPU, and it lets me run DDCC in real time with all my audio enhancements and Haali's Renderer.....this is awesome :D

http://pix.nofrag.com/0/9/9/f76a843109dbd01e7bec409131558tt.jpg (http://pix.nofrag.com/0/9/9/f76a843109dbd01e7bec409131558.html)

what do you guys think of this TV>PC levels AVS script ?
http://forum.doom9.org/showthread.php?t=137479

it basically does a TV>PC levels conversion doing chroma smoothing, to avoid banding, which is very pleasing to the eye....

but OTOH it's messing with the gamma curve, which increases the contrast :)

here's a comparison(both get through my pj SMPTE-C PS script), top is with Ulevels(), bottom is with ffdshow at the RGB32 conversion :

http://thumbnails8.imagebam.com/991/b61b119905830.gif (http://www.imagebam.com/image/b61b119905830)http://thumbnails8.imagebam.com/991/9b2ef49905832.gif (http://www.imagebam.com/image/9b2ef49905832)http://thumbnails8.imagebam.com/991/3b5c889905834.gif (http://www.imagebam.com/image/3b5c889905834)

http://thumbnails8.imagebam.com/991/f1ffe19905831.gif (http://www.imagebam.com/image/f1ffe19905831)http://thumbnails8.imagebam.com/991/0b3b449905833.gif (http://www.imagebam.com/image/0b3b449905833)http://thumbnails8.imagebam.com/991/fa99c29905835.gif (http://www.imagebam.com/image/fa99c29905835)

there's an ongoing war on AVS around SMPTE-C reds being way too orangey, and I have to agree.

basically the CARS hero will never look as red in the movie as he is on the cover....so using this thing kinda fixes this problem :cool:

here's what I'm running in ffdshow at this point :
MT("LimitedSharpenFaster(ss_x=1.0,ss_y=1.0,strength=40)",4)
MT("""ULevels(preset="tv2pc")""",4)
MT("""ConvertToRGB32(matrix="PC.709")""",4)
ddcc(chr_i=3,gam_i=5,ofile="C:\PJ.txt",threads=4,opt=1)

[pitch.fr]

just wanted to say that DDCC works perfectly fine in real time in ffdshow with any 720p/2.35 1080p content on a G0 Q6600 o/c to 3.4Ghz :)

it's too slow for 1080p 1.78/1.85 movies, though(even when downscaled to 720p).......ffdshow is wasting too many CPU cycles on 15/20mbit h264

but hopefully the h264 Remoulade decoder will solve this issue, because it's got much less latency than ffdshow and is far more MT optimized :eek:

[tritical]

While working on a project requiring rgb->Lab/Luv/Lch conversions, for which I stole code from ddcc, I discovered a bug in ddcc's chromatic adaptation code (it's used when the white points of the source and destination differ). Specifically, it should have been multiplying by the transpose a matrix when it was just using the matrix straight away. Fortunately, the errors caused by this were small. Anyways, I put up a fixed v1.3 at the usual location (http://bengal.missouri.edu/~kes25c/ddcc.zip). Also, I still don't have any plans to port this to the GPU.

[yesgrey]

tritical,
The correction matrix is always the same for each display. So, why not make a very simple thing like this:
Pick this filter and divide it in two parts:
1-One small software tool that will create files with 3D LUTs for all our display modes we need.
2-The Avisynth filter only has to load that file and output the correct RGB values just by looking at the 3D LUTs. This will not use lots of memory and it will speed up all this process. It's not very efficient calculating each RGB value one by one, since for each RGB value the corrected value will always be the same. This way, if we have the 3D LUTs in a file format, we could simply ask the ffdshow developers to add this to ffdshow, which would be very simple, just load the 3D LUTs and applying it after the YUV->RGB conversion, without any increase in cpu load, just some memory usage.
From my calculations, it would be: 3 3D LUTs: 3x256^3 = 48MB
For the current memory available in a PC, it's an insignificant amount...
What do you think?
The porting to the GPU is completelly useless, I agree with you. This is a one time calculation, so it could also be all written in C, then it's simply using the 3D LUTs...

[tritical]

yesgrey3, when I read your post my first thought was that accessing a 48MB LUT would be really slow on a typical desktop comp. Then I got curious about how slow it would be... Turns out it wasn't that slow at all (faster than the sse3 code path of ddcc on the dual core comp I'm on right now).

So I added a parameter to ddcc to output a 3D LUT ('lutfile'). The table is stored in binary format. The offset into the table in bytes is calculated as ((g<<16)+(b<<8)+r)*3, and at that location the new values are stored in b,g,r order (one byte each). I chose that arrangement because it made the assembly implementation fastest/easiest. I also added a new function to ddcc.dll called 'rgb3d'. It takes a LUT of the format I just described as input, and performs the 3D LUT operation. 'rgb3d' requires rgb24 input. The new dll is at the same place as before.

[yesgrey]

tritical,
Thank you very much! It was a good Christmas gift!:)
I will take a look and test it and will let you know...

:thanks:

[leeperry]

goddamn, you know you're just a bunch of mad scientists right :D

ConvertToRGB32(matrix="rec709")
= 302 fps

ConvertToRGB32(matrix="rec709").AviShader("C:\effect.fx", "ColorCorrection")
= 86 fps
(using this script : http://www.avsforum.com/avs-vb/showthread.php?t=912720 )

ConvertToRGB32(matrix="rec709")
ddcc(chr_i=3,gam_i=2,ofile="C:\coeffs.txt",threads=4,opt=1)
= 96 fps

ConvertToRGB24(matrix="rec709")
= 283 fps

ConvertToRGB24(matrix="rec709")
rgb3d(lutfile="C:\lut.txt")
= 220 fps

ConvertToRGB24(matrix="rec709")
ConvertToRGB32()
= 196 fps

ConvertToRGB24(matrix="rec709")
rgb3d(lutfile="C:\lut.txt")
ConvertToRGB32()
= 170 fps

anyway me likes it A LOT, thanks a lot fellas & merry xmas http://forum-images.hardware.fr/images/perso/astrid72.gif

if it could work natively/output in RGB32 & support RAR format for the lut file(so I can copy them on a ramdisk), that would be great too...but it's already awesome as it is!

[yesgrey]

tritical,
It's great as it is, but I would like to make a suggestion... I think the name rgb3dlut would be a little more suggestive...

leeperry,
I was worried to not have hear anything yet from you...;-)

[leeperry]

I was worried to not have hear anything yet from you...;-)
well when it comes to Reclock/ffdshow/KMP/HR or 3D LUT's, I'm all ears :p

besides, I think it's good to have real world benchmarks to see how efficient the new code is :o

PS: the lut stuff seems to be more accurate than the realtime SSE3 mode...or at least the PNG's are slightly bigger than both the SSE3 mode & the PS script.

[tritical]

I changed the name to rgb3dlut, and added rgb32 support.

[leeperry]

awesome, thanks a bunch tritical!

ConvertToRGB32(matrix="rec709")
rgb3dlut(lutfile="C:\lut.txt")
= 216 fps

I've RAR'ed up the LUT files(1 mb a pop) on a ramdisk and I unrar them through a rar.exe batch, so everything's cool...damn I'm drunk, gonna get some more Champagne :D

[yesgrey]

PS: the lut stuff seems to be more accurate than the realtime SSE3 mode...
Read the readme.txt file.
With all calculations not needed to be done in Real-time, no simplifications are used, the values in the 3D LUT are as accurate as they could be!

[yesgrey]

tritical,
Thanks a lot for your work, and also for your curiosity in knowing how slow my suggestion would be...;)
:thanks:

[leeperry]

Read the readme.txt file.
With all calculations not needed to be done in Real-time, no simplifications are used, the values in the 3D LUT are as accurate as they could be!
right, I remembered I read something about that, but I couldn't find it in this thread :rolleyes:

[yesgrey]

tritical,
Why do you request all chromaticity coordinates in the file. Is not the rule x+y+z=1 always valid? Usually, the colorimeters only give us the x,y coordinates, so we have to perform the calculation above to get the z coordinate...

Another question: in the readme, you don't say what is the gamma for SMPTC-E and EBU, only the chromaticity coordinates...

If you release a new version to remove the z coordinates, also take a look at this, in your post #54, maybe you still want to change it, even not being needed...

If you go through all the calculations based on how D65 is defined, 0.312713,0.329016,0.358271 are closer to the true values. BT.709 just rounds to 4 decimal places. I guess the BT.709 chromaticity coordinates definition in ddcc should be changed to the truncated values, but I don't think the difference is enough to matter (i.e. release a new version just for that).

[leeperry]

colors look definitely even more true to life with that LUT stuff, quite a blast to watch BARAKA in BD in its native gamut this accurately :eek:

I tried gam_i=2,gam_o=5 as yesgrey suggested, but then the gamma curves were not dark enough...gam_i=5,gam_o=5 looks identical to the PS script gamma-wise and really good on my ±2.2 calibrated display :cool:

[tritical]

I require z in the files just because that's how I wrote it. Calculating z isn't that much extra work :p. I don't list gamma functions for SMPTE-C because it doesn't specify a specific gamma function. AFAIK, with SMPTE-C you should use NTSC gamma (BT.470-2 System M, 2.2 gamma) for NTSC stuff and PAL gamma (BT.470-2 System B,G, 2.8 gamma) for PAL stuff. EBU should usually use BT.470-2 System B,G gamma AFAIK. On the truncating of white point coefficients for BT.709, I'm not sure if the standard actually states truncated values or simply says the white point is D65 illuminant (in which case more accurate values would be fine). Either way, the difference wouldn't be noticeable. I might change it in the next version.

One thing I definitely want to change is the way out-of-gamut colors are handled when using lut creation. Right now, each channel (R,G,B) is simply capped to [0,1] (before gamma is applied). That method is used for speed. A better way would be to adjust all channels together. In the case of values < 0, subtract min(r,g,b,0) from all channels (i.e. add white). In the case of values > 1, scale all channels using the same value such that the maximum channel is at 1.

[leeperry]

..that still wouldn't show off-gamut colors I guess ? :D

actually that'd be great to have an option to set off-gamut colors to blink or sumthing(for troubleshooting purposes), because from what yesgrey3 said the most saturated tints are hardly ever used...and I've never witnessed banding myself.

it would also be great if you could import a .chc file from Color.HCFR and use the primaries/secondaries saturations data to counterbalance it in the LUT :eek:

I was discussing it with JohnAd here, he said it would be possible :
http://www.avsforum.com/avs-vb/showthread.php?p=14594838#post14594838

:thanks:

[yesgrey]

Either way, the difference wouldn't be noticeable.
I agree with that, that's why I think it's preferable using the truncated values. The standard says D65 and the x,y coordinates as 0.3127, 0.3290. I agree that the other values are more accurate, but using the truncated values avoid the repetition of this question over and over... do as you prefer, for me it's not an issue.:)

If SMPTE-C and EBU do not specify any gamma curve, should we use option 5 but using the gamma values you suggested?
I think it would be a good idea to include in the readme that explanation about the gamma curves for SMPTE-C and EBU.

[yesgrey]

actually that'd be great to have an option to set off-gamut colors to blink or sumthing(for debug purposes), because from what yesgrey3 said the most saturated tints are hardly ever used...and I've never witnessed banding myself.

With the current displays, the off-gamut colors is almost not an issue, because their gammuts exceed the standards gammuts; maybe only ntsc could have some problems with the reds...

The more problematic would be the inside-gamut colors. Due to the PC only working with 8 bit per component, the same as the video sources, some source colors will be showed as the same color after the gammut conversion (shrinking).
If we had 10 bit per component color depth in our PCs... some graphics cards already support it, but Windows don't.:(

[tritical]

@yesgrey3
For SMPTE-C I would use gam_i/o = 3 for NTSC and 4 for PAL, which is the same as using 5 but with 2.2 or 2.8 gamma respectively. I will add that to the readme.

@leeperry
it would also be great if you could import a .chc file from Color.HCFR and use the primaries/secondaries saturations data to counterbalance it in the LUT
In the saturation error graph you posted in the avsforum thread, how is saturation being computed?... From Luv colorspace or XYZ or HSV? How are those % errors computed? Is it computing the saturation of the desired color, the saturation of the color measured by the probe, and then computing the relative error? What values are in the .chc file (I can't download the file you posted since I don't have an account there). Given those values, how do you propose to modify the calculation?

[leeperry]

@leeperry

In the saturation error graph you posted in the avsforum thread, how is saturation being computed?... From Luv colorspace or XYZ or HSV? How are those % errors computed? Is it computing the saturation of the desired color, the saturation of the color measured by the probe, and then computing the relative error? What values are in the .chc file (I can't download the file you posted since I don't have an account there). Given those values, how do you propose to modify the calculation?
apparently JohnAd could answer you on that, as he managed to import the .chc data and try to fix it through the PS script.

but because it was a very simple 3D LUT in the PS script, it wasn't quite possible to fix it entirely.

with your LUT stuff, you should be able to take it in account in the conversion computing I would guess ?

all I can say right now is that there is an option in Color.HCFR to choose whether you want the saturations to be computed from the reference gamut or from the display native gamut.

I will ask your questions to one of the Color.HCFR coders, and I'll get back to you.

I've uploaded the CHC file here BTW :
http://www.yousendit.com/download/TTZuUWVuTWN6RStGa1E9PQ

you need Color.HCFR 2.01 :
http://www.homecinema-fr.com/colorimetre/release/Setup_v2_0_1.exe

For SMPTE-C I would use gam_i/o = 3 for NTSC and 4 for PAL, which is the same as using 5 but with 2.2 or 2.8 gamma respectively. I will add that to the readme.
well SMPTE-C is used on US/ASIAN DVD/BD, and EBU on EUR BD/DVD...you're saying we should use 3/3 for SMPTE-C stuff ? what about EBU stuff ?

what if you have values at the end of the ofile and still specify gam_o in the AVS call, is gam_o prefered ?

I've tried to put this at the end of my ofile(same values as gam_o=3) but it gave much darker gamma than gam_o=5 :
1
0.0
1.0/2.2
0.0
0.0

this is 0.45454545~ where gam_o=5 is 0.45...the difference I see seems much bigger than that, maybe the "/2.2" part has been ignored :confused:

I was under the impression than 5/5 worked in any given situation :rolleyes:

[tetsuo55]

With the current displays, the off-gamut colors is almost not an issue, because their gammuts exceed the standards gammuts; maybe only ntsc could have some problems with the reds...

The more problematic would be the inside-gamut colors. Due to the PC only working with 8 bit per component, the same as the video sources, some source colors will be showed as the same color after the gammut conversion (shrinking).
If we had 10 bit per component color depth in our PCs... some graphics cards already support it, but Windows don't.:(

Windows 7 has full support for 10bit, it goes as far as 16bit actually.
I personally cannot wait because i have a 10bit videocard AND a 10bit display

I really hope Windows 7 is smart enough to detect all the different colorspaces and converts them accurately to 10bit BT.709

[leeperry]

i have a 10bit videocard
the TMDS encoder of your graphic card works in 3*8 bits, no soup for you :D

[tetsuo55]

the TMDS encoder of your graphic card works in 3*8 bits, no soup for you :D


Why do you think so?

According to all ATI documentation i read on the subject it has full support, also read some posts on random forums where people are using it.(incidentally with almost the same panel as i have)

Quoting Ati's PR:
-Full 30-bit display processing
-Spatial/temporal dithering provides 30-bit color quality on 24-bit and 18-bit displays
-Primary supports 18-, 24-, and 30-bit digital displays at all resolutions up to 1920x1200 (single-link DVI) or 2560x1600 (dual-link DVI)1
Secondary supports 18-, 24-, and 30-bit digital displays at all resolutions up to 1920x1200 (single-link DVI only)1

[leeperry]

According to all ATI documentation i read on the subject it has full support, also read some posts on random forums where people are using it.(incidentally with almost the same panel as i have)
well we've discussed this a bit with Seb.26(an occasional ffdshow coder from HCFR), basically you can output 30 bits on VGA....considering it's analog and the LUT is 3*10 bits, you can even measure the LUT accuracy with ARGYLLCMS and a colorimeter.

DVI/HDMI 1.0 is 3*8 bits TMDS, and I don't see any >1.0 HDMI graphic card at this point...so these nice HDMI 1.3 inputs on top of the line displays are m00t at this point(even so considering there's no 30 bits source at this point, and there won't be before a long while).

so 30 bits/xvYCC would only be useful to the HTPC color freaks...like us :D

apparently DVI can only do 30 bits in dual link configuration :
http://techreport.com/forums/viewtopic.php?t=47715

but dual link DVI & HDMI 1.3 are not compatible AFAIK...what's your display that does 30 bits on DVI ?

[tetsuo55]

Interesting...

I have a Sony HDTV, its a 1080P/10bit(30bit) panel.
My current videocard is a HD2400pro.

The card seems to have a HDMI 1.2 port, which supports everything except TrueHD/DTS-MA bitstream and 10bit(30bit)
My card does support up to 10bit(30bit) but only with DVI

I guess you're right.
Currently you need a panel that supports 10bit over DVI, not HDMI(Many of these panels exist, but they are small and expensive as they are sold to the graphic industry)

I know there is no content available, but at least it would fix the fact that all are mediacenters are stuck in sRGB(which is the only colorspace windows understands)

[yesgrey]

Windows 7 has full support for 10bit, it goes as far as 16bit actually.

I was hoping for this...
In fact, when they start W7 development, I have posted to their blog requesting that... I don't think they have done by my request, but it's great to know that it's coming...

Maybe you can not use it with the hdmi port, but with the vga port yes, I believe the dacs are 10 or 12bit...

[leeperry]

there's still no HDMI 1.3 soundcard that can do bitstream....so wait for a (long) while and HDMI 1.3 graphic cards will pop up, eventually :D

many pj work internally in 10/12 bits, meaning the gamma/colorimetry settings in the OSD won't create terrible banding

even if we get HDMI 1.3 graphic cards & 10 bits native windows 7, don't count on anyone but tritical, yesgrey3 & JohnAd to watch our back.

just like Reclock, ppl who care about butter smooth movies and proper colorspaces are not legions.

actually, there's this card from Asus that looked most promising "12-bit gamma correction" :
http://vr-zone.com/articles/ASUS_Combines_Splendid_HD_w_HD3850_MXM_Card/5753.html?doc=5753

too bad they didn't put HDMI 1.3 outputs :rolleyes:

[tritical]

Well, after reading the documentation of color.hcfr I know how they calculate saturation (euclidean distance from the white point in xyY space) and the saturation error percentages. However, I'm still not sure how you'd go about accuractly correcting anything. All you have are measures for a few points that fall along the 6 lines running from the white point to the 3 primary and 3 secondary colors in xyY colorspace.

[leeperry]

actually Colorfacts doesn't measure these saturations at all.

all you get is gray levels & gamut measurements, so maybe it's not that important after all.

in my case cyan is going down the drain >70%, and other colors are oversaturated...if you tell me what data YOU'd need, I can try to get the Color.HCFR coders to provide you with them.

http://pix.nofrag.com/0/2/8/a990a92dce9da10f80a7f76c10e18.png

[yesgrey]

For SMPTE-C I would use gam_i/o = 3 for NTSC and 4 for PAL, which is the same as using 5 but with 2.2 or 2.8 gamma respectively. I will add that to the readme.


tritical,
This is my understanding of all this formats thing...

For the output, whichever format we use, I think we should always use our display coordinates, and gam_o=5 with a gamma value equal to our display gamma... if our display has a gamma of 2.0, we should use 2.0.

For PAL we should use BT.470-2 System B,G
primaries and gamma curve, chr_i=2 and gam_i=4.

and from this (http://en.wikipedia.org/wiki/NTSC), it appears that for NTSC we should use SMPTE C primaries and SMPTE 170M gamma curve, chr_i=3 and gam_i=1.

What do you think of this?

[yesgrey]

leeperry,

could you post the same graph but without performing the color correction? Just with the original primaries and secondaries?

Thanks.

[leeperry]

leeperry,

could you post the same graph but without performing the color correction? Just with the original primaries and secondaries?

Thanks.
well that's the second part of the problem actually.
it's easy to measure them with the automatic test patterns built into Color.HCFR...but then it's done through simple GDI(no DS filter).

to do it through ddcc, you'd need to use the manual DVD test patterns.....and to get this chart you need to go through at least 24 of them, enough to turn anyone nuts.

so I've asked the Color.HCFR guys if they could somehow drive MPC by sending "next chapter" keystrokes, but well if these data can't be "processed" into ddcc's LUT then it's pointless.

[tetsuo55]

there's still no HDMI 1.3 soundcard that can do bitstream....so wait for a (long) while and HDMI 1.3 graphic cards will pop up, eventually :D

many pj work internally in 10/12 bits, meaning the gamma/colorimetry settings in the OSD won't create terrible banding

even if we get HDMI 1.3 graphic cards & 10 bits native windows 7, don't count on anyone but tritical, yesgrey3 & JohnAd to watch our back.

just like Reclock, ppl who care about butter smooth movies and proper colorspaces are not legions.

actually, there's this card from Asus that looked most promising "12-bit gamma correction" :
http://vr-zone.com/articles/ASUS_Combines_Splendid_HD_w_HD3850_MXM_Card/5753.html?doc=5753

too bad they didn't put HDMI 1.3 outputs :rolleyes:Auzentech has a HDMI1.3 soundcard, you connect the device or videocard with 1.2 or lower to the hdmi in on the soundcard, then it converts it to hdmi1.3(this does not add any new information except for the audio)

[leeperry]

so they finally rlsed it, and it does HD bitstream audio ?
I guess the fees to offer HDMI 1.3 must be very high, but soon or later we'll get HDMI 1.3 graphic cards I guess.

maybe with the new nvidia cards early next year ? :)

[yesgrey]

tritical,
I had another idea to increase speed and lower the size of the 3D LUT file... Why not include in the 3D LUT also the YUV->RGB conversion? (I think YUY2 would be enough)
The LUT size would be: 3x220x254x254 ~ 40.6MB < 48MB.
And is just adding the specification of the matrix we would like to use (BT.601 or BT.709) and the levels we want... (you already have part of that done in Colormatrix)

So the 3D LUT would become equivalent to:
Y'U'V'->R'G'B'->RGB->Color Correction->RGB->R'G'B'.

I think this would be a more powerfull and interesting solution, because some people only need the YUV->RGB conversion with a 3D LUT... perhaps it would be faster than the ConvertToRGB32()...;)

If you don't have time let me know, I could try changing just the C part of the code for calculating the 3D LUT file...

[tritical]

I am working on the next version, current list of changes to make:

1.) don't require z in the input files
2.) change the way out-of-gamut colors are handled
3.) Add an option to ddcc to use lut (basically it will just programmically invoke rgb3dlut after creating the lut file so you don't have to open the script twice).

@yesgrey3
Coding a yuy2 to rgb 3d lut filter wouldn't take much work (small modifications to rgb3dlut). I might include it in the next release of ddcc. If you could write a program to actually calculate the LUT files for use with it that would great :).

@leeperry
the difference I see seems much bigger than that, maybe the "/2.2" part has been ignored
It will be... it just reads fp values (sscanf(buf,"%lf",&val)).

On the topic of saturation correction. Maybe you could ask JohnAd what he did, because I still don't know how you could make any corrections based on the data you have.