View Single Post
Old 25th August 2011, 02:02   #68  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by nand chan View Post
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.
The whole point of going YUY2 is that the YCbCr>RGB32 conversion through a LUT hardly requires any CPU power, and it can be MT'ed. It also allows the use of yv12toyuy2() which has a lot of nifty features(like choosing the chroma interpolating algorithm). Using RGB LUT's in ffdshow is far from ideal, and same goes for 16bit LUT's because t3dlut() is required and it's far more CPU hungry than rgb3dlut(). They also double the loading time over 8bit, even off a ramdisk.

Quote:
What you can do is set up a .bat script to run dispcal -d 1 --save file.txt --reset, run MPC-HC, then run dispcal -d 1 --load file.txt once it closes. That way, whenever you start MPC-HC, the LUTs should automatically be reset.
I'm really looking for a kludge-free HTPC at this point, I've got all my gamut mapping settings within automatic ffdshow profiles, that's how cool it's gotten

Hopefuly, madshi is reading this: an option to bypass the graphic card's CLUT when mVR is playing would be amazing

Quote:
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. [..] applycal -i BT709_SMPTE-C.3dlut your_cal_file.cal should work fine.
Alright, sounds like a plan! Whenever I'll find the courage to install a W7SP1 VM, I'll get back to you.

Last edited by leeperry; 25th August 2011 at 02:05.
leeperry is offline   Reply With Quote