gamut conversions through Avisynth ?

[yesgrey]

Originally Posted by leeperry

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

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?

Originally Posted by leeperry

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?...&postcount=288

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

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

[yesgrey]

Originally Posted by leeperry

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.

Originally Posted by leeperry

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

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") :



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

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

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 :



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)

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 :

[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

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)

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]

Originally Posted by leeperry

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

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



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)

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 :

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

[yesgrey]

Originally Posted by leeperry

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]

Originally Posted by tetsuo55

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.

Originally Posted by yesgrey3

b=0.0, c=1.0

ah! thanks. didn't think about that one

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 ?!



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

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

[yesgrey]

Originally Posted by leeperry

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]

Originally Posted by leeperry

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

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]

Originally Posted by yesgrey3

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]

Originally Posted by yesgrey3

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/i15...pp19201080.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.

Originally Posted by 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

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]

Originally Posted by 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.

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.

[yesgrey]

Originally Posted by tritical

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?

Originally Posted by leeperry

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.

Originally Posted by leeperry

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