gamut conversions through Avisynth ?

[yesgrey]

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 :)
Maybe you are right, I don't know. Would it be possible that you see all as green because you can't see the red part that is in the image?:confused:

so to get the "realtime" algorithm, I have to select CA3 right?
No.
-CA3 and "Out_Of_Gamut_Clipping 0" is the same as the PS script.
-CA1 and "Out_Of_Gamut_Clipping 0" is the same as ddcc realtime

[leeperry]

I mean, the PS script and ddcc realtime look quite similar...where ddcc in LUT burns the green gamma in my previous tests :
http://forum.doom9.org/showpost.php?p=1273996&postcount=288

don't tell me that the green is identical between all the charts...please :D

anyway, I will compare them again...if I can get the same colors as ddcc realtime I'll be a happy camper :thanks:

[yesgrey]

I mean, the PS script and ddcc realtime look quite similar...
Yes, but they are not equal, because ddcc performs chromatic adaptation using Linearized Bradford Transform, while PS script uses von Kries in XYZ.

don't tell me that the green is identical between all the charts...please :D
But I never said that the green is the same, what I say is that it could be more appealing... But there is a problem in the HUE method that you never noticed it, and it's pretty obvious... banding. If you look carefully, you see that with the simple clipping there are 4 tones of green, and with the "maintain hue dithering" there are only two tones of green and red. If you used that in your projector you should get lot's of banding, and that would be ugly. Even if the colors would be more appealing, it would be pretty useless.

[leeperry]

well, as I understand it there's some banding because my gamut exceed the red and doesn't match the green SMPTE-C references(clipping green and lowering the red "scale") :

http://www.image-load.eu/out.php/t158097_gamut.png (http://www.image-load.eu/out.php/i158097_gamut.png)

I sent you screenshots, the "green burning" makes everything green in movies.

anyway, I'll try the new cr3dlut build and hopefully I'll find something that I like http://forum-images.hardware.fr/images/perso/caloub.gif

the PS script already looks great you know, and I only have an Eye One Display 2 colorimeter, so w/o an uber-accurate freshly recalibrated spectrophotometer...this is major nit-picking IMVHO.

even though my i1d2 gives very close results to the Eye One Pro(the Calman coders said on AVS that the measurements difference wouldn't be visible on DLP front projectors), if the i1d2 gives a ΔE of 1, god knows if it wouldn't be 5 or 6 w/ a Minolta CS-200 :o

and the most saturated colors in the gamut are hardly ever used anyway?

[leeperry]

alright, I was kinda surprised to see how slow my o/c Q6600 was doing on 16bit LUT's...so I've done a few benchmarks :

ConvertToYUY2()
t3dlut("C:\16bit.3dlut",threads=4)
=117

ConvertToYUY2()
t3dlut("C:\8bit.3dlut",threads=4)
=360

ConvertToRGB32(matrix="rec709")
ddcc(chr_i=3,gam_i=5,ofile="C:\HC3100.txt",threads=4,opt=1)
=123

ConvertToYUY2()
rgb3dlut(lutfile="C:\HC3100_SMPTE-C.txt",itype=2,threads=4)
=480

ConvertToYUY2()
rgb3dlut(lutfile="C:\HC3100_SMPTE-C.txt",threads=4)
=555

yv12toyuy2(itype=2,threads=4)
rgb3dlut(lutfile="C:\HC3100_SMPTE-C.txt",threads=4)
=410

yv12toyuy2(itype=2,threads=4)
rgb3dlut(lutfile="C:\HC3100_SMPTE-C.txt",itype=2,threads=4)
=355

I don't really get why t3dlut is much slower than rgb3dlut on the same 8bit LUT(created in cr3dlut)...I guess it's not because of the new file format, so maybe some of the default options make it slower?

I understand 16bit LUT's give much better results in gray ramps, but it'd need further testing to see whether it's worth the HUGE performance drop. But mVR doesn't use any CPU cycles to run the 16bit LUT anyway? so it'd be a non-issue there.

Also, I think the picture is somewhat sharper in mVR...might need to play around w/ rgb3dlut's settings :)

[tritical]

t3dlut is slower than rgb3dlut because with all of the extra conversions I decided not to special case everything. Also there is no assembly. In rgb3dlut everything was special cased, and everything but itype=2 was in assembly.

in itype=2 I get an error msg w/ either b/c=0.0,1.0 or b/c="0.0,1.0"....anyone's got an idea how to use that?
What is the error message?

[leeperry]

It said that it was missing a " or a ( )...probably the "/" is confusing Avisynth, or I'm really missing some character?

And is it my imagination or yv12toyuy2(itype=2) + rgb3dlut(itype=2) look sharper than ConvertToYUY2() + rgb3dlut(itype=1) ? the PQ is really great!

also, you set the bicubic coeff to 0.75 in rgb3dlut and its yv12toyuy2 but it's 0.5 in t3dlut and its yv12toyuy2. I thought 0.6 was the most mathematically accurate, and 0.75 slightly sharper?

[leeperry]

so I've compared 8bit against 16bit dithered.

native BD content w/o rescaling in ffdshow or HR :

http://thumbnails14.imagebam.com/3312/7e4d6333119757.gif (http://www.imagebam.com/image/7e4d6333119757) http://thumbnails15.imagebam.com/3312/09600333119759.gif (http://www.imagebam.com/image/09600333119759)http://thumbnails19.imagebam.com/3312/8e730533119762.gif (http://www.imagebam.com/image/8e730533119762)

that's the cr3dlut .ini :
# Example input file for cr3dlut v2.0 and up
#
# Settings for creating a 3D LUT for a Custom display
# (including YCbCr->RGB conversion)
#

# Do not mess up with these settings
Chromatic_Adaptation 1
Input_Bit_Depth 8
Input_YCbCr_Full_Range 0
Input_Gamma 1
Output_Bit_Depth 16
Output_YCbCr_Matrix 0
Output_RGB_Black_White 0 255

# You can change the following settings

# for BT.709 use '1'; for BT.601 use '3'
Input_YCbCr_Matrix 1

# for HDTV use '0'; for EBU use '2'; for SMPTE-C use '3'
Input_Primaries 0

# put here your primaries and white point xy coordinates, RGBW order.
Output_Primaries 1

# if you want to try other gamma values change the 0.45 value accordingly
Output_Gamma 1

left side is
yv12toyuy2(itype=2,threads=4)
t3dlut("C:\test_8bit.3dlut",threads=4)

right side is
yv12toyuy2(itype=2,threads=4)
t3dlut("C:\test_16bit.3dlut",threads=4)

http://thumbnails18.imagebam.com/3312/4bf71433119768.gif (http://www.imagebam.com/image/4bf71433119768)http://thumbnails14.imagebam.com/3312/9c07d933119771.gif (http://www.imagebam.com/image/9c07d933119771)
http://thumbnails3.imagebam.com/3312/6c78d433119774.gif (http://www.imagebam.com/image/6c78d433119774)http://thumbnails5.imagebam.com/3312/ecc28233119777.gif (http://www.imagebam.com/image/ecc28233119777)
http://thumbnails18.imagebam.com/3312/44233233119780.gif (http://www.imagebam.com/image/44233233119780)http://thumbnails8.imagebam.com/3312/ce24aa33119782.gif (http://www.imagebam.com/image/ce24aa33119782)
http://thumbnails9.imagebam.com/3312/13ab1f33119790.gif (http://www.imagebam.com/image/13ab1f33119790)http://thumbnails18.imagebam.com/3312/3e81e533119791.gif (http://www.imagebam.com/image/3e81e533119791)
http://thumbnails.imagebam.com/3312/79db7633119794.gif (http://www.imagebam.com/image/79db7633119794)http://thumbnails10.imagebam.com/3312/7900e533119799.gif (http://www.imagebam.com/image/7900e533119799)

some of my comparisons didn't make it through to my imagehost coz they were >3MB, but I can't really say that it ever made any visible difference on that BD(MPEG2).

Kazuya has been kind enough to encode some test patterns in 16-235 h264, so they could go through my Avisynth ffdshow pipeline like any other video.

left side is 8bit/right side is 16 :

http://thumbnails14.imagebam.com/3313/caf19c33121658.gif (http://www.imagebam.com/image/caf19c33121658)http://thumbnails19.imagebam.com/3313/38621933121661.gif (http://www.imagebam.com/image/38621933121661)
http://thumbnails17.imagebam.com/3313/47073033121664.gif (http://www.imagebam.com/image/47073033121664)http://thumbnails11.imagebam.com/3313/178c1d33121667.gif (http://www.imagebam.com/image/178c1d33121667)
http://thumbnails19.imagebam.com/3313/47817033121669.gif (http://www.imagebam.com/image/47817033121669)http://thumbnails19.imagebam.com/3313/ebd8a133121672.gif (http://www.imagebam.com/image/ebd8a133121672)

[leeperry]

last but not least, I wanted to try 0-255 native content so we could see if xvYCC would make an even bigger difference....but ImageSource() seems to convert to TV levels anyway :confused:

so left side is 8bit, right side is 16. Both using this script :
ImageSource("C:\Faces_1920x1080.jpg",pixel_type="RGB32")
ConvertToYUY2(matrix="pc.709")
t3dlut("C:\test_16bit.3dlut",threads=4)

http://thumbnails15.imagebam.com/3313/487c7733121647.gif (http://www.imagebam.com/image/487c7733121647)http://thumbnails11.imagebam.com/3313/90783233121651.gif (http://www.imagebam.com/image/90783233121651)
http://thumbnails.imagebam.com/3313/fc70fa33121654.gif (http://www.imagebam.com/image/fc70fa33121654)http://thumbnails8.imagebam.com/3313/6ed56833121656.gif (http://www.imagebam.com/image/6ed56833121656)

if anyone knows how to encode image files in 0-255 h264, I'll update my posts. The test patterns are available here : http://www.burosch.de/shop/shop_content.php?coID=136&

[tetsuo55]

so I've compared 8bit against 16bit dithered.

native BD content w/o rescaling in ffdshow or HR :

http://thumbnails14.imagebam.com/3312/7e4d6333119757.gif (http://www.imagebam.com/image/7e4d6333119757) http://thumbnails15.imagebam.com/3312/09600333119759.gif (http://www.imagebam.com/image/09600333119759)http://thumbnails19.imagebam.com/3312/8e730533119762.gif (http://www.imagebam.com/image/8e730533119762)

that's the cr3dlut .ini :
# Example input file for cr3dlut v2.0 and up
#
# Settings for creating a 3D LUT for a Custom display
# (including YCbCr->RGB conversion)
#

# Do not mess up with these settings
Chromatic_Adaptation 1
Input_Bit_Depth 8
Input_YCbCr_Full_Range 0
Input_Gamma 1
Output_Bit_Depth 16
Output_YCbCr_Matrix 0
Output_RGB_Black_White 0 255

# You can change the following settings

# for BT.709 use '1'; for BT.601 use '3'
Input_YCbCr_Matrix 1

# for HDTV use '0'; for EBU use '2'; for SMPTE-C use '3'
Input_Primaries 0

# put here your primaries and white point xy coordinates, RGBW order.
Output_Primaries 1

# if you want to try other gamma values change the 0.45 value accordingly
Output_Gamma 1

left side is
yv12toyuy2(itype=2,threads=4)
t3dlut("C:\test_8bit.3dlut",threads=4)

right side is
yv12toyuy2(itype=2,threads=4)
t3dlut("C:\test_16bit.3dlut",threads=4)

http://thumbnails18.imagebam.com/3312/4bf71433119768.gif (http://www.imagebam.com/image/4bf71433119768)http://thumbnails14.imagebam.com/3312/9c07d933119771.gif (http://www.imagebam.com/image/9c07d933119771)
http://thumbnails3.imagebam.com/3312/6c78d433119774.gif (http://www.imagebam.com/image/6c78d433119774)http://thumbnails5.imagebam.com/3312/ecc28233119777.gif (http://www.imagebam.com/image/ecc28233119777)
http://thumbnails18.imagebam.com/3312/44233233119780.gif (http://www.imagebam.com/image/44233233119780)http://thumbnails8.imagebam.com/3312/ce24aa33119782.gif (http://www.imagebam.com/image/ce24aa33119782)
http://thumbnails9.imagebam.com/3312/13ab1f33119790.gif (http://www.imagebam.com/image/13ab1f33119790)http://thumbnails18.imagebam.com/3312/3e81e533119791.gif (http://www.imagebam.com/image/3e81e533119791)
http://thumbnails.imagebam.com/3312/79db7633119794.gif (http://www.imagebam.com/image/79db7633119794)http://thumbnails10.imagebam.com/3312/7900e533119799.gif (http://www.imagebam.com/image/7900e533119799)

some of my comparisons didn't make it through to my imagehost coz they were >3MB, but I can't really say that it ever made any visible difference.

Kazuya has been kind enough to encode some test patterns in 16-235 h264, so they could go through my Avisynth ffdshow pipeline like any other video.

left side is 8bit/right side is 16 :

http://thumbnails14.imagebam.com/3313/caf19c33121658.gif (http://www.imagebam.com/image/caf19c33121658)http://thumbnails19.imagebam.com/3313/38621933121661.gif (http://www.imagebam.com/image/38621933121661)
http://thumbnails17.imagebam.com/3313/47073033121664.gif (http://www.imagebam.com/image/47073033121664)http://thumbnails11.imagebam.com/3313/178c1d33121667.gif (http://www.imagebam.com/image/178c1d33121667)
http://thumbnails19.imagebam.com/3313/47817033121669.gif (http://www.imagebam.com/image/47817033121669)http://thumbnails19.imagebam.com/3313/ebd8a133121672.gif (http://www.imagebam.com/image/ebd8a133121672)

I don't think you used the best samples, both of those movies are mostly computer generated using 8bit rgb(or lower) textures

[yesgrey]

in itype=2 I get an error msg w/ either b/c=0.0,1.0 or b/c="0.0,1.0"....anyone's got an idea how to use that?

b=0.0, c=1.0

[leeperry]

I don't think you used the best samples, both of those movies are mostly computer generated using 8bit rgb(or lower) textures
I can't seem to find any free imagehost that accepts files bigger than 3MB, so I've put the remaining comparisons there : http://rapidshare.com/files/223274625/t3dlut.rar.html

except for the inflated filesize in 16bit, they look identical to me.

but in the test patterns, gray ramps on top look better in the photo w/ the 2 women in 16bit.....very slight improvement, though.

b=0.0, c=1.0
ah! thanks. didn't think about that one :rolleyes:

so what would be some good value ? 0.0/0.75? or 0.0/0.60?


BTW, I was trying to get this test pattern through HR and mVR....but colors don't come off the same way ?! :o

http://www.image-load.eu/out.php/t158401_Zone70pp19201080.jpg (http://www.image-load.eu/out.php/i158401_Zone70pp19201080.jpg)

the mVR .PNG is 4MB, so I had to make a RAR again w/ the 2 files :
http://rapidshare.com/files/223278460/compare.rar.html

the idea was to check for sharpening, and apart from the different colors this should be OK :)

the test pattern is available here(it's the last one in the MP4 container) : http://www.megaupload.com/?d=B6R60TE0

in HR, I put this in ffdshow :
yv12toyuy2(itype=2,threads=4)
t3dlut("C:\madVR\HD.3dlut")

and in mVR 0.5, I disabled ffdshow and used the same "HD.3dlut"....so I can't really explain this color difference :o

I tried it both in the MP4 file, and using ImageSource()...colors always come off different..

[yesgrey]

so what would be some good value ? 0.0/0.75? or 0.0/0.60?
You could try 0.0/0.5 or 1.0/0.0.

[yesgrey]

BTW, I was trying to get this test pattern through HR and mVR....but colors don't come off the same way ?! :o
HR image is using Video levels, and madVR image is using PC levels. Check your settings.;)

[leeperry]

@tritical: any chance you could make yv12toyuy2() fallback to itype=0 if it's not mod4 please? coz I can't make rules in ffdshow on that criteria, so yv12toyuy2() can't really be used on all videos at this point :(

[leeperry]

You could try 0.0/0.5 or 1.0/0.0.
b/c -

Adjusts properties of cubic interpolation (itype=2). Same as Avisynth's BicubicResize filter.

default: 0.0,0.75
http://avisynth.org/mediawiki/Resize
BicubicResize is similar to BilinearResize, except that instead of a linear filtering function it uses the Mitchell-Netravali two-part cubic. The parameters b and c can be used to adjust the properties of the cubic, they are sometimes referred to as "blurring" and "ringing" respectively.

With b = 0 and c = 0.75 the filter is exactly the same as VirtualDub's "precise bicubic" and the results are identical except for the VirtualDub scaling problem mentioned above. The default is b = 1./3. and c = 1./3., which were the values recommended by Mitchell and Netravali as yielding the most visually pleasing results in subjective tests of human beings. Larger values of b and c can produce interesting op-art effects--for example, try b = 0 and c = -5.

If you are magnifying your video, you will get much better-looking results with BicubicResize than with BilinearResize. However, if you are shrinking it, you are probably just as well off, or even better off, with BilinearResize. Although VirtualDub's bicubic filter does produce better-looking images than its bilinear filter, this is mainly because the bicubic filter sharpens the image, not because it samples it better. Sharp images are nice to look at--until you try to compress them, at which point they turn nasty on you very quickly. The BicubicResize default doesn't sharpen nearly as much as VirtualDub's bicubic, but it still sharpens more than the bilinear. If you plan to encode your video at a low bitrate, I wouldn't be at all surprised if BilinearResize yields better quality.

You have to set "b + 2 * c = 1" for the numerically most accurate filter. This gives for b = 0 the maximum value for c = 0.5, which is the Catmull-Rom spline and a good suggestion for sharpness.

From c>0.6 the filter starts to "ring". You won't get real sharpness, what you'll get is crispening like on a TV set. No negative values are allowed for b. Then stay on b=0.

I'll try to force 0.0/0.5, because it's the default values in t3dlut() but not in rgb3dlut(0.75)

[leeperry]

HR image is using Video levels, and madVR image is using PC levels. Check your settings.;)
ah indeed, I didn't pay attention that there was some new settings in mVR...

and whatever I set "c" to 0.5/0.6/0.75/1.0 in rgb3dlut(), this test pattern gives CRC identical outputs : http://www.image-load.eu/out.php/i158401_Zone70pp19201080.jpg

[tritical]

That test pattern is grayscale. b and c only effect chroma upsampling.

Also, I didn't say it in the readme, but t3dlut expects raw lut files (not 3dlut format) to be stored such that the lookup is calculated r<<16+g<<8+b (which is the same as the 3dlut format). While rgb3dlut expects g<<16+b<<8+r. So lut files created with ddcc can't be used with t3dlut. However, yesgrey3's app can create LUT's the same as ddcc that will work with t3dlut so I don't plan to change ddcc.

@tritical: any chance you could make yv12toyuy2() fallback to itype=0 if it's not mod4 please? coz I can't make rules in ffdshow on that criteria, so yv12toyuy2() can't really be used on all videos at this point

I will think it about it, but why not just use converttoyuy2()? Especially if you are willing to accept itype=0 (nearest neighbor) in yv12toyuy2().

[leeperry]

That test pattern is grayscale. b and c only effect chroma upsampling.

Also, I didn't say it in the readme, but t3dlut expects raw lut files (not 3dlut format) to be stored such that the lookup is calculated r<<16+g<<8+b (which is the same as the 3dlut format). While rgb3dlut expects g<<16+b<<8+r. So lut files created with ddcc can't be used with t3dlut. However, yesgrey3's app can create LUT's the same as ddcc that will work with t3dlut so I don't plan to change ddcc.

I will think it about it, but why not just use converttoyuy2()? Especially if you are willing to accept itype=0 (nearest neighbor) in yv12toyuy2().
oh OK, so t3dlut only works with .txt LUT's, not .3dlut...now that's confusing...how come it even works then?

well, the idea is that most files are mod4 anyway, so you can use yv12toyuy2(itype=2) but sometimes you have files that are mod2...and IIRC only itype=0 works on mod2.

so if yv12toyuy2() could either fall back to a mod2-compatible mode, or to ConvertToYUY2(it's GPL right? only a matter of cut/paste?)...that would make life easier when you run them in ffdshow instead of getting an error msg.

:thanks:

[yesgrey]

Also, I didn't say it in the readme, but t3dlut expects raw lut files (not 3dlut format) to be stored such that the lookup is calculated r<<16+g<<8+b (which is the same as the 3dlut format). While rgb3dlut expects g<<16+b<<8+r. So lut files created with ddcc can't be used with t3dlut. However, yesgrey3's app can create LUT's the same as ddcc that will work with t3dlut so I don't plan to change ddcc.
tritical,
cr3dlut currently works like this:
-3dlut format: r<<16+g<<8+b
-raw format: g<<16+b<<8+r
I made it like this to let cr3dlut create files for both t3dlut and rgb3dlut. I thought that t3dlut's raw format was the same as rgb3dlut... Do you think I should change my raw format to r<<16+g<<8+b?

but why is the default 0.75 in rgb3dlut/yv12toyuy2 and 0.5 in t3dlut/yv12toyuy2? apparently 0.75 is sharper but 0.5 is "neutral" ?
Avisynth's help says that 0.0/0.5 is the most sharp without ringing. I have suggested tritical to change the defaults to these values, and it seems he agreed with the idea.;)

and is it my imagination or using itype=2 in yv12toyuy2()/rgb3dlut() make the picture sharper than the default options?
Yes it makes. The default in rgb3dlut is itype=1.
You should start reading the help more thoroughly...;)

[leeperry]

Avisynth's help says that 0.0/0.5 is the most sharp without ringing. I have suggested tritical to change the defaults to these values, and it seems he agreed with the idea.;)


Yes it makes. The default in rgb3dlut is itype=1.
You should start reading the help more thoroughly...;)
1) OK, I'll try several values w/ a test pattern tomorrow but indeed 0.5 looks good in yv12toyuy2/rg3dlut and ffdshow(when downscaling BD to 720p)
2) I did. but it's not too self-explanatory that "linear interpolation" doesn't look as good as "Mitchell-Netravali two-part cubic interpolation"...especially when ppl advise to have very blurry chroma :o

And what are the real world differences between the different itypes of yv12toyuy2() and ConvertToYUY2()...the way they align chroma pixels and how sharp they upsample chroma I think? so if itype2 0.5 is the best, how does Convert() fare against it?

[yesgrey]

And what are the real world differences between the different itypes of yv12toyuy2() and ConvertToYUY2()
I think ConvertToYUY2() is the same as yv12toyuy2(itype=1).

[tritical]

oh OK, so t3dlut only works with .txt LUT's, not .3dlut...now that's confusing...how come it even works then?
t3dlut works with 3dlut format files (it doesn't rely on the extension to detect them), and with raw lut files (i.e. the lut file contains just the entries without a header). rgb3dlut worked only with raw lut files since it was created before the 3dlut format. The difference is that rgb3dlut expects the entries in the raw lut file to be stored in different positions than t3dlut does.

I made it like this to let cr3dlut create files for both t3dlut and rgb3dlut. I thought that t3dlut's raw format was the same as rgb3dlut... Do you think I should change my raw format to r<<16+g<<8+b?
No, I think the way it is is good. If the user wants to use t3dlut they can always output as 3dlut format, or if they want to use rgb3dlut they can output as raw. For uses that don't need t3dlut's extra features, rgb3dlut is better since it is faster.

And what are the real world differences between the different itypes of yv12toyuy2() and ConvertToYUY2()...the way they align chroma pixels and how sharp they upsample chroma I think? so if itype2 0.5 is the best, how does Convert() fare against it?
As yesgrey3 said, converttoyuy2() is the same as yv12toyuy2 with itype=1 and yv12toyuy2's default chroma placement settings. And yes, the differences between converttoyv12() and yv12toyuy2() are simply the upsampling method and chroma placement assumption.

There isn't really a best setting for b/c. Your question is the same as how does bilinearresize() compare to bicubicresize()? and how do different values of b/c effect bicubicresize()?... just applied to chroma resampling. I personally can't tell the difference between converttoyuy2() and converttoyv12(itype=2), assuming the same chroma placement, except when zooming in under extreme cases.

Also, why can't your script use a line like:

mod_4_check() ? yv12toyuy2() : converttoyuy2()

Obviously you'd have to script your own mod_4_check, but it should be pretty easy.

[leeperry]

alright, I'll just stick to ConvertToYUY2() + rgb3dlut(itype=2,b=0.00,c=0.5)...no worries, PQ is great and it's very fast :)

[leeperry]

ah well, maybe it's psychological but I still find yv12toyuy2(itype=2,threads=4,b=0.00,c=0.5) more appealing than ConvertToYUY2()

there's no chance you could get it to work w/ mod2? like padding additional lines and removing them afterwards?

madshi advises to go for blurry chroma(softcubic), so I'm not sure...maybe it's all in my head :o

[madshi]

Avisynth's help says that 0.0/0.5 is the most sharp without ringing. I have suggested tritical to change the defaults to these values, and it seems he agreed with the idea.;)
Unfortunately the AviSynth help is wrong. 0.0/0.5 *does* ring. Not as much as e.g. 0.0/0.75, and not as much as e.g. Lanczos, but 0.0/0.5 does ring. If you don't want ringing, use e.g. 0.33/0.33 (Mitchell-Netravali). Or maybe 0.5/0.5 (madVR calls this "SoftCubic50"). Personally, I even prefer 1.0/0.0 which is *very* soft, but totally aliasing free and ringing free.

[leeperry]

I even prefer 1.0/0.0 which is *very* soft, but totally aliasing free and ringing free.
indeed ConvertToYUY2() + rgb3dlut(itype=2,b=1.0,c=0.0) look really great http://forum-images.hardware.fr/images/perso/otakonleboss.gif

maybe it appears sharper because the chroma is very soft, and LSF only sharpens the luma I think...so at least the chroma doesn't "interfere".

ffdshow only offers one negative parameter for bicubic downscaling(from 1080p to 720p) so I've set it to -0.5....looks good too I think, not too sharp, not too blurry :)

[leeperry]

@tritical: so is it normal that ddcc in realtime and rgb3dlut w/ a ddcc RGB LUT don't output the same colors ? :(

http://forum.doom9.org/showpost.php?p=1273996&postcount=288

cr3dlut still suffers from the same kind of problem, I guess I'll be using ddcc in realtime in HR for a while...at least colors are great(identical to the PS script) and HR is very smooth in 48Hz(unlike EVR/VMR/etc) :)

that'd be great if you could let ddcc output identical RGB LUT's to ddcc in realtime, if any possible :o

:thanks:

[tritical]

The only difference between ddcc directly and ddcc's lut in rgb3dlut is the handling of out-of-gamut colors (capping of channels individually vs adjusting all 3 to maintain hue). Didn't yesgrey3 add an option in his program to do it both ways? Does that not work as expected?

[yesgrey]

Didn't yesgrey3 add an option in his program to do it both ways? Does that not work as expected?
Yes, I did. He's right, though, there is a strange thing with the results. I'm investigating to see what's happenning...

Another question.
Do you think it should be preferable (more accurate) to use t3dlut to convert from YCbCr->YCbCr instead of using ColorMatrix?

[tritical]

Yes, I did. He's right, though, there is a strange thing with the results. I'm investigating to see what's happenning...

Alright. I think I did a test where I changed the lut creation code in ddcc to cap the channels individually and then compared rgb3dlut with that lut vs ddcc directly and the outputs were identical. I'll go back and check though.

Do you think it should be preferable (more accurate) to use t3dlut to convert from YCbCr->YCbCr instead of using ColorMatrix?
Maybe. Colormatrix basically upsamples chroma using nearest neighbor, and does the conversion using integer approximation for speed. So mathematically t3dlut would be more accurate, but I don't know if the difference would be noticeable.

[yesgrey]

I'll go back and check though.
I don't know yet if it's a problem with both ddcc and cr3dlut 3DLUT's or if it's only a problem with cr3dlut... Maybe it's better if you wait until I see if the problem is the samew with both...;)

[leeperry]

The only difference between ddcc directly and ddcc's lut in rgb3dlut is the handling of out-of-gamut colors (capping of channels individually vs adjusting all 3 to maintain hue). Didn't yesgrey3 add an option in his program to do it both ways? Does that not work as expected?
ok, but if you try my settings, you can see that the green levels are completely burned using a LUT...

yesgrey has changed this behavior in his latest build of cr3dlut, but colors are still quite off..mostly red is too saturated this time.

if you could please make the out-of-gamut colors behave the same exact way in a LUT as they do w/ realtime ddcc..that'd be really great :)

I very much enjoyed ConvertToYUY2() + rgb3dlut(itype=2,b=1.0,c=0.0)...it doesn't use much CPU and the chroma is very soft, which makes the luma cleaner and clearer to look at.

:thanks:

[leeperry]

@yesgrey: if you ever plan to import Color.HCFR saturations into cr3dlut, I've just found out that you can measure them on 10 points :

http://img19.imageshack.us/img19/5627/satz.png

http://rapidshare.com/files/233048376/05-14_HC3100.chc.html

and hopefully if tritical has time to find the diff between LUT/realtime out-of-gamut colors management, will you be able to export the change to cr3dlut? seems like mVR will be ripe anytime soon, and I'd like to play too :)

:thanks:

[leeperry]

hi guys, any news by any chance? :)

ideally if ddcc could treat out-of-gamut colors in a LUT the same way it does in realtime, that would enable far more ppl(including DLP users like me) to be able to use a LUT to convert gamuts...atm I'm playing around w/ 48fps content, and I simply don't have enough CPU cycles to run ddcc in realtime :(

:thanks:

[tritical]

I changed ddcc to clip in the same fashion during lut file creation that it does during realtime usage, and when using the resulting lut file with rgb3dlut the output is identical to ddcc realtime. I put up a new ddcc version with the ability to set the clipping method during lut creation on my website. However, the lut format that ddcc uses for output isn't compatible with anything but rgb3dlut. If I get time I might add the ability to output in .3dlut format. It'll take more investigating to figure out what the difference is between ddcc and cr3dlut.

[leeperry]

awesome, thank you tritical!

I was about to give up on gamut conversion for now on 48p content, this definitely cheers me up! http://forum-images.hardware.fr/images/perso/sniperr.gif

ideally, if it could also output YUY2 LUT's, that'd be even better...or maybe yesgrey could commit your code change to cr3dlut? :)

[tritical]

That's just it, cr3dlut already has that change (Out_Of_Gamut_Clipping=0). Anyways, I did some quick tests, and using rgb3dlut with cr3dlut's lut file is giving me exactly the same results as with ddcc's lut file (for both Out_Of_Gamut_Clipping=0/oog=0 and Out_Of_Gamut_Clipping=1/oog=1) . Could you give an example that is producing different output. I'll see if there is any difference with cr3dlut's .3dlut output loaded with t3dlut.

Using t3dlut with rgb input and cr3dlut's .3dlut output is fine.

There seem to be some major differences in flat color areas between:

convertToRGB32().rgb3dlut()
converttoyuy2().t3dlut()

the second one using cr3dlut's .3dlut output. I'll do some more testing.

[leeperry]

well, did you try this? http://forum.doom9.org/showpost.php?p=1273996&postcount=288

the latest build of cr3dlut definitely doesn't output the same colors as ddcc in realtime(even w/ Out_Of_Gamut_Clipping=0), and yesgrey confirmed it. red is too saturated and the green gamma is still way too bright.

I will give a go at the new version, w/ the settings from this url :)

PS: oops, I gave all the detailed files to yesgrey, but didn't post them on the forum...I'll look into it tomorrow morning and will post every file so you can reproduce(if a problem still occurs).

[tritical]

I believe I tested that exact example, or close to it, using your monitor values that you posted a while ago. cr3dlut file used to create "cr3dlut":

Chromatic_Adaptation 1
Out_Of_Gamut_Clipping 0
Input_Bit_Depth 8
Input_YCbCr_Matrix 0
Input_YCbCr_Full_Range 0
Input_RGB_Black_White 0 255
Input_Primaries 3
Input_Gamma 9 1.0 0.0 0.45 0.0
Output_Bit_Depth 8
Output_YCbCr_Matrix 0
Output_RGB_Black_White 0 255
Output_YCbCr_Full_Range 0
Output_Primaries 9 0.656 0.332 0.342 0.610 0.151 0.071 0.311 0.330
Output_Gamma 9 1.0 0.0 0.45 0.0

ddcc(chr_i=3,gam_i=5,ofile="t.txt",lutfile="ddcclut",oog=0)

t.txt is:

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

then tested the difference between:

converttorgb32().ddcc(chr_i=3,gam_i=5,ofile="t.txt")
converttorgb32().rgb3dlut(lutfile="cr3dlut")
converttorgb32().rgb3dlut(lutfile="ddcclut")

and all were the same. I also had cr3dlut output a matching .3dlut format file, and used it with t3dlut. That gave the same output. So far the only differences I have found are when cr3dlut includes the yuv->rgb conversion.

[leeperry]

that was something along the lines

# Example input file for cr3dlut v2.0 and up
#
# Settings for creating a 3D LUT for a Custom display
# (including YCbCr->RGB conversion)
#

# Do not mess up with these settings
Chromatic_Adaptation 1
Out_Of_Gamut_Clipping 0
Input_Bit_Depth 8
Input_YCbCr_Full_Range 1
Input_Gamma 9 1.0 0.0 0.45 0.0
Output_Bit_Depth 8
Output_YCbCr_Matrix 0
Output_RGB_Black_White 0 255

# You can change the following settings

# for BT.709 use '1'; for BT.601 use '3'
Input_YCbCr_Matrix 1

# for HDTV use '0'; for EBU use '2'; for SMPTE-C use '3'
Input_Primaries 3

# put here your primaries and white point xy coordinates, RGBW order.
Output_Primaries 9 0.6530 0.3300 0.3390 0.6120 0.1500 0.0700 0.3120 0.3280

# if you want to try other gamma values change the 0.45 value accordingly
Output_Gamma 9 1.0 0.0 0.45 0.0

0.150
0.070
0.339
0.612
0.653
0.330
0.312
0.328
1
0.0
0.45
0.0
0.0

even this last bit didn't yield the same colors between ddcc realtime/ddcc LUT w/ this test pattern : http://www.megaupload.com/?d=F8DES6ZN

[tritical]

Do you get the same output when you don't have cr3dlut perform the yuv->rgb conversion? From my testing it appears that differences only arise when cr3dlut's lut includes the yuv->rgb conversion as opposed to converting to rgb in avisynth first.

EDIT 1:
After some more tests, cr3dlut's yuv->rgb lut works when no gamma/gamut changes are required... i.e. only doing yuv->rgb conversion. Once the gamma/gamut conversions are thrown in the values are off.

EDIT 2:
I think there is a bug in v2.1 of cr3dlut. I built v2.0 from the source, and building a lut with it, "lut.3dlut", using the following config file:

Chromatic_Adaptation 1
Input_Bit_Depth 8
Input_YCbCr_Matrix 1
Input_YCbCr_Full_Range 0
Input_RGB_Black_White 0 255
Input_Primaries 3
Input_Gamma 9 1.0 0.0 0.45 0.0
Output_Bit_Depth 8
Output_YCbCr_Matrix 0
Output_YCbCr_Full_Range 0
Output_RGB_Black_White 0 255
Output_Primaries 9 0.656 0.332 0.342 0.610 0.151 0.071 0.311 0.330
Output_Gamma 9 1.0 0.0 0.45 0.0

the output of these two match:

converttorgb32(interlaced=false,matrix="Rec709").ddcc(chr_i=3,gam_i=5,ofile="t.txt",ulut=true,lutfile="t",oog=1)
converttoyuy2(interlaced=false).t3dlut(itypeU=1,cplaceU=0,lutfile="lut.3dlut",destcs=2)

but building a lut file using v2.1 with this config file (the only difference is the Out_Of_Gamut_Clipping=1 which shouldn't change anything):

Chromatic_Adaptation 1
Out_Of_Gamut_Clipping 1
Input_Bit_Depth 8
Input_YCbCr_Matrix 1
Input_YCbCr_Full_Range 0
Input_RGB_Black_White 0 255
Input_Primaries 3
Input_Gamma 9 1.0 0.0 0.45 0.0
Output_Bit_Depth 8
Output_YCbCr_Matrix 0
Output_YCbCr_Full_Range 0
Output_RGB_Black_White 0 255
Output_Primaries 9 0.656 0.332 0.342 0.610 0.151 0.071 0.311 0.330
Output_Gamma 9 1.0 0.0 0.45 0.0

gives completely different output. Hopefully yesgrey3 can look into it.

[yesgrey]

So far the only differences I have found are when cr3dlut includes the yuv->rgb conversion.
Yes, I have already reached this point too. I'm still trying to arrange some free time to find what's the problem...

Edit: tritical, thanks for your help, I will test with your examples.;)

[leeperry]

http://thumbnails14.imagebam.com/3767/81271937662519.gif (http://www.imagebam.com/image/81271937662519) http://thumbnails10.imagebam.com/3767/3dc7c437662523.gif (http://www.imagebam.com/image/3dc7c437662523) http://thumbnails14.imagebam.com/3767/99738b37662525.gif (http://www.imagebam.com/image/99738b37662525)
http://thumbnails6.imagebam.com/3767/26e99037662527.gif (http://www.imagebam.com/image/26e99037662527) http://thumbnails17.imagebam.com/3767/d21d9f37662529.gif (http://www.imagebam.com/image/d21d9f37662529) http://thumbnails15.imagebam.com/3767/4a5c4837662531.gif (http://www.imagebam.com/image/4a5c4837662531)

1)
colorYUV(levels="tv->pc") in ffdshow
dithered 0-255 RGB32HQ in ffdshow > HR

2)
colorYUV(levels="tv->pc") in ffdshow
dithered 0-255 RGB32HQ in ffdshow > VMR9 Renderless (mixer mode disabled)

1 and 2 match!

3)
colorYUV(levels="tv->pc") in ffdshow
dithered 0-255 RGB32HQ in ffdshow > VMR9 Renderless (mixer mode disabled)
+ PS script to convert gamut to SMPTE-C

4)
colorYUV(levels="tv->pc")
ConvertToRGB32(matrix="pc.709")
ddcc(chr_i=3,gam_i=5,ofile="X:\HC3100.txt",threads=4,opt=1)
RGB32 in ffdshow > HR

===

ddcc(chr_i=3,gam_i=5,ofile="X:\HC3100.txt",lutfile="X:\3100_SMPTE-C_oog0.txt",oog=0,threads=4,opt=1)

ddcc(chr_i=3,gam_i=5,ofile="X:\HC3100.txt",lutfile="X:\3100_SMPTE-C_oog1.txt",oog=1,threads=4,opt=1)

===

5)
colorYUV(levels="tv->pc")
ConvertToRGB32(matrix="pc.709")
rgb3dlut(lutfile="X:\3100_SMPTE-C_oog0.txt",threads=4,itype=2,b=1.0,c=0.0)
RGB32 in ffdshow > HR

6)
colorYUV(levels="tv->pc")
ConvertToRGB32(matrix="pc.709")
rgb3dlut(lutfile="X:\3100_SMPTE-C_oog1.txt",threads=4,itype=2,b=1.0,c=0.0)
RGB32 in ffdshow > HR

3/4/5 match! well done :)

I don't see how 6 would be useful to anyone ?! maybe if your original gamut can fully include the new one?

well, yesgrey knows there's some problems in cr3dlut, I'll be most happy to try any new version :thanks:

[leeperry]

but, rgb3dlut() used to be faster than t3dlut() in the past...not the case anymore :confused:

ConvertToRGB32(matrix="pc.709")
=275

ConvertToRGB32(matrix="pc.709")
t3dlut(lutfile="X:\3100_SMPTE-C_oog0.txt",threads=4)
=200

ConvertToRGB32(matrix="pc.709")
rgb3dlut(lutfile="X:\3100_SMPTE-C_oog0.txt",threads=4,itype=2,b=1.0,c=0.0)
=198

or it's only much faster in YUY2, but not in RGB32?

EDIT: ConvertToRGB32() is really wasting CPU cycles here :(
I was able to get 480fps from
ConvertToYUY2()
rgb3dlut(lutfile="C:\HC3100_SMPTE-C.txt",itype=2,threads=4)

http://forum.doom9.org/showpost.php?p=1275498&postcount=405

[yesgrey]

I don't see how 6 would be useful to anyone ?! maybe if your original gamut can fully include the new one?
That's the most common situation. In general, the color gamuts of the new projectors are much larger than the standards...

[leeperry]

ok well, I wonder how it'd differ to oog=0 in that case...but anyway I'm happy w/ oog=0

all the 720p DLP have a lack of green AFAIK..

anyway, if I got it right cr3dlut 2.0 is fine? all it needs is oog=0 basically?

[tritical]

Speed difference between t3dlut and rgb3dlut should be pretty small for rgb->rgb and using multiple threads. rgb3dlut should be faster for yuy2->rgb, as you've observed.

I also found a bug in t3dlut with yuy2 input and itypeU=1/cplaceU=0... the right edge pixels are not handled correctly.

[yesgrey]

I've just released here (http://yesgrey3.totalh.com/) cr3dlut v2.2.
v2.2 - 2009/06/03
- Fixed: when performing both Y'CbCr->R'G'B' and color gamut conversions some errors could occur


Once again, I've just released the executable. The source code is still v2.0.
This is 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.

[73ChargerFan]

Article on ars technica: Expanding the gamut: Sharp to increase color range of LCDs (http://arstechnica.com/gadgets/news/2009/06/expanding-the-gamut-sharp-to-increase-color-range-of-lcds.ars)


The company's new design adds cyan and yellow to the standard red, green, and blue subpixels found in other LCDs. This allows the display to reproduce nearly the color defined by the Pointer color space, a standard based on measurements of real world inks, paints, and pigments. Sharp claims this makes images displayed on the device "identical in appearance to real-world objects."