Don’t worry about the specific domain of XYZ in this case, consider how to invert the encoding. I covered the basics of the AllocationTransform here.
Important note: The forward encoding and the inversion must match 1:1 precisely, otherwise all calculations will be wrong. It is important to test the encoding through decoding process.
Correct. Remember, the encoding is a compression scheme to assert maximal density coming into the processing algorithms. The processing algorithms can output exactly what they want, which is why the output can be considered “complete” at that point, if required.
The important part is to appreciate why the shaper side is required. If we have a domain of 0.0 to 1.0 but the importance is non-uniform, such as “middle” being 0.18, we can see a discrepancy. If our “important range 50%” goes from 0% of the encoding to 18%. That’s 18% that we are “stretching” to 50% importance. That means that in terms of a 3D LUT, which we can consider from 0% to 100%, we’d be leaning heavily into the sampling of the 0% to 18% range of the 3D LUT, and wasting many of the LUT values from 18% to 100%!
As before, OpenColorIO has some brain wormed design that simply doesn’t work. Don’t try to overfit things that are working algorithmically into the design of OpenColorIO. Just because it might seem “tidy”, doesn’t mean it works. Make it work, and hack around the clunky OpenColorIO brain wormed nonsense parts. That likely means jettisoning looks, but you’ll have to arrive at that on your own. I’ve tried to make their architecture work. It can’t. It’s brain wormed.
Yes. Remember in OpenColorIO, the log2 is a pure log2. That means that any scaling for “middle grey” needs to be calculated prior as per the link I included and that is referenced above.
Nice work folks. Keep hammering!