[nand chan]

Originally Posted by leeperry

Well, atm I use an 8bit VGA connection w/ a 10bit CLUT...so all is well, but soon or later I'll be upgrading to a 40" LCD from SONY/LG(I want at least 4K:1 native CR) so it'll be about a 8bit CLUT on top of a 8bit 3DLUT AFAIK...so ideally I would like Argyll's calibration to be embedded within the 3DLUT.

Right, this is currently well-possible.

To avoid all those YCbCr>RGB>YCbCr lossy conversions, ideally I would like to input a 16bit RGB gamut mapping LUT from cr3dlut, merge it w/ a .cal file and output a BT.601/709 8bit YUY2 LUT to use w/ rgb3dlut() in ffdshow.

Except for the YUY2 part this is possible already: Create a 16-bit gamut mapping LUT from BT.601 to BT.709 using cr3dlut, merge it with a .cal file using applycal, then change the bit-depth down to 8-bits with changedepth.

Then you'd just have to use that 8-bit RGB lut in ffdshow. It won't be YUY2 though, the problem here would be that .cal doesn't work in YUY2 space - it works in RGB space, so you can't just “apply” a .cal to a YUY2 lut without converting all of the values back and forth. (These won't necessarily be lossy because conversions are performed with 64-bit precision)

But this would very much require a "reset CLUT while playing" option in mVR, otherwise it'll end up useless....and maybe the flat screen I'll be buying will have serious 10/12bit calibration options so I won't have to use a .cal kludge anymore

What you can do is set up a .bat script to run dispclut -d 1 --save file.txt --reset, run MPC-HC, then run dispclut -d 1 --load file.txt once it closes. That way, whenever you start MPC-HC, the LUTs should automatically be reset.

So as I said earlier, it's all sheer brainstorming at this point from my side...still, I know some ppl already requested the ability to merge gamut mapping and .cal files together in order to avoid having the CLUT messing around w/ mVR's dithering, but I dunno how much of a PQ difference it would make. And at the end of day, adding three 1D CLUT's on top of a 3DLUT is nothing more than a kludge at the price of a dispensable quality loss.

Mapping three 1D CLUTs onto a 16-bit 3DLUT using my methods should *always* be higher quality than loading them to the video card, because my calculations properly interpolate the 1d CLUTs to 16-bit space (they are normally 8 bit -> 16 bit on the display device and my program calculates them as 16 bit -> 16 bit). So that gives madVR 16 bits of information to work with after calibration, and it can dither this down properly.

It's certainly an advantage, but you are right, the PQ difference in real world scenarios is debatable.

Here's a 0-255 8bit YUY2 LUT from my CRT gamut to SMPTE-C: BT709_SMPTE-C.rar

I'll have a look, thanks

Edit: Alright, seems like cr3dlut ignores the Color Encoding field as well and just scans through the parameters file to figure out which value type to use.

You can take that YCbCr -> RGB .3dlut as-is and just apply a .cal onto it, should already be fully supported* because the .cal process only modifies the output value and not the input value. It's still a good reference file though, so I know what to scan for to detect ranges etc.

* Since my scripts only work with yCMS parameters at the moment, you'll have to tag your .3dluts as full range using tag3dlut --full -i BT709_SMPTE-C.3dlut, otherwise it will assume limited range and mess up the colors.

But after doing that, applycal -i BT709_SMPTE-C.3dlut your_cal_file.cal should work fine.