Also keep in mind that some tools* may not work entirely correctly yet because I haven't written code for separately detecting the input depth and output depth (I'll add that by 0.7), so right now if the output range changes then the entire range changes.
I'll write code sooner or later to pulldown the input range and output range independently of each-other and detect both ranges correctly.
*This should probably just affect changedepth -r and imagecal -3
Quote:
Alright, sounds like a plan! Whenever I'll find the courage to install a W7SP1 VM, I'll get back to you. 
|
Is it that hard to install .NET 4.0 on XP? If it's a huge problem I may be able to find some way around it, but the way I'm generating lambda functions on the fly* right now requires 4.0.
* Since .3dLUTs can be so different (bytes, ushorts, floats, PC levels, TV levels, color encoding etc) I generate the correct function for an operation during runtime - or at least, I used to, I could probably reduce these lambdas to static delegates now that I'm just about finished outlying all logic to the unified 64-bit floating point pipeline.
What I'll probably doing by version 0.7 or 0.8 is abstracting all transformation operations behind an ITransformationProvider interface and compositing these objects together on the fly and packaging them into a TransformationFactory. That way you will be able to serialize a bunch of different composite operations into a loadable file and pass them around, or store them inside a .3dlut's meta-tags, allowing for rapid prototyping, modification and large-scale distribution of environment-tailored 3dLUTs through a common interface.
Then I could probably create a drag and drop UI front-end for it that allows you to visualize composite transformations and preview them on the fly.
But for now, the delegates shall suffice.
