gamut conversions through Avisynth ?

[leeperry]

@yesgrey3: w00t, same colors as ddcc/ogg0 would be a god bless http://forum-images.hardware.fr/images/perso/otakonleboss.gif

@73ChargerFan: they keep increasing the gamuts, but the movies are still SMPTE-C....and usually they don't offer any option to shrink it(or poorly, like on the latest JVC pj) :rolleyes:
well, Epson starts to offer options to switch gamuts on their consumer projectors, but you have to dig into menus and submenus to reach it...only the Samsung shown in the OP has direct access buttons on its remote control.

[leeperry]

oh my, oh my....it's working :D

http://thumbnails19.imagebam.com/3777/3a81a937766600.gif (http://www.imagebam.com/image/3a81a937766600) http://thumbnails6.imagebam.com/3777/dca22037766601.gif (http://www.imagebam.com/image/dca22037766601) http://thumbnails16.imagebam.com/3777/ae452a37766602.gif (http://www.imagebam.com/image/ae452a37766602)

1)
colorYUV(levels="tv->pc")
ConvertToRGB32(matrix="pc.709")

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

3)
colorYUV(levels="tv->pc")
ConvertToYUY2()
rgb3dlut(lutfile="X:\HC3100_SMPTE-C.txt",threads=4,itype=2,b=1.0,c=0.0)

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

# 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 3
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

I will try BT.601 later on, and also the different other options...but I've never been able to see any difference between ddcc and the PS script, to me they go different ways to achieve the same result :o

way to go yesgrey, thanks a bunch! http://forum-images.hardware.fr/images/perso/ginie.gif

[Neeto]

@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:

Do you have to do the import from Color.HCFR?
Perhaps a new "10" Custom type with the first row being the same as format as "9" and muliple following rows with each row being the parameters for a particular pecentage saturation?
I guess this means messing with the calcuations to produce the 3dlut quite a lot ;-)

:thanks: for all the work!

[Neeto]

I've been playing around with rgb3dlut and thougth I had it working just fine (silly me!)
Take a look at the following two images which are a crowd seen from an Elton John One Night Only NTSC DVD played using MPC-HC (v1.2.1160) with EVR, fddshow (revsion 3014), using libmpeg2 codec to a ATI 4650 card
The first is with AviSynth off & thus no rgb3dlut & the second is with AViSynth on & thus rgb3dlut doing its magic.

http://thumbnails10.imagebam.com/4251/d0d52c42503305.gif (http://www.imagebam.com/image/d0d52c42503305)

http://thumbnails10.imagebam.com/4251/5a07c542503306.gif (http://www.imagebam.com/image/5a07c542503306)

It is clear that something is badly wrong with the second image - all sorts of "squares" have appeared.
It is most noticable on sceens where it is low light with mainly single colors.

All I've done to gernerate these images is start MPC-HT with AviSynth on in ffdshow, then pause "Print Screen", save image, turn AviSynth off, and step a few frames foward "Print Screen", save image.

AviSynth Script:

Last=ffdshow_source()
isYV12() ? yv12toyuy2(2,true) : last
rgb3dlut("C:\Program Files\AviSynth 2.5\plugins\rgb3dlut_NTSC.raw")

I've tried:
1. outputing the image as NV12 (i.e. NV21,VU)
2. changing codec form libmpeg2 to libavcodec
3. changing to EVR Custom
4 change yv12toyuy2 interplotation method to 0, 1 & 2

Any other ideas?

Neeto

[Neeto]

This look like it the chroma upsampling bug people talk about with the ATI cards - can someone confirm?
By changing the to RGB on the ffdshow Output tab, rather than NV12 I was able to get to get back to a good picture, just with crappy de-interlacing.
But this does not make sense with the about "AviSynth/rgb3dlut" on & off giving better with AviSynth/rgb3dlut ON giving worse images - going to recheck everything.
I really want this to work with hardware de-interlacing as the advanced modes of de-interlacing are not supported in RGB on the ATI cards.

[yesgrey]

rgb3dlut_NTSC.raw
What settings have you used to create this file?

[leeperry]

This look like it the chroma upsampling bug people talk about with the ATI cards - can someone confirm?
[..]
I really want this to work with hardware de-interlacing as the advanced modes of de-interlacing are not supported in RGB on the ATI cards.
well, simple...the ATi will do ugly chroma upsampling if you don't send them RGB...or you'll have to use Leak's chroma blurring script in MPC, but it'll be compatible w/ VMR9/EVR only(the script also works in KMP).

[Neeto]

What settings have you used to create this file?

Input file to cr3dlut

#
# Settings for creating a 3D LUT for watching the following Video formats:
# NTSC DVD, NTSC SD Broadcast
# without any Display correction
# Includes YCbCr->RGB conversion preserving Video Levels

# Set input bitdepth
Input_Bit_Depth 8

# Set source video format
Input_Video_Format NTSC YCbCr

# Set output bitdepth
Output_Bit_Depth 8

# Set display video format
Output_Video_Format NTSC RGB_PC

[Neeto]

well, simple...the ATi will do ugly chroma upsampling if you don't send them RGB...or you'll have to use Leak's chroma blurring script in MPC, but it'll be compatible w/ VMR9/EVR only(the script also works in KMP).

This is the script from this post?
http://forum.doom9.org/showthread.php?p=1184975#post1184975

I was hoping to avoid using that script, but it seems wiser folk have trodden this path before me and concluded this is the best we can do.
:thanks:

[Neeto]

Point taken about the "lossy" - everything is a compromise at the moment as I've not been able to find a software delinterlacer that is as good as ATI hardware de-interlacer.
The half-resolution chorma of the YV12 is definitely lossy

DVD is in YCrCb which MPEG2 decoder output as RGB or YV12 (correct?) & rgb3dlut want it in YUY2, so need the yv12toyuy2, so the video is going to go:
DVD source> (Splitter):MPEG2-YCrCb > (MPEG2 decoder):YV12 > (yv12toyuy2):YUY2 > (rgb3dlut):RGB32 > (ffdshow output convert):NV12 > (ATI drivers, deinterlacing, scaling)

I'm really not sure how "lossy" this will be compared with something like (is this correct?):

DVD source> (Splitter):MPEG2-YCrCb > (MPEG2 decoder):YV12/RGB32/YUY2 > (ffdshow deinterlace):RGB32/YUY2 > (ffdshow scaling):RGB32/YUY2 > (rgb3dlut):RGB32 > ATI drivers

All I know so far is I don't like the output of the deinterlace (software).

I did some more testing to confirm my original findings.

Additional info:

MPEG2 codec must be libmpeg2 as the libmpeg2 codec seems to be the only one that supports it output being rendered set to the renderer in NV12 & RGB output, the libavcodec only seems to support it being sent in RGB.

Definitenly re-confirmed When playing MPC-HT :
1. With Avisynth/rgb3dlut "OFF" and NV12 output, image is "good" (as per first image posted above) and de-interlacing good
2. With Avisynth/rgb3dlut "ON" and NV12, image is "ugly" (as per second image posted above), and de-interlacing good
3. With Avisynth/rgb3dlut "OFF" and RGB output, image is "good" (as per first image posted above) and de-interlacing bad
4. With Avisynth/rgb3dlut "ON" and RGB output, image is "good" (as per first image posted above) and de-interlacing bad

From this I conclude that Avisynth/rgb3dlut is doing something to confuse the renderer/ATI hardware acceleration implementation, because the first test "proves(?)" that NV12 input can be handled correctly by the ATI drivers.

Perhaps it is somehow "triggering" the upscaling problem - perhaps levels? out of range colors?
Another thought is that if rgb3dlut is actually producing frames in RGB (someone confirm please or is it coming out of rgb3dlut in YUY2 - I'm starting to doubt the most basic of assumptions) then ffdshow will need to convert RGB to NV12 & perhaps this is where the problem is.
Are there any avisynth filters to convert back to NV12? - I've not been able to find any.

Thoughts?

[yesgrey]

Thoughts?
Yes, don't use rgb3dlut, you don't need it.:)

You should use rgb3dlut in one of two scenarios:
a)you want to perform some kind of video adaptation to your display.
b)you want to perform YV12->RGB32 with more accuracy.

Looking at the file you used to create the 3dlut file, you are not changing anything in your video to adapt it to your display. So you're not in a).

You're also not in b), because after using rgb3dlut you use ffdshow to convert back from RGB32->NV12 to use the ATI hardware deinterlacing.

So, keep it simple, do not use rgb3dlut and feed directly the deinterlacer with the dvd output, you will get the best quality.;)

[Neeto]

Ahhhh - forgot to say that I haven't yet got my caliabration for my new Samsung LED LCD - so can't put int he custom levels/colour space yet.
I'm doing all this testing in anticipation.

What about the idea of having rgb3dlut output YUY2?

[yesgrey]

What about the idea of having rgb3dlut output YUY2?
Have you heard about t3dlut?;)
Look a few posts back. tritical created t3dlut that supersedes rgb3dlut and can use all combinations output by cr3dlut, even YUY2->YUY2.

[Neeto]

Thanks for the pointer yesgrey3.

I've played around with tritical's t3dlut function.
I can get the RGB output to work, with the same image problems described in earlier post - no surprises there.

When I change the output color space on t3dlut to YUY2, the colors are all messed up.
I get a "Pink" FBI Warning on a "Green" background as per this image on the opening of an NTSC DVD.

http://thumbnails15.imagebam.com/4268/7ddf4242671846.gif (http://www.imagebam.com/image/7ddf4242671846)

It's like all the Blue in RGB went missing.

This is the avisynth script:
isYV12() ? yv12toyuy2(interlaced=true) : last
t3dlut("C:\Program Files\AviSynth 2.5\plugins\t3dlut_NTSC_Video.3dlut", destcs=0)

I've tried:
1. changing output color space in ffdshow Output tab to "RGB32", "NV12" & "YV12" - no difference
2. adding a yuy2toyv12 to the script & changing output color space in ffdshow Output tab to "RGB32", "NV12" & "YV12" - no difference

Do I need to generate the 3dlut file different?
I don't think so cause the cr3dlut documentation says we have all the conversions needed:

" In reality, our 3D LUT file contains three 3D LUTs, one 3D LUT for each component:
- R'G'B' -> R'G'B':
R'out = 3D LUT(R'in,G'in,B'in)
G'out = 3D LUT(R'in,G'in,B'in)
B'out = 3D LUT(R'in,G'in,B'in)
- R'G'B' -> Y'CbCr:
Y'out = 3D LUT(R'in,G'in,B'in)
Cbout = 3D LUT(R'in,G'in,B'in)
Crout = 3D LUT(R'in,G'in,B'in)
- Y'CbCr -> R'G'B':
R'out = 3D LUT(Y'in,Cbin,Crin)
G'out = 3D LUT(Y'in,Cbin,Crin)
B'out = 3D LUT(Y'in,Cbin,Crin)
- Y'CbCr -> Y'CbCr:
Y'out = 3D LUT(Y'in,Cbin,Crin)
Cbout = 3D LUT(Y'in,Cbin,Crin)
Crout = 3D LUT(Y'in,Cbin,Crin)"

Thanks, Neeto

[yesgrey]

Do I need to generate the 3dlut file different?
Yes.
I don't think so cause the cr3dlut documentation says we have all the conversions needed
No. The documentation shows all the possible conversions.
For YUY2->YUY2 you should use:
Output_Video_Format NTSC YCbCr

[Neeto]

:thanks::thanks::thanks:

Yep it's all working now.

I can confirm that by using the following script:

isYV12() ? yv12toyuy2(interlaced=true) : last
t3dlut("t3dlut_NTSC__YCbCr_Video.3dlut",destcs=0)

and having ONLY NV12 checked on the Output tab of ffdshow you can indeed get hardware acceleration for the deinterlacer AND color space adjustment/conversion.

Note: Don't be tempted to add a yuy2toyv12(interlaced=true) for some reason this reintroducates the "squares" - see previous posts.

Again thanks for all the help!

Now if I can just workout why EVR Custom Pres rendere will not obey aspect information - and why jitter has gone to hell in a handbasket - all would be good - SIGH.....

[yesgrey]

Great.:)

you can indeed get hardware acceleration for the deinterlacer AND color space adjustment/conversion.
Good finding, I will give it a try, maybe it's a good solution for the interlaced stuff...;)

[Neeto]

Things where going along swimmingly until decided to upgrade to latest ATI 9.8 drivers.
This is because 9.8 driver fixes the "double expansion" problem when using H/W acceleration.

Now having AviSyth in ffdshow with this script

isYV12() ? yv12toyuy2(interlaced=true) : last
t3dlut("t3dlut_PAL_DVD_YCbCr_Video.3dlut",destcs=0)

and having ONLY NV12 checked on the Output tab of ffdshow will "clip" i.e. convert anything < 16 to 16 & anything >235 to 235. All other levels appear to be fine.
If I disable AviSyth in ffdshow no more clipping - i.e. 0 to 254 displayed just fine.

It would seem the problem might be one of the following:

a. A bug in ffdshow?
I'm using ffdshow version 3014 & Avisynth version 2.5.8
Perhaps AviSynth doesn't talk to the NV12 interface correctly.
How might I check this?

b. A bug in t3dlut.dll - I hope not.

c. The way it's meant to be & I've mis-understood all this time.

d. Badly configured 3dlut input file. Unlikely as I've not changed it - but can someone check I'm not doing something silliy in the file I use to generate the 3dlut file.

e. Something else??? Ideas??

Thanks, Neeto

# Settings for creating a 3D LUT for watching the following Video formats:
# PAL DVD
# without any Display correction
# Excludes YCbCr->RGB conversion preserving Video Levels (Black: 16 and White: 235)

Chromatic_Adaptation 2

Out_Of_Gamut_Clipping 1

Input_Bit_Depth 8

Input_Video_Format PAL_DVD YCbCr

Input_YCbCr_Matrix 3

Input_YCbCr_Full_Range 0

Input_RGB_Black_White 16 235

Input_Primaries 2

Input_Gamma 1

Output_Bit_Depth 8

Output_Video_Format PAL_DVD YCbCr

Output_YCbCr_Matrix 3

Output_YCbCr_Full_Range 0

Output_RGB_Black_White 16 235

Output_Primaries 0

Output_Gamma 1

[yesgrey]

Try changing the following lines:
Input_YCbCr_Full_Range 1

Input_RGB_Black_White 0 255

Output_YCbCr_Full_Range 1

Output_RGB_Black_White 0 255


And be sure to use the latest version, v2.2.
Post your results.;)

[Neeto]

Yet again the experts are in victory! :)
All working, but now I'm curious why. Can you explain?
It makes me wonder what else I need to change in the config files for "non-hardware" accelerated HD/NTSC/PAL sources.

Thanks, Neeto

[yesgrey]

All working, but now I'm curious why. Can you explain?

I've made some changes in the latest versions of cr3dlut and now when Input_YCbCr_Full_Range is set to 0 it only converts the YCbCr values from 16-235, clipping the <16 and >235, as it should.
I still have to made some changes in cr3dlut about these conversions, because it's not yet exactly how I want, but I have to think in it more carefully...

[leeperry]

I still have to make some changes in cr3dlut about these conversions, because it's not yet exactly how I want, but I have to think about it more carefully...
yeah! I'm bored, everything works fine :scared:

I demand new features to beta-test http://img513.imageshack.us/img513/6779/icecream.gif

[yesgrey]

yeah! I'm bored, everything works fine :scared:
That's the bad thing of a perfect world...;)

Unfortunatelly, not everything is working fine.:(
Yesterday, I was trying to work a little in cr3dlut and I don't know what happenned, because now it's not compiling... The last time I opened the project it compiled fine, now, don't. I think I will have to uninstall and re-install VS2008 and ICL11.:mad:

[Neeto]

If you're messing with parameters then may I suggest keeping some consistency with those in ffdshow video RGB Conversion tab.
Up until the last set of changes, I thought they where consistent, but now I'm confused.

I started thinking how I would configure the 3dlut config file if I needed to display on a monitor i.e blacks really at 0 & whites really at 255 with HA acceleration.
I can't see a way at the moment.

Perhaps this is a missing parameter that indicates whether to clip or not clip below 16 and above 235 on the output, because sometimes you really do want black 16 & white at 235 and sometimes you want the black at 0 and white at 255 and when you have black at 16 and white at 235 sometimes you want <16 & > 235 info included and sometimes you don't.
In the 3dlut config parameters I can't see a way of indicating whether you want <16 & > 235 info to be included or not.

[yesgrey]

may I suggest keeping some consistency with those in ffdshow video RGB Conversion tab.
Don't worry. In case you don't know, I've participated actively in the discussion of the new ffdshow tab, and some of its ideas were suggested by me.;)

In the 3dlut config parameters I can't see a way of indicating whether you want <16 & > 235 info to be included or not.
I think cr3dlut has everything that you need.
In first place, you need to distinguish between input/output levels and YCbCr/RGB levels.
Generally, the input is YCbCr and the output is RGB, hence the possibility of confusion between the terms, but as you are using it, YCbCr can be both input and output.
The parameter that sets the YCbCr black and white levels is the XXX_YCbCr_Full_Range. If set to 1, it considers the video black at 0 and video white at 255; if set to 0, it considers the video black at 16 and video white at 235, hence clipping all <16 and >235 values. If you want to use YCbCr and all <16 and >235 values, you should set the parameter always to 1.

What I am missing, is the option to customize the levels for values different than the standard 0/16 and 235/255, like ffdshow does, because despite the XXX_RGB_Black_White parameter allowing that kind of customization, since the XXX_YCbCr_Full_Range performs clipping when set to 0, this is useless, because even if I set the RGB white to 245, I will not see the >235 values of the source, because they are clipped. My current idea is doing it similar to ffdshow, and substituting the XXX_YCbCr_Full_Range with a XXX_YCbCr_Black_White with the possibility of custom values, but I still need to think a little more about it.
I want the parameters setting to be clear, logic and simple, and that's not the case yet...

[Neeto]

That seems to make sense.
if I undestand correctly, what we need is Input AND Output config parameters for BOTH RGB and YCbCr with custom black/white levels for both RGB & YCbCr on both input and output.
If I understand correctly, we're missing the setting of custom levels on output of YCbCr.


The parameter that sets the YCbCr black and white levels is the XXX_YCbCr_Full_Range. If set to 1, it considers the video black at 0 and video white at 255; if set to 0, it considers the video black at 16 and video white at 235, hence clipping all <16 and >235 values. If you want to use YCbCr and all <16 and >235 values, you should set the parameter always to 1.


I'm not sure what's happening on the input YCbCr with regard to Input_RGB_Black_White parameters. Is it like the "Custom" in the "Input levels" on the ffdshow RGB conversion tab where you can choose the black level & white level? or is it simply ignored by cr3dlut when using Input_YCbCr_Full_Range set to 1?
I guess it's the use of "RGB" in the parameter name when we're dealing with YCbCr input info that is confusing me (or perhaps it is the screwy ATI drivers and how they deal with YCbCr input levels when taking NV12 and doing hardware acceleration - it seems to want YCbCr in Full Range Y:0-255 CbCr: 1-255 where as I would have expected it want it in Standard range Y:16-235, CbCr:16:240)

I've confirmed that by using setting:

Input_YCbCr_Full_Range 1
Input_RGB_Black_White 16 235
Output_YCbCr_Full_Range 1
Output_RGB_Black_White 16 235

On initial veiwing I get the same results when using HA as using:

Input_YCbCr_Full_Range 1
Input_RGB_Black_White 0 255
Output_YCbCr_Full_Range 1
Output_RGB_Black_White 0 255

i.e. no clipping. The first set of parameters seem more logical to me.

[yesgrey]

You are confusing the YCbCr and RGB Input/Output parameters, which shows that you have not read the readme carefully... but this confusion of yours is good, because it showed me one thing that is not very clear.
What defines the Input and output formats is the xxx_YCbCr_Matrix parameter. If set to 0 the format is RGB, if set to other values is YCbCr, and uses the specified matrix.
If you read the readme carefully, you will see that the xxx_RGB_Black_White parameter setting is ignored when the corresponding xxx_YCbCr_Matrix parameter is not set to 0, and that the xxx__YCbCr_Full_Range parameter setting is ignored when the corresponding xxx_YCbCr_Matrix parameter is set to 0. So, when you specify both parameters for Input and Output, only one is considered, depending of your YCbCr_Matrix setting.;)
Yes, I know, this is a bit confusing, but when this started the idea was only YCbCr->RGB, so it was natural to put the YCbCr and RGB words in the parameters names. With the current state of cr3dlut, it seems a better idea to substitute xxx_YCbCr_Full_Range and xxx_RGB_Black_White by a single parameter, like xxx_Black_White_Levels. The only problem I see is that this could be less intuitive for some people, because the YCbCr and RGB words are missing... but I feel that I am nearer to what I feel is right.:)

[Neeto]

Thanks for the clarification - as usual I was confused - situation normal ;-)

[canuckerfan]

any chance the yv12toyuy2() function can support matrix strings like converttoyuy2() does so that we can keep the full range of 0-255?

and in its current state does yv12toyuy2(), by default, clamp the range to 16-235?

[yesgrey]

any chance the yv12toyuy2() function can support matrix strings like converttoyuy2()
That does not make any sense.
converttoyuy2 needs the matrix strings because it can be used to perform the conversion from RGB -> YUY2. When it's used to perform the conversion from YV12->YUY2 the matrix string is not used.
yv12toyuy2 only performs the conversion from YV12->YUY2, hence no need for the matrix string.
Since there is no RGB->YUY2 conversions invloved, the levels are untouched. If it enters 16-235 it outputs 16-235, if it enters 0-255 it outputs 0-255.

[darkbasic]

Hi!
I have a wide gamut display (similar to AdobeRGB) and I'dd like to have color correct video playback.
Can someone explain me how to achieve it?
Thank you!

[leeperry]

do you have a colorimeter?

[darkbasic]

do you have a colorimeter?
Yes, I have a spectrophotometer (Colormunki Photo).

[leeperry]

ok, cool..but it's not supported by Color.HCFR, is it? but maybe you're using Calman or another similar app?

anyway, do you know the RGBW coordinates of your display gamut? you also need to decide whether you wanna use madVR or t3dlut/rgb3dlut in the Avisynth filter of ffdshow...you can also use MPC HC's PS script in MPC(only for VMR9/EVR)

[yesgrey]

Hi!
I have a wide gamut display (similar to AdobeRGB)
Yes, I have a spectrophotometer (Colormunki Photo).
The better option would be to measure your primaries coordinates and use them when creating a 3DLUT for your display. The other option, easier, would be select option 4 for the output primaries (set them as Adobe RGB) when creating your 3DLUT using cr3dlut.

[darkbasic]

ok, cool..but it's not supported by Color.HCFR, is it?
I don't know, but I have also an Eye-One Display 2. I already have a monitor profile (both matrix+shaper and LUT) and I know my RGB coordinates (I usually use Spectraview II for hardware calibration and argyll 1.1 beta for profiling). I use gamma 2.2 and D65 white point.

you also need to decide whether you wanna use madVR or t3dlut/rgb3dlut in the Avisynth filter of ffdshow...you can also use MPC HC's PS script in MPC(only for VMR9/EVR)
Well, what's the difference? Which one should I use? How to use them?
I don't know much about video encoding standards and video color management, I know only about photography...

Thank you,
Darkbasic

[leeperry]

yes, the i1d2 in Color.HCFR might be an easier solution to measure coordinates.

well, it depends on many things actually...all the video renderers have their advantages:
-madVR supports YV12 input, is very smooth and makes highly accurate color conversions, but it's still in beta stage, needs a beefy GPU, is not very stable yet and doesn't support subs or DXVA(you can use CoreAVC CUDA, though)
-EVR and VMR9 support exclusive mode(for smooth playback if your system is not optimized), and they also support DXVA...the gamut conversion PS script hardly needs any GPU power, and no CPU power at all. you can use PS scripts in MPC/MPC HC and KMPlayer
-if you want to use Haali's Renderer(which is quite buggy), you have to use t3dlut/rgb3dlut in RGB32..which is a CPU hog. I don't recommend it at this point, madVR is a better choice now.

I'd say if you watch your movies in 60Hz, EVR w/ the PS script in MPC or KMPlayer might be the easiest solution(a few clicks and you're good to go!): Color Correction with a HTPC - Simpler solution and now it really works! - AVS Forum (http://www.avsforum.com/avs-vb/showthread.php?t=912720)

if you watch movies with Reclock in a 24Hz multiple to get butter smooth playback, don't need DVD support and don't mind fiddling around, madVR would be better.

[pbmtp]

Hi yesgrey3,

I emailed you (@gmail) some HCFR files about differences between cr3dlut & t3dlut and pixel shader script, did you had any time to have a look at it ?

[yesgrey]

Hi yesgrey3,

I emailed you (@gmail) some HCFR files about differences between cr3dlut & t3dlut and pixel shader script, did you had any time to have a look at it ?

I will try to take a look at them as soon as possible. I have to instal hcfr to be able to see the files...;)

[pbmtp]

Thanks a lot

[darkbasic]

I already tried the Shader Editor solution, but I'm not fully satisfied with it. I want to achieve the best quality possible and if I can have a smooth playback I don't care about CPU/GPU usage (you were talking about Reclock in a 24Hz multiple, can you tell me more about it?). madVR seems to be very nice...
I have an AMD Athlon64 3800+X2@2700 MHz, 2GB ram (fsb synchronous) and an Ati Radeon 3870HD and I use Windows 7 x64 and Media Player Classic HC x64 (with K-Lite Codec Pack x64).
I think I can also use CHROMiX ColorThink Pro 3 or Argyll's iccdump utility and a chromatic adaptation calculator (bradford) to find the RGBW coordinates. Do you need them referred to D50 or D65?

[leeperry]

I already tried the Shader Editor solution, but I'm not fully satisfied with it. I want to achieve the best quality possible and if I can have a smooth playback I don't care about CPU/GPU usage (you were talking about Reclock in a 24Hz multiple, can you tell me more about it?). madVR seems to be very nice...
I have an AMD Athlon64 3800+X2@2700 MHz, 2GB ram (fsb synchronous) and an Ati Radeon 3870HD and I use Windows 7 x64 and Media Player Classic HC x64 (with K-Lite Codec Pack x64).
I think I can also use CHROMiX ColorThink Pro 3 or Argyll's iccdump utility and a chromatic adaptation calculator (bradford) to find the RGBW coordinates. Do you need them referred to D50 or D65?
the PS script is as accurate as can get...if that doesn't satisfy you, you either need to make the right conversion(SMPTE-C for US/ASIAN movies, EBU for european/russian) and/or make sure your RGBW coordinates are OK.

theoritically, madVR/cr3dlut in 16bit/ddcc would yield better results on extreme test patterns...but the PS script does the job, it's actually my personal reference as it looks so damn nice on my DLP pj and it's been double-proofed on several occasions by either ppl on AVS or myself on my own setup :cool:

you can extrapolate zillion values, but the source movies are only 16-235 SMPTE-C/EBU to begin with..when xvYCC and so will show up it'll be a different story, though.

look at this doctored JVC RS1 w/ the PS script : http://www.avsforum.com/avs-vb/showpost.php?p=11937064&postcount=90

and that's Kazuya's PLV-Z4 in SMPTE-C w/ cr3dlut in madVR: http://img301.imageshack.us/img301/1904/clip54.th.png (http://img301.imageshack.us/i/clip54.png/)

D65 is required AFAIK, and you'd be better off using ColorHCFR w/ your i1d2 to measure coordinates.

oh well, Reclock carries a pretty steep learning curve...you can start here: http://forum.slysoft.com/forumdisplay.php?f=85

[yesgrey]

the PS script is as accurate as can get...
No. Using madVR with a 3DLUT file is more accurate than the PS script.

oh well, Reclock carries a pretty steep learning curve...you can start here: http://forum.slysoft.com/forumdisplay.php?f=85
Also, you're using mpc-hc x64, and reclock only is available in 32bit version. You need to use mpc-hc 32bit.

[leeperry]

No. Using madVR with a 3DLUT file is more accurate than the PS script.
well, show me some real world movies where they make a clear difference ;)

Seb.26 told me that the HLSL PS scripts work in double-precision 64bit float, the source movies are still 16-235 SMPTE-C...you can't squeeze a lemon forever :o

when fiddling w/ cr3dlut, my goal has always been to reach the same colors as the PS script...which has been double-proofed on many occasions, and looks amazing anyway.

when we'll have xvYCC, then yes...cr3dlut+madVR will most likely kill the PS script.

anyway, the PS script w/ EVR is an easy way to get gamut conversion(you even get a nice menu for different conversion presets in MPC or KMP), if you wanna fiddle a lot more you can go cr3dlut+madVR..that's only what I was saying, no offense.

[yesgrey]

Thanks a lot
I think it's better if we discuss the problem here.
Start by telling me how have you measured the primaries in all three cases. Only the results is not enough.

well, show me some real world movies where they make a clear difference ;)
The PS use an aproximate transfer function to remove the gamma, while cr3dlut uses the exact transfer function inverse of each format, and it uses 64bitFP per component, while PS uses at max 32bitFP.
The fact that you cannot see the difference doesn't mean that it's as accurate as can get.;)

Seb.26 told me that the HLSL PS scripts work in double-precision 64bit float
No they don't. Pixel Shaders currently only support 32bit float per component (what madshi is using in madVR), and I don't know if mpc-hc PS is also working with that level of precision.

when fiddling w/ cr3dlut, my goal has always been to reach the same colors as the PS script...which has been double-proofed on many occasions, and looks amazing anyway.
That would make the colors more nice looking, which is not the same as more accurate.;)

anyway, the PS script w/ EVR is an easy way to get gamut conversion(you even get a nice menu for different conversion presets in MPC or KMP).
Yes, I agree, currently the PS solution is more user friendly. I believe madshi will take care of it.

that's only what I was saying, no offense.
I am not offended.:)

[leeperry]

The fact that you cannot see the difference doesn't mean that it's as accurate as can get.
[..]
That would make the colors more nice looking, which is not the same as more accurate.
as you know, I'm colorblind anyway :D

if the gamut conversion is spot-on in ColorHCFR and if my brain is stunned by the natural colors(as it's always been the case w/ the PS script), I'm cool!

getting spot-on SMPTE-C seems to increase the CR, maybe because colors are not mixed or oversaturated anymore...anyway it's like Reclock, try a butter smooth movie w/ perfect colorimetry and you'll never look back :devil:

professional grade equipment works w/ a 2.5 gamma(including the Samsung projectors from Joe Kane), but I think my HC3100 was built to work at 2.22..like every consumer display.

[pbmtp]

Hi yesgrey,

I used the following patterns in ts files which are adaptation of AVSHD for being use with a video player. Here is the link http://kvcd.net/downloads/MIRES_1080P_POUR_MPCHC_V3.rar The ones I used were 100 % Color (folder ColorHCFR Fields\100% Color).

For first measure, video were played using MPC-HC EVR configured in 0-255 without D3D, decoded with CoreAVC in YV12 16-235, conversion to RGB32 0-255 was done using ffdshow (High quality YV12 to RGB32 conversion), ColorHCFR probe was configured in 0-255 plugged on a second computer. This measurement gave me the exact same results as when using ColorHCFR pattern generator.

The next measure was done using the exact same configuration but with the pixel shader corresponding to the primaries of my Z3000 applied in MPC-HC, in that case CIE diagram was close to spot on with BT.709 reference.

Final measure was done using same config for CoreAVC, MPC-HC without any shader, and the provided avisynth script with t3dlut using the LUT generated by cr3dlut with the config file i gave you by email. ffdshow was configured in RGB32 0-255 output. I also tried with a more simple cr3dlut input file recommended in the manual for HD BT.709 with just the added output primaries but got the same results.

Also all 3 measures were done in a row without turning off the video projector.

Hope you have all you need, i can also mail you my ffdshow profile if needed.

Thanks

[yesgrey]

Hope you have all you need, i can also mail you my ffdshow profile if needed.
Yes, please send it.

[pbmtp]

done by email

[Kazuya]

and that's Kazuya's PLV-Z4 in SMPTE-C w/ cr3dlut in madVR: http://img301.imageshack.us/img301/1904/clip54.th.png (http://img301.imageshack.us/i/clip54.png/)

D65 is required AFAIK, and you'd be better off using ColorHCFR w/ your i1d2 to measure coordinates.

oh well, Reclock carries a pretty steep learning curve...you can start here: http://forum.slysoft.com/forumdisplay.php?f=85

Of course, it works perfect, and D65 is not required for that !
Color temperature only affects secondaries colors and their position on the gamut.

Thanks Yesgrey !!! :thanks: