gamut conversions through Avisynth ? [Archive] - Page 4

leeperry

28th January 2009, 15:42

The Luts designation refers to the black and white in RGB.
The BT.709_0-255 is
Y:16-235 -> RGB: 0-255
and the BT.709_16-235 is
Y:16-235 -> RGB: 16-235
well, I think you told me that PC/TV levels didn't matter for colorimetry matters...what I need is full range YUY2 to full range RGB32 conversion(in 601 & 709)

BTW I've definitely had to lower my sharpening in ffdshow one notch, that smearing red was tempering w/ the PQ apparently..

so here we go again :

Convert() 609 / ddcc() 609 / ffdshow 609 RGB32(not HQ, same as the ATi drivers in YV12/YUY2)

http://thumbnails12.imagebam.com/2491/2d15aa24903098.gif (http://www.imagebam.com/image/2d15aa24903098)http://thumbnails14.imagebam.com/2491/4a0ede24903105.gif (http://www.imagebam.com/image/4a0ede24903105)http://thumbnails11.imagebam.com/2491/dd153924903110.gif (http://www.imagebam.com/image/dd153924903110)
http://thumbnails15.imagebam.com/2491/c7b08524903114.gif (http://www.imagebam.com/image/c7b08524903114)http://thumbnails11.imagebam.com/2491/51812224903124.gif (http://www.imagebam.com/image/51812224903124)http://thumbnails14.imagebam.com/2491/ec623824903131.gif (http://www.imagebam.com/image/ec623824903131)

can't really notice less red blocking between Convert() and ddcc() on these screenshots, only that red is more saturated w/ ddcc.

mark0077

28th January 2009, 16:14

So how will the new ffdshow rgb32hq that is being developed compare to the final version of this? I assume by definition they should be exactly the same but will they?

leeperry

28th January 2009, 16:20

So how will the new ffdshow rgb32hq that is being developed compare to the final version of this?
you'll have to pray for some good soul to add tritical's chroma upsampling algorithm in ffdshow :o

BTW, if you care to run compares w/ the nvidia drivers...you're most welcome :cool:

mark0077

28th January 2009, 16:27

I will do the compare in about 2 hours when I'm home from work ;) will be interested to see which is better. Pretty sure this conversion to rgb32 in software is a great idea because of the difference between nvidia and ati, not to mention the diff between conversion with nvidia and different renderers (sometimes bad conversion with evr-cp).

I'll post the new pics up soon with my test pattern.

EDIT: Got the code working, no avisynth errors, but ffdshow seems to still do a conversion which means I can't test this :( Any workarounds...? ffdshow musn't know that avisynth is outputting 32bit rgb?

Using ffdshow set to rgb32 output only, and full range and the following two sets of codes, but ffdshow is still doing some conversion

colorYUV(levels="tv->pc")
ConvertToYUY2()
rgb3dlut(lutfile="c:\3dlut_ycbcr_BT601_16-235.txt",itype=0)

and

colorYUV(levels="tv->pc")
ConvertToYUY2()
rgb3dlut(lutfile="c:\3dlut_ycbcr_BT601_0-255.txt",itype=0)

leeperry

28th January 2009, 23:42

colorYUV(levels="tv->pc")
ConvertToYUY2()
rgb3dlut(lutfile="c:\3dlut_ycbcr_BT601_16-235.txt",itype=0)

and

colorYUV(levels="tv->pc")
ConvertToYUY2()
rgb3dlut(lutfile="c:\3dlut_ycbcr_BT601_0-255.txt",itype=0)
you don't have to use colorYUV(), I do coz I got a longer script and I want GrainFactory3() to be processed on the full range video...

this SHOULD work :

ConvertToYUY2()
rgb3dlut(lutfile="c:\3dlut_ycbcr_BT601_0-255.txt",itype=1)

610 for SD, 709 for HD of course ;)

we spoke about it in PM, but if you only have RGB32 checked in ffdshow, ffdshow should bypass the Avisynth stream....I dunno what's up :confused:

instead of using Avisynth 2.5.8, you could try 2.5.7 + MT 0.7 on XP ? that's what I got....or as a last resort the alpha 2.60, which is already patched for MT.

try to set the RGB conversion of ffdshow to bogus levels, and see if it has any effect....this doesn't on my box :

http://www.image-load.eu/out.php/i142077_plop0.png

mark0077

29th January 2009, 00:48

Disabling ffdshows internal decoders fixed the problem, now avisynth seems to be doing the conversion...

Well I am kind of disappointed. Scaling upto 1920 x 1080 and tried

ffdshow rgb32hq and rgb32lut with the following settings

ConvertToYUY2()
rgb3dlut(lutfile="c:\3dlut_ycbcr_BT601_0-255.txt",itype=1)

Both show the ugly scaling problem again at the edge of the letters in my test. rgb32lut with itype=1 is 2kb larger file size than ffdshow's rgb32hq. The Nvidia yv12 -> rgb32 is absolutely perfectly smooth again as usual.

DISCOVERY ! :P
Now I have a feeling why I am seeing these ugly artifacts on this test, and I may be wrong but I think my hunch might be right in this case. When I view my test as part of the entire DVD, it is the first title and the image is scaled to the correct aspect ratio, BUT when its played alone, as a seperate vob file, this same image is displayed much narrower.

I am wondering if this image I am using to test is originally in the aspect ratio

x pixels : y pixels

and when played as part of the DVD it is signalled to be scaled to a non x:y aspect ratio (as I think it should by just looking at the width of the fonts) to

(x*z) : y

I think this is what is happening, and this horizontal stretching in certain configurations is what is causing these weird little jaggy lines (all but nvidias own conversions). What can be done software wise to counteract this. I am trying to find a combination of ffdshow resize, before and after avisynth to see what nvidia might be doing, or what order they do things in.

Any input on this would be great, because I think this may be important. Could it be that the resizers that we / I use are better in yv12/yuy2, than rgb32? This is my hunch so far anyways.

yesgrey

29th January 2009, 01:15

but ffdshow seems to still do a conversion which means I can't test this :( Any workarounds...? ffdshow musn't know that avisynth is outputting 32bit rgb?

Are you using any filter after the avisynth filter in ffdshow?
Some of the filters require YV12 input, so, even if you are outputing RGB32 from the avisynth filter, ffdshow will convert back to YV12 to feed the filter, then, it will convert to RGB32.

leeperry

29th January 2009, 11:15

Now I have a feeling why I am seeing these ugly artifacts on this test, and I may be wrong but I think my hunch might be right in this case. When I view my test as part of the entire DVD, it is the first title and the image is scaled to the correct aspect ratio, BUT when its played alone, as a seperate vob file, this same image is displayed much narrower.
it's splitter/player/renderer dependent I guess.

I gave up on your test pattern coz it's SD, and needs to be upscaled....kinda ruins the point of checking how the chroma looks.

anyway here it is, in spline36 upscale to 1280*768, and zoomed at 400% :

http://www.image-load.eu/out.php/t142192_01.png (http://www.image-load.eu/out.php/i142192_01.png)

leeperry

29th January 2009, 11:33

@tritical : Haruhiko has implemented a new chroma upsampling algorithm in ffdshow :
http://forum.doom9.org/showpost.php?p=1243154&postcount=6366

the results look really good :
http://forum.doom9.org/showpost.php?p=1243161&postcount=6368

your input would be much appreciated :thanks:

tritical

29th January 2009, 13:28

Nice that it is 20% faster, but I don't see how the extra bit depth during the yv12->yuy2->yv24 conversions, using linear interpolation, could make any noticeable difference. During yv12->yuy2 you do 75/25 and 25/75 averaging. The most error you could incur while rounding to 8-bit result is 0.5 (only possible results are: 1.0,0.75,0.5,0.25,0.0, rounding .5 to 1.0 gives the largest error). During yuy2->yv24 you keep all of the u/v values you calculated during yv12->yuy2, and do 50/50 averaging to get the other half. Now if you happened to introduce .5 error into both pixel values during yv12->yuy2 you could end up with a difference of at most 1.0 in the new u/v values calculated during yuy2->yv24. A difference of +-1 in u/v is not noticeable, and is certainly not the cause behind the differences in mark0077's image.

The explanation above is also why I'm not keen to add yv12 support to rgb3dlut... I don't think it would be at all noticeably different than if you called converttoyuy2(). Certainly it wont be faster. The only way it would be visibly different is if it used a different interpolation method during yv12->yuy2 conversion, and, if a more complex upsampling method is used, I think it would be better to have it as a separate filter (so that yuy2 frames are fed to rgb3dlut). However, I did add a cubic interpolation mode to rgb3dlut for yuy2->yv24 conversion, but before I release it I'd like to do a blind test. If anyone has samples that would really show the difference between chroma upsampling algorithms please post them :thanks:.

leeperry

29th January 2009, 13:50

A difference of +-1 in u/v is not noticeable, and is certainly not the cause behind the differences in mark0077's image.
it would appear that what you see in mark0077's compares is mostly due to bogus upscaling...so the results are to be taken with a grain of salt, as he has said himself here :
http://forum.doom9.org/showpost.php?p=1243013&postcount=156
If anyone has samples that would really show the difference between chroma upsampling algorithms please post them
it only showns on extreme test patterns, such as these red rolling end credits :
http://rapidshare.com/files/122925763/Bronz_s.mkv.html

if you zoom *a lot*, you can see that Haruhiko's new algorithm looks slightly better than ddcc :
http://forum.doom9.org/showpost.php?p=1243161&postcount=6368

but ddcc is already a major improvement over ConvertToRGB32() when zoomed....still it doesn't really show in real world practice :
http://forum.doom9.org/showpost.php?p=1242783&postcount=149

tritical

29th January 2009, 23:02

Well, on second thought I don't want to take the time for the test. Everyone can do their own tests and make up their own mind. ddcc v1.7 is on my site, changes:

+ added cubic interpolation option to rgb3dlut
+ added adobe 1998 chromaticity and linear gamma presets to ddcc
+ added yv12toyuy2 filter

yesgrey

29th January 2009, 23:35

tritical,
Once again...
:thanks:

leeperry

30th January 2009, 02:08

ddcc v1.7 is on my site, changes:

+ added cubic interpolation option to rgb3dlut
+ added adobe 1998 chromaticity and linear gamma presets to ddcc
+ added yv12toyuy2 filter

looking good, thanks!

so I ran a quick test on my o/c Q6600 :

yv12toyuy2(threads=4)
=750 fps

yv12toyuy2(itype=1,threads=4)
=1400 fps

ConvertToYUY2()
=1400 fps

is "itype 1" the same exact thing as what ConvertToYUY2() does?

and w/ rg3dlut() :

yv12toyuy2(itype=1,threads=4)
rgb3dlut(lutfile="Y:\BT709_0-255.txt",itype=1,threads=4)
=550 fps

yv12toyuy2(itype=1,threads=4)
rgb3dlut(lutfile="Y:\BT709_0-255.txt",itype=2,threads=4)
=480 fps

the speed drop is hardly noticeable, my full script(w/ LSF+Grainfactory3) falls from 62 to 61.5 fps...I'll be doing visual comparisons tomorrow :p

madshi

30th January 2009, 10:14

Dear gamut experts. Unfortunately I'm not an expert in this area at all. But I've one question:

The Lumagen Radiance video processor offers gamut correction which seems to be comparable to what tritical's solution does. But there seems to be a limitation of the Radiance, which is described here:

http://www.avsforum.com/avs-vb/showpost.php?p=15033893&postcount=3101
http://www.avsforum.com/avs-vb/showpost.php?p=15045760&postcount=3111
http://www.avsforum.com/avs-vb/showpost.php?p=15126353&postcount=3130

Does the tritical gamut solution have the same limitation? If so, could it be improved to beat the Radiance? :D

yesgrey

30th January 2009, 11:03

Does the tritical gamut solution have the same limitation? If so, could it be improved to beat the Radiance? :D
Yes, currently it does, and probably it will remain like that.
Since I am creating a little program to create the 3D LUT files all the future developments should be done in this program, that will create the 3D LUT files to use with rgb3dlut. These are our (tritical and I) plans.
The final goal would be to create a color correction application with complete customization of the output to fit all display irregularities that we can measure. Just to name a few: gamma correction without any predefined function (all data points you measure from your display), and for each color channel; chromatic adaptation to several white points (color temperatures), because a display cannot maintain the same white point from 0 to 100 IRE, and usually the higher on/off contrast is not at 6500k. Gammut correction at several levels, not only at one point as other solutions available, with better off-gammut colors handling. Etc...
With the 3D LUT, the main problem of adding all these corrections is solved: speed. It will always be the same speed, because it will be just mapping values. Now it will be just coding the algorythms for performing all the corrections we want.;)
Just a final note: this will be free. The program will be released under GNU GPL.

madshi

30th January 2009, 11:42

Yes, currently it does, and probably it will remain like that.
Since I am creating a little program to create the 3D LUT files all the future developments should be done in this program, that will create the 3D LUT files to use with rgb3dlut. These are our (tritical and I) plans.
The final goal would be to create the "ultimate" color correction application, a complete customization of the output to fit all display irregularities that we can measure. Just to name a few: gamma correction without any predefined function (all data points you measure from your display), and for each color channel; chromatic adaptation to several white points (color temperatures), because a display cannot maintain the same white point from 0 to 100 IRE, and usually the higher on/off contrast is not at 6500k. Gammut correction at several levels, not only at one point as other solutions available, with better off-gammut colors handling. Etc...
With the 3D LUT, the main problem of adding all these corrections is solved: speed. It will always be the same speed, because it will be just mapping values. Now it will be just coding the algorythms for performing all the corrections we want.;)
Just a final note: this will be free. The program will be released under GNU GPL.
Well, that sounds *really* good. I think the biggest problem may be on how to make all this potential functionality available in a way which is easy and intuitive to use? Ideally, I guess, your little program would contain a calibration "assistant" which would guide the consumer through a set of test screens (contained in and displayed by your program) and then ask for measurements of each of those test screens and then automatically do all necessary calculations based on those measurement results? If implemented in such a way, I guess even a calibration dummy (like me) would be able to get near to perfection, as long as good measurement hardware is used? Would that be "goodbye" to hiring ISF calibrators?

:)

yesgrey

30th January 2009, 12:10

Ideally, I guess, your little program would contain a calibration "assistant" which would guide the consumer through a set of test screens...
Well, I really haven't thought about it. Currently, my idea is just a simple console application (like eac3to;)) in which the user inputs a file with all the data, and the program outputs a 3D LUT file accordingly. Your idea is very good, and maybe it could end to something like that, but I don't know if I will have the time and the skills for all of that... Let's just see how the things progress... Currently there are already some free software for measuring and testing the displays (HCFR, for example), maybe we can find a way to use it for collecting the data needed for creating the 3D LUT...

Would that be "goodbye" to hiring ISF calibrators?
To someone with a HTPC, yes. Maybe it's better keeping my identity secret...:D

madshi

30th January 2009, 12:25

Well, I really haven't thought about it. Currently, my idea is just a simple console application (like eac3to;)) in which the user inputs a file with all the data, and the program outputs a 3D LUT file accordingly. Your idea is very good, and maybe it could end to something like that, but I don't know if I will have the time and the skills for all of that... Let's just see how the things progress... Currently there are already some free software for measuring and testing the displays (HCFR, for example), maybe we can find a way to use it for collecting the data needed for creating the 3D LUT...
I demand a perfect solution. NOW!!

Just joking. I was a little day dreaming, of course... :)

If you provided a command line tool which does all the dirty work which is necessary to realize all the fancy features you mentioned, then that would a very awesome first step.

But it would be great, if your tool just needed a specific set of measurements and would do all the necessary calculations itself. Finding a way to provide those measurements comfortably should be easy enough to add for other people then (e.g. the HCFR guys). I'm just hoping that your tool won't require users to be calibration experts. Well, because I'm not... :o

To someone with a HTPC, yes. Maybe it's better keeping my identity secret...:D
:D

yesgrey

30th January 2009, 13:28

I'm just hoping that your tool won't require users to be calibration experts. Well, because I'm not...
It won't.:)

madshi

30th January 2009, 13:36

It won't.:)
Great! You might be responsible for holding me in the HTPC camp then. Was already thinking about going external media player. Now I have to reconsider... :rolleyes:

leeperry

30th January 2009, 13:44

To someone with a HTPC, yes. Maybe it's better keeping my identity secret
not quite, we're still a far cry from real ISF calibration.
not because of their software tools(Color.HCFR has actually more features than ColorFacts, like the saturation measurements which ColorFacts doesn't do at all)....but the real difference is the sensor.

home users will have an Eye One Display 2 colorimeter from X-Rite at best, which is as accurate as the Eye One Pro in *most* cases :
http://www.avsforum.com/avs-vb/showthread.php?p=9495885#post9495885 (oops pix have gone AWOL...)

it's almost as accurate as the i1pro on DLP projectors, but on plasma or SXRD...it's a whole different story.

ISF ppl use Minolta spectrophotometers, that are recalibrated every 6 months(mastering houses get their CRT's recalibrated on a weekly basis w/ these professional tools).

http://www.konicaminolta.com/instruments/products/display/index.html

when an i1d2 gives a ΔE of 3, god knows if it wouldn't be 1 or 15 w/ a true Minolta spectrophotometer...it'd be like having a SP-A800B pj, and calibrate it w/ a spyder 2 :D

yesgrey

30th January 2009, 14:01

You might be responsible for holding me in the HTPC camp then.
It's funny, because you, with eac3to, are also responsible for holding a lot of people in the HTPC camp...;)

leeperry

30th January 2009, 15:13

so here I am w/ comparisons :)

1)
colorYUV(levels="tv->pc")
yv12toyuy2(itype=1,threads=4)
rgb3dlut(lutfile="Y:\BT709_16-235.txt",itype=2,threads=4)

2)
colorYUV(levels="tv->pc")
yv12toyuy2(itype=2,threads=4)
rgb3dlut(lutfile="Y:\BT709_16-235.txt",itype=2,threads=4)

3)
colorYUV(levels="tv->pc")
convertToYUY2()
rgb3dlut(lutfile="Y:\BT709_16-235.txt",itype=2,threads=4)

4)
colorYUV(levels="tv->pc")
convertToYUY2()
rgb3dlut(lutfile="Y:\BT709_16-235.txt",itype=1,threads=4)

5)
colorYUV(levels="tv->pc")
+ ffdshow RGB32 709 full range

6)
colorYUV(levels="tv->pc")
+ ffdshow RGB32HQ 709 full range

7)
colorYUV(levels="tv->pc")
+ ffdshow RGB32HQ 709 full range / new test build from Haruhiko

http://www.image-load.eu/out.php/t142371_1.png (http://www.image-load.eu/out.php/i142371_1.png)http://www.image-load.eu/out.php/t142372_2.png (http://www.image-load.eu/out.php/i142372_2.png)http://www.image-load.eu/out.php/t142373_3.png (http://www.image-load.eu/out.php/i142373_3.png)
http://www.image-load.eu/out.php/t142374_4.png (http://www.image-load.eu/out.php/i142374_4.png)http://www.image-load.eu/out.php/t142375_5.png (http://www.image-load.eu/out.php/i142375_5.png)http://www.image-load.eu/out.php/t142376_6.png (http://www.image-load.eu/out.php/i142376_6.png)
http://www.image-load.eu/out.php/t142377_7.png (http://www.image-load.eu/out.php/i142377_7.png)

first comparison :

http://www.image-load.eu/out.php/t142378_orig.png (http://www.image-load.eu/out.php/i142378_orig.png)

zoomed at 400% :

http://www.image-load.eu/out.php/t142379_origx4.png (http://www.image-load.eu/out.php/i142379_origx4.png)

second comparison :

http://www.image-load.eu/out.php/t142381_2orig.png (http://www.image-load.eu/out.php/i142381_2orig.png)

zoomed at 400% :

http://www.image-load.eu/out.php/t142382_2origx4.png (http://www.image-load.eu/out.php/i142382_2origx4.png)

after careful examination, it seems to me that the sharpest and best looking results are w/ Haruhiko's new algorithm...any chance adding it in rgb3dlut please ? plus it works in 10 bits or so, so going yv12>rgb32 in more than 8 bits would avoid sloppy roundings and increase the LUT accuracy. Haruhiko talked about it here :
http://forum.doom9.org/showpost.php?p=1243635&postcount=6402
this is really über-nitpicking, though...feel free to throw rocks at me if you like http://forum-images.hardware.fr/images/perso/antp.gif

yesgrey

30th January 2009, 17:24

leeperry, how have you peerformed your tests? Are you using any sharpenning? My tests show differences, but not so big as yours... I think the comparison must be done at the most raw level...

Here are my test results...
ffdshow new algorythm:
9365
yv12toyuy2 and rgb3dlut with itype=2, b=0, c=0.5
9365

Comparing both images, the ffdshow new algorythm has a slightly less sharp image, but the colors are more even (Look at the capital J's).
There is also a strange thing... if you compare both images switching from one to another (I open both with Paint, and then switch using Alt+Tab), you can notice a little horizontal shift between them.
Maybe the slightly loss of precision due to the yv12->yv24 being performed in two steps with yv12toyuy2+rgb3dlut would be the responsible for that?

leeperry

30th January 2009, 17:46

nope, no sharpening.

remoulade(divx7) decoding > colorYUV() in HR/full range 32bits and that's it.

you can't trust VMR/EVR as they do postprocessing, HR does not.

I can't see your screenshots, maybe you could put them on imagebam?

anyway, we both agree that using Haruhiko's new code and doing the LUT thingie in 10 bits w/o any in-between 8 bits conversion could potentially yield more pleasing results...let's wait to know what tritical thinks about all this, and whether this would be technically achievable http://forum.slysoft.com/images/smilies/agreed.gif

leeperry

1st February 2009, 10:55

the funny thing is that if you save the 7 original screenshots to your PC, then quickly pass through them w/ the windows picture viewer....they all smear a bit, except the seventh.

in RGB32HQ stock, the background is R3/G1/B1 like all the other screenshots...but w/ the new experimental yv12 algorithm it's R2/G0/B0

this time I haven't messed up w/ the LUT's, and I used the exact same settings between stock ffdshow and the new Haruhiko's version...I only updated ffdshow :o

FoLLgoTT

1st February 2009, 11:25

in RGB32HQ stock, the background is R3/G1/B1 like all the other screenshots...but w/ the new experimental yv12 algorithm it's R2/G0/B0

The overall saturation is too high. Is this a basic problem of this algorithm or just a matter of implementation?

tritical

2nd February 2009, 06:42

There is also a strange thing... if you compare both images switching from one to another (I open both with Paint, and then switch using Alt+Tab), you can notice a little horizontal shift between them.
Maybe the slightly loss of precision due to the yv12->yv24 being performed in two steps with yv12toyuy2+rgb3dlut would be the responsible for that?
It's because the new ffdshow algorithm assumes centered chroma placement in yuy2, and not left aligned (which is the mpeg2 standard, and what rgb3dlut uses). As I explained before, the extra bits in the conversion during the 4:2:0 -> 4:4:4 interpolation steps will be absolutely unnoticable (there are bigger differences between yv12toyuy2(itype=1) and converttoyuy2(), try to spot those :)). Now a change in assumed chroma position is a different matter. I have added chroma placement options to rgb3dlut/yv12toyuy2, which allow the user to select between all possible scenarios. In yuy2 there are only 2, centered or left aligned. In yv12 there are a few more, depending on interlaced vs non-interlaced and non-standard ways the conversion could be performed... which has been discussed in the past.

Jeremy Duncan

2nd February 2009, 07:01

It's because the new ffdshow algorithm assumes centered chroma placement in yuy2, and not left aligned (which is the mpeg2 standard, and what rgb3dlut uses). As I explained before, the extra bits in the conversion during the 4:2:0 -> 4:4:4 interpolation steps will be absolutely unnoticable (there are bigger differences between yv12toyuy2(itype=1) and converttoyuy2(), try to spot those :)). Now a change in assumed chroma position is a different matter. I have added chroma placement options to rgb3dlut/yv12toyuy2, which allow the user to select between all possible scenarios. In yuy2 there are only 2, centered or left aligned. In yv12 there are a few more, depending on interlaced vs non-interlaced and non-standard ways the conversion could be performed... which has been discussed in the past.

- "left aligned (chroma) is the mpeg2 standard"
- "ffdshow uses centered aligned (chroma)"
- "you can spot a change in the assumed chroma"

My question to you, Tritical.
- Mpeg2 assumes left, and I use yv12.
- ffdshow output changes yv12 to rgb32 with (16-235 levels).
- Will the picture be degraded? because the yv12 being changed into rgb 32 is treated like it's centered chroma when in fact it's left chroma?

tritical

2nd February 2009, 07:18

My question to you, Tritical.
- Mpeg2 assumes left, and I use yv12.
- ffdshow output changes yv12 to rgb32 with (16-235 levels).
- Will the picture be degraded? because the yv12 being changed into rgb 32 is treated like it's centered chroma when in fact it's left chroma?

The thing is, just because the standard specifies left aligned 4:2:2 doesn't mean all encoders do that. Heck, avisynth's rgb->yuy2 conversion averages every two pixels... resulting in centered chroma (yet its yuy2->rgb conversion assumes left aligned, and averages to create the right pixel value, which will result in visible shifting if you chain enough conversions together). Xvid's old color conversion routines (circa 2003-2004, I have no idea if they are the same now) operated based on centered chroma. I assume there are commercial encoders that operate that way... so in these cases assuming centered chroma in the yuy2->rgb conversion will look better. That said... if you are watching video, and not zooming in on still frames, you probably wouldn't be able to notice the difference.

Also, when I mentioned yuy2 vs yv12 and number of positioning scenarios... for yuy2 I was talking only about horizontal positioning (what matters in the yuy2<->rgb conversion) and in yv12 I was talking only about vertical positioning (what matters in the yuy2<->yv12 conversions). Generally, progressive yuy2->yv12 vertical positioning is consistent. It's the interlaced yuy2->yv12 conversion that is more likely to result in non-standard chroma placement (for example: separating fields and then doing a progressive yv12->yuy2 conversion on each field results in non-standard placement). The nice thing about mpeg2 standard 4:2:0 interlaced vertical chroma positioning, is that if the content is actually progressive, but is downsampled using interlaced conversion, then you can use normal progressive upsampling on it because the two positionings are actually the same (the difference is how the values are created). If the positioning is non-standard though, then the progressive conversion's assumptions wont match up correctly.

madshi

2nd February 2009, 09:09

It's because the new ffdshow algorithm assumes centered chroma placement in yuy2, and not left aligned (which is the mpeg2 standard, and what rgb3dlut uses).
Do you happen to know what the h264 and VC-1 specifications say about chroma placement?

tritical

2nd February 2009, 10:56

h.261,h.263,mpeg1 -> centered
mpeg2,mpeg4,h.264 -> left

Don't know about vc-1 for sure, but I would guess left.

madshi

2nd February 2009, 11:07

Pretty interesting - thanks!

leeperry

2nd February 2009, 11:30

I have added chroma placement options to rgb3dlut/yv12toyuy2
in ddcc 1.7? you mean itype? which one is left and which one is centered please?
there are bigger differences between yv12toyuy2(itype=1) and converttoyuy2(), try to spot those :)
haha, couldn't tell :D
I'm using yv12toyuy2(itype=1)/rgb3dlut(itype=2) and it looks good to me.
h.261,h.263,mpeg1 -> centered
mpeg2,mpeg4,h.264 -> left

Don't know about vc-1 for sure, but I would guess left.
ok, I'll try to make automatic profiles in ffdshow then :p
if you are watching video, and not zooming in on still frames, you probably wouldn't be able to notice the difference.
indeed, this is major nitpicking :devil:
anyway what I *can* see is that yesgrey3's REC601/709 matrixes are more accurate than ffdshow.
so we finally have very accurate decoding and conversion, this is too awesome :thanks:

leeperry

3rd February 2009, 03:33

I've got some h264/DTS MKV samples that make yv12toyuy2() crash ffdshow instantly(using HMS/divx7 decoder/sonic audio 4.2), whatever in type 1 or 2...itype 0 works fine, and so does ConvertToYUY2() :confused:

here's one of them :
http://www.megaupload.com/?d=4A4TRTNB

btw, look at the native gamut of the Epson TW5000 :
http://www.homecinema-fr.com/BE/TW5000/usine-cie.jpg

it's got a full CMS, BenQ/Epson are now offering it in their projectors...got to be a good sign ;)

tritical

4th February 2009, 21:58

in ddcc 1.7? you mean itype? which one is left and which one is centered please?

It's in 1.8, haven't released it yet. Still need to test it a little more, and need to check out your crashing report.

yesgrey

5th February 2009, 20:53

leeperry

5th February 2009, 21:22

thanks yesgrey! I was busy doing stuff today, but now that I've RTFM several times I'll look into it tomorrow http://forum-images.hardware.fr/images/perso/d4buff.gif

Mug Funky

6th February 2009, 02:35

heywow!

3d luts in avisynth, 1 step closer to being quite practical :)

i'm just R'ingTFM now.

just thinking, probably the best balance of performance versus complexity might be in the way programs like lustre, scratch, resolve etc do it - a 16x16x16 LUT (in a text file) with processing and interpolation between these "cube points" happening on the GPU. i'm pretty confident most modern GPU's can handle it, and the advantage is you can go ape with the precision and it all happens at the output stage.

right now i'm just trying to figure out how to port the Arri DCI LUT for log-to-print emulation, so i can preview film scans in avisynth as they'd appear in a cinema.

[edit]

would it be advantageous to make the 3d lut file format such that it looks meaningful when loaded raw into an image editor? that way you could create a series of adjustments in gimp or photoshop or whatever, use them on a "flat" lut file, then save the result as a raw image that can be used as a lut in avisynth. does that make sense? this way i could drop the flat file into scratch, apply the arri lut, then render to a new pic that i can use.

canuckerfan

6th February 2009, 04:29

i feel a little lost in all this but would using yv12toyuy2() be advantageous in any way over avisynth's native converttoyuy2()?

tritical

6th February 2009, 05:31

@All
Put up ddcc v1.8 on my website... only change was adding 'cplace' parameter to yv12toyuy2 and rgb3dlut for specifying chroma placement.

@leeperry
The crash happened because I coded most of yv12toyuy2 for mod 4 height, but didn't put in the necessary error checking. Since itype=0 with progressive upsampling was the only combination that worked with mod 2 height, I decided to require all input be mod 4.

just thinking, probably the best balance of performance versus complexity might be in the way programs like lustre, scratch, resolve etc do it - a 16x16x16 LUT (in a text file) with processing and interpolation between these "cube points" happening on the GPU. i'm pretty confident most modern GPU's can handle it, and the advantage is you can go ape with the precision and it all happens at the output stage.
Well, I have no plans to port it to the gpu, but someone else might. In terms of programming for the cpu, 16x16x16 lut with interpolation would be more complicated. If the interpolation was something simple it might be faster, but the current method (with full 48MB table) is pretty quick on most recent computers. Working with 8-bit in -> 8-bit out you certainly can't get better precision than with the full table (precision of the mapping is limited by the program computing the table). Personally, I think it would be easier to write a separate program that converts other lut formats into the format rgb3dlut currently uses, and since that would be offline you could make it as complex as you want (interpolation methods, etc...). Plus, that way rgb3dlut is never the limiting the factor, in terms of interpolation methods offered for smaller luts, etc...

would it be advantageous to make the 3d lut file format such that it looks meaningful when loaded raw into an image editor? that way you could create a series of adjustments in gimp or photoshop or whatever, use them on a "flat" lut file, then save the result as a raw image that can be used as a lut in avisynth. does that make sense? this way i could drop the flat file into scratch, apply the arri lut, then render to a new pic that i can use.
What format are you thinking? Again, I think it would be easier just to have a separate program that converts from one format to another and leave rgb3dlut as it is.

i feel a little lost in all this but would using yv12toyuy2() be advantageous in any way over avisynth's native converttoyuy2()?
That question is like asking if bicubicresize() would be advantageous over bilinearresize(). Compared to converttoyuy2(), yv12toyuy2() simply offers more choices for interpolation function, and more choices for chroma placement. Are those differences large? Not really, people aren't that sensitive to chroma. As a test, I created an image in paint, and converted it to yv12 using converttoyv12(matrix="Rec709",interlaced=false). Then I converted it back to rgb using a number of methods: cpic-center.png (http://bengal.missouri.edu/~kes25c/cpic-center.png). For the images that are named "xxx,yyy", 'xxx' specifies the interpolation method for yv12->yuy2, and 'yyy' specifies the interpolation method for yuy2->yv24 (dup=duplicate,lin=linear,cub=cubic). Those images were converted using yv12toyuy2/rgb3dlut. Since avisynth's rgb->yuy2 conversion averages every two pixels, I used centered chroma placement in rgb3dlut. Here is the result using left aligned chroma placement for the yv12toyuy2/rgb3dlut images: cpic-left.png (http://bengal.missouri.edu/~kes25c/cpic-left.png). Are there differences among the conversions? Yep. Are they that big between linear and cubic? Not really.

cyberbeing

6th February 2009, 06:29

I'm finding ddcc 1.8 nearly 30-50% slower then ddcc 1.7 which makes it unusable for me. This is a major problem considering that the 30-50% slower causes me to be unable to view some 720p video in real-time on my AMD X2 computer with yv12toyuy2, rgb3dlut, and reclock. If just adding the chroma placement option is the only thing changed/fixed and is the entire cause of this slowdown, I'll just continue using 1.7.

Below are the options I use:

yv12toyuy2(itype=2, interlaced=false, threads=2, b=0.33, c=0.33)
rgb3dlut(itype=2, lutfile="C:\Program Files\AviSynth 2.5\bt709lut.txt", threads=2, b=0.33, c=0.33)

Edit: Oh and thank you yesgrey3 for the cr3dlut app, initial impressions is it seems to work as designed.

canuckerfan

6th February 2009, 08:02

thanks for the explanation, tritical. the visuals helped:)

leeperry

6th February 2009, 08:30

@leeperry
The crash happened because I coded most of yv12toyuy2 for mod 4 height, but didn't put in the necessary error checking. Since itype=0 with progressive upsampling was the only combination that worked with mod 2 height, I decided to require all input be mod 4.
any chance you could make it fall back to itype=0 if it's not mod4? but well I'm not sure I could even see a diff between the itypes :o

anyway, I'll look into the new version! :thanks:

tritical

6th February 2009, 09:25

@cyberbeing
Is this faster: [removed]?

madshi

6th February 2009, 10:22

Finally it's ready the first version of cr3dlut, a program for creating a 3D LUT file to use with tritical's rgb3dlut. This first version is partially based in tritical's ddcc code, so the results should be very similar.
You can get both the program and source code at my web page. Here is the link:
http://yesgrey3.totalh.com/

It's not (yet) very user friendly, but I will also improve the user-friendliness at the same time I will improve the program. For that, it will be very important your comments and suggestions.;)
Thanks!

Some comments:

(1) There are some "*/" in the readme which probably aren't supposed to be there?
(2) The readme is very technical. I didn't understand half of it... :) Would it make sense to split the readme into two separate files: One for technical gurus, where all the funny details are explained. And one for every user where there are more explanations and less technical terms? I can't help much with double checking the technical stuff. But I could easily tell you which parts are difficult to understand for a noob like me. Some of the current text of the readme is only useful for programmers, but not for users, e.g. "The table is created such that the offset into the table" is not useful for users, but might be useful for programmers, I think. Such information could also be moved to a separate file.
(3) For some parameters you're listing a number of ITU/SMTP/whatever specs. That's ok, but it doesn't help a noob like me at all. I'd need an explanation what these specs are actually usually used for. E.g. for "Source_primaries" both options 1 and 3 contain the word "NTSC", so if I wanted to use the default source primaries for DVD NTSC discs, I wouldn't know whether to use 1 or 3. Also the word "ATSC" doesn't appear, anywhere, so I wouldn't know which source primaries to use for ATSC, either. I think for each of these options the first line should explain what they are usually used for, and then maybe the ITU/SMPTE spec listings under that. Personally, I couldn't care less about ITU/SMPTE. If you ask me, I'd move the ITU/SMTPE numbers to the "technical readme" and remove them from the normal readme. I think for each option which requires different values depending on the source type, each of the following source types should be contained somewhere in one of the options: Blu-Ray/HD DVD, NTSC DVD, PAL DVD, NTSC SD broadcasts, ATSC HD broadcasts, PAL SD broadcasts, PAL HD broadcasts. So that we noob users know exactly which option is the right one to use.
(4) What does "GBR" stand for? I'd simply remove that and only write "RGB Input, no YCbCr->RGB conversion" there instead.
(5) I'd rename "YCbCr_Full_range" to "YCbCr_Input_Full_range" to make it clear that this is for *input*. It's clear enough if you think about it (after all output of 3dlut is always RGB, so YCbCr can only be the input and not the output), but adding "input" to the parameter name means you don't even need to use intelligent logic to find out that input is meant and not output.
(6) "RGB_BW" should be renamed to "RGB_Output_BW".
(7) Would it make sense to add an "RGB_Input_BW" option?
(8) "Chromatic_adaptation" definitely needs an explanation. I've no idea what this is good for and which value it should be set to under which circumstances.
(9) What should "Display_primaries" be set to for people who don't have this information about their display?
(10) Is there a direct correlation between different source types (e.g. PAL DVD, NTSC DVD, Blu-Ray, ...) and "Source_gamma"?
(11) What should "Display_gamma" be set to for people who don't have this information about their display?
(12) An explanation would be helpful about whether YCbCr and RGB data are usually linear or gamma corrected. E.g. are compressed sources usually gamma corrected (probably yes)? And if you transport YCbCr via HDMI, is that also gamma corrected or linear? And if you transport RGB via HDMI, is that also gamma corrected or linear? How about if you use HDMI 1.3 DeepColor. Is that still gamma corrected or linear?
(13) I'd like to have an option to output 16bit RGB instead of 8bit... ;)

(Of course my questions are not meant to be answered by you here in the forum. The intent of my questions is that they should be answered by the readme.)

cyberbeing

6th February 2009, 10:29

It seems like I underestimated before how slow the initial version of 1.8 was. Instead of 10-20% it was actually nearer to 30-50% slower then 1.7 when I retested and actually calculated the percentage instead of guessed. The new version you posted is much better but still slower then 1.7 by about 5-15%.

CPU graphs from left to right, |ddcc 1.7|original ddcc 1.8|new ddcc 1.8|
http://img17.imageshack.us/img17/6731/17st7.png http://img10.imageshack.us/img10/6216/old18iu9.png http://img15.imageshack.us/img15/9736/new18ew8.png

yesgrey

6th February 2009, 12:54

But I could easily tell you which parts are difficult to understand for a noob like me.
madshi,
Thank you very much for your excellent post! I need feedback like this, because it's the only way of improving things.
You should consider the actual readme as the technical readme.;)
I did not want to delay much more the release of the program, so I only put the more technical stuff. For helping the newbies, I've created 3 typical input files, for Blu-ray, dvd-pal and dvd-ntsc, but I know the instructions must be a lot more detailed and simpler.
As you know very well, only when people start using our software we can see what's good, what's bad, what's useful, what's useless...

(5) I'd rename "YCbCr_Full_range" to "YCbCr_Input_Full_range"
(6) "RGB_BW" should be renamed to "RGB_Output_BW".

I'm not so sure about this. I was thinking that maybe could be a good idea of allowing the 3D LUT to work both ways:
YCbCr->RGB or RGB->YCbCr.
tritical, what do you think about it? Some people are reporting slightly better results when performing YCbCr->RGB with the 3D LUT, maybe the RGB->YCbCr could also be more accurate with the 3D LUT?
I think that would be a good idea starting a new thread about rgb3dlut. Now, there is a new option available for the Avisynth usage (using 3D LUTs), and the current thread name is not very meaningfull about it; some potential users could be missing it...
If you agree with using the 3dlut in both ways, we have two optios:
-rename rgb3dlut to a more generic name
-keep rgb3dlut as it is and create ycbcr3dlut or yuv3dlut (i prefer the former because is the correct designation), etc. As you wish.