1. Messages
  2. reversable, but not 1D color transforms in config.ocio

Re: reversable, but not 1D color transforms in config.ocio

Troy Sobotka <troy.s...@...>
 



On Fri, Feb 3, 2017 at 11:52 AM Andrew Wood <andre...@...> wrote:
Looking at my values closer, looks like you are probably right.  My input image is 0 to 1 linear, so I wasn't using a shaper.  However, when I get to LAB space, there are negative values, which would explain why its all messed up going back to rgb right afterwards.

But what shaper would even make sense here?  My head hurts trying to think about the a*b* components going through a log curve or something. That doesn't really make sense, does it?

The shaper here would be a purely technological solution, simply helping out interpolation given that your input happens to be imagery. In your CTL, you would assume that you are being fed Log2 values and undo it, then run the L*a*b* according to the proper canonical formula. Even a simple Log2 shaper would probably be more than acceptable I'd speculate, although Mr. Cooper's suggestion might be more on point perhaps given that L* is already nonlinear and uniform, albeit more complex to implement in the CTL.

To fix the negative nature of the a*b* formation, I'd encode them with a uniform offset of 0.5 in much the same way 8 bit cheats encode L*a*b*.

This would spit out a Log2 encoded L*a*b* series of values. Undo the Log2 on the tail end and you end up with pure L*a*b* with a*b* offset. If you really wanted to get fancy, you could run it through a MatrixTransform with an identity, and leverage the offset to reset the a*b* to proper negatives. Perhaps even an ExponentTransform or LogTransform etc. could be used to cheat that as well. Sean?

With respect,
TJS 
Join {ocio-dev@lists.aswf.io to automatically receive all group messages.