#### Re: ExpressionTransformation for OCIO?

Jeremy Selan <jeremy...@...>

On Fri, Aug 30, 2013 at 9:11 AM, Mark Boorer wrote:
Hi Ben,

* I'm surprised your lin-log transform cannot be nicely applied as a 1D LUT.  Even with a large 2**16 or 2**32 line LUT? Would a different interpolation help (e.g cubic)?

My example where a 1D lut would be insufficient is where the source image is already in float linear, and a grading operation is to be applied in log (like saturation). Here negative values are acceptable, and we would expect them to be preserved when converted back to lin. When using a 1D lut, negative values (and positive values greater than 1) would be clamped off.

You may be interested in experimenting with the .spi1d lut format, it's actually rather general.

The spi1d format is unique in allowing LDR on an input axis, and HDR on the output axis. So if you wanted to have a log to linear lut, which supports HDR linear, but also maps negative values into a reasonable range in log space such a lut could be formulated.  And it supports both inverse / forward operations at full fidelity, so as long as both of your axes are not HDR it works great.

Mocking up a small demonstration of your use case...

The input domain for the LUT below is log space.  But rather than defining only the range of 0-1, I've extended it to -0.25,1.25 to allow for 'negative' log values as you mentioned.  So for the samples you see, they represent uniform steps in log space from of [-0.25, 0.0, 0.25, 0.5, 1.0, 1.25] The output domain is scene-linear.

> mylogtolin.spi1d

Version 1
From -0.25 1.25
Length 7
Components 1
{
-0.05
0.0
0.05
0.18
1.5
13.0
55.0
}

You will be able to use such a LUT, at full fidelity, in programs such as nuke in either the forward (log->lin) or inverse (lin->log) directions.  Obviously a real lut would have much higher number of samples.

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