Re: ociobakelut clamps tops?


Malcolm Humphreys <malcolmh...@...>
 

Oliver Farkas <oliver...@...> wrote:

Hey guys,

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?
Its good that Jeremy could get a fix for you. I built all the luts before I left with ociobakelut to make sure we were not using any pre ocio data. This was checked with all the host apps and the ocio nuke nodes so its a bit strange that it doesn't work now or in this case. The baker was a pretty quick first pass so its not a complete surprise that it has issues but this sounds like its broke.

On Tue, May 3, 2011 at 9:53 AM, Jeremy Selan <jeremy...@...>
wrote:

Oliver,

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.


http://github.com/jeremyselan/OpenColorIO/tree/shapertest/testdata/csp/oliverbug

-- Jeremy
--
Sent from my phone.

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