toggle quoted messageShow quoted text
thanks for the feedback from both of you. Jeremy's workaround does the trick brilliantly, that's exactly what I was looking for. Thanks very much Jeremy.
Malcolm, I know about the Vectorfield node problem in Nuke, because I've checked with your csp lut as well and saw it was blown out. By now I've tried an endless number of combinations of inputspace, shaperspace, outputspace, but the tops were always clamped. I'm happy that this workaround does the trick.
There's just one thing I don't understand, Malcolm: how were you able to bake out the Kodak2383_sRGB.csp if this bug was in the code before? Or you used something else than ociobakelut?
Thanks again guys, I appreciate it.
On Tue, May 3, 2011 at 9:53 AM, Jeremy Selan <jeremy...@...>
I've checked this out and am able to recreate exactly what you
describe. I see the clamping when playing back the 'no shaper' baked
lut using OCIO. And also see the brightness increase when using the
shaper lut. For both tests I am just comparing the unbaked lut
application to that using OCIOFileTransform (in nuke).
The issue is related to some assumptions the Baker class is making
internally. I will try to refactor the Baker code to address this
issue this week (though it may push to next week). I will also touch
up a bunch of 'todos' in that part of the code (allowing for looser
input restrictions). Afterwards, the syntax you describe (both with,
and without, the shaperlut) will support HDR allocations. (For those
who dont specify shaperluts, the gpu allocation will be used to
achieve a similar effect).
In the meantime I am providing a simple workaround script which can be
used to generate HDR friendly csp luts. Note that for this csp lut
I'm taking advantage of non-uniformly sampled input domains. I am not
sure if all apps support this feature of .csp files. If your client
apps do not support this, let me know and we can work around this with
a one or two line change.