Version 0.1.1 is out now that I have gained yesgrey's acceptance of the yCMS download method
Quote:
Originally Posted by leeperry
TBH I use 0-255 LUT's using an old version of cr3dlut, but I'm quite sure yCMS could create them as well...the only problem would be mVR that might expect 16-235 LUT's indeed, but if you want automatic gamut mapping depending on the frame rate/resolution, the only solution atm is to use rgb3dlut(8bit) or t3dlut(16bit) within ffdshow automatic profiles.
|
True, but I dislike the usage of ffdshow because it does not yet have a native 10-bit pipeline, also that would require working with YUV LUTs instead of RGB luts unless you want to use ffdshow's piss poor RGB conversion. I'll still consider adding 3dLUT combining as a future feature but it's not high on the priority list because there are too many variables to be careful of when combining them, and it's not easily doable with madVR LUTs. (unless madVR allows working with 0-255 LUTs in the future)
It's fairly straightforward to /create/ the correct LUTs using yCMS, it's just that madVR will reject the .3dlut.
Quote:
|
Several ppl already requested the feature of embedding together within the same 3DLUT both the Argyll calibration and the gamut mapping, so mVR's dithering wouldn't be messed around by the graphic card's CLUT...this would require an option in mVR to disable the latter, though.
|
This would indeed be very important since iirc the CLUTs are only one-dimensional. The main problem would be generating a proper 16-235 .3dlut from .cal data, which probably lies within the domain of a tool such as yCMS. I do not (yet) have the necessarily technical knowledge to interpolate and generate tables like that.
My first priority now though is getting a working, automatized front-end for Argyll and yCMS in place to bridge the process from profiling to .3dlut creation.