Date 1 - 2 of 2
ExpressionTransformation for OCIO?
Mark Boorer <mark...@...>
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.
The GPU code path for this expression-transform would be difficult. Not sure how big a deal this is, as I have little experience with such things, but: Compiling the expression to shader code sounds doable but difficult. Baking the expressions to a LUT for the GPU seems might be more practical (using the AllocationOps to define the range the expression applies over)
I imagined either providing a single expression for 1D transforms, or 3 expressions for 3D, but I like the idea of the expression engine pre-setting the variables "x" or "r,g,b" when toggled via a bool.
I had a quick search for the current GPU shader code, but only found a process that generates a 3D lut as a texture, then does a simple lookup to generate output frag colors. Is there a mode complex model that accurately follows the CPU computation? Because that was another point I was hoping to raise :D
Could you let me know where to look for the current GPU implementations? Obviously duplicating the effort of expression compilation on the GPU would be insane, but I don't have any other immediate ideas. Personally I'm happy with just a CPU based solution.
On Friday, August 30, 2013 4:25:51 PM UTC+1, dbr/Ben wrote:
Jeremy Selan <jeremy...@...>
On Fri, Aug 30, 2013 at 9:11 AM, Mark Boorer <mark...@...> wrote:
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.
From -0.25 1.25
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.
|1 - 2 of 2|