Re: ociobakelut clamps tops?
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.