Date
1 - 4 of 4
ExpressionTransformation for OCIO?
|
Mark Boorer <mark...@...>
Howdy, Any further feedback on this? Cheers, Mark |
|
|
|
Mark Boorer <mark...@...>
Hi, I've finished my proof of concept, and it seems to be working quite nicely. I ended up needing to provide 3 strings for 3d transformations (which isn't too terrible) and I was able to implement GLSL shader support too (I don't know enough Cg script, but it should be trivial to add in). Here's a link to the pull request: https://github.com/imageworks/OpenColorIO/pull/329 Would be great to hear any feedback :) Thanks, Mark |
|
|
|
dbr/Ben <dbr....@...>
There was discussion of a CTLTransform (Color Transform Language) in the past, although it would probably require OCIO to have a plugin interface for transforms, because having the OCIO core depend on CTL which depends on IlmBase is.. not ideal.. exprtk seems interesting, and looks "small enough" to be included in the core, as done with md5/pystring (Jeremy could say more authoritatively). The SeExpr project also seems suitable. Would definitely be interesting to see a prototype of the transform.. Some other random thoughts: * 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)? * 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) Baking the expression to a LUT defeats the purpose you mention, but it would be useful in other cases (e.g we have a several colourspaces which are defined by simple expressions, but we currently have to bake these out as LUTs - would be much tidier as an expression-transform) * OCIO's Transforms have a "hasChannelCrosstalk" method - since deterring this from an arbitrary expression might be impractical, so I guess when defining the transform you would have to specify if it's a 1D transform (e.g !<ExprTransform> {expr: "v**2"}) or 3D expression (e.g !<ExprTransform> {expr: "r+g+b/3", is3d:true}) On 31/08/2013, at 12:05 AM, Mark Boorer wrote:
|
|
|
|
Mark Boorer <mark...@...>
Hi, I'm currently looking at moving our existing color pipeline tools over to OCIO, and I'm wondering if anyone can see a place for such a feature. In our current setup, some of our log to lin conversions cannot be adequately expressed via a 1D lut, and for grading operations the changes caused by interpolation are too great. I'm proposing to write an Expression Transformation, which would allow us to express these transformation operations via a string, and evaluate them using exprtk or a similar library. Has anything like this been proposed before? Does anyone have any thoughts? I'm hoping to knock up a proof of concept over the next few weeks. Cheers, Mark |
|
|