ociobakelut clamps tops?

[Oliver Farkas]

Hey guys,

I'm trying to use ociobakelut to bake out a .csp lut. I'm using the latest opencolorio (0.8.0), but getting weird results. It clamps the tops, details in the bright areas are completely gone. I'm wondering if I'm missing something.


The command I'm using is this:

ociobakelut --iconfig ./config.ocio --inputspace scene_grey18 --outputspace Dreamcolor --format cinespace > ./Kodak2383CoolGrade_ocio_Dreamcolor.csp 

The corresponding parts in the config.ocio look like this:


  - !<ColorSpace>
    name: scene_grey18
    family: lin
    bitdepth: 32f
    isdata: false
    gpuallocation: lg2
    gpumin: -15
    gpumax: 6


  - !<ColorSpace>
    name: Dreamcolor
    family: lin
    bitdepth: 32f
    isdata: false
    gpuallocation: uniform
    gpumin: 0
    gpumax: 1
    from_reference: !<GroupTransform>
      children:
         - !<CDLTransform> {slope: [0.80369623146242275, 0.9566818354009814, 0.94751600781483858], offset: [0, 0, 0], power: [1, 1, 1], saturation: 1}
         - !<FileTransform> {src: jp_lin2log.lut, interpolation: linear}
         - !<FileTransform> {src: Kodak2383_Dreamcolor.cub, interpolation: linear}



Cheers,
Oliver

[Jeremy Selan]

Hmmm,

Oliver - could you email be your jp_lin2log.lut (directly)? I'd like
to re-create this on my end. Dont worry about the Kodak cube lut, I
can use one of my own there instead.

One thing I notice, the Dreamcolor family shouldnt be 'lin'. I'd
probably set it to 'Dreamcolor' on the absence of other information.
(The family is often used to short-circuit conversions of the same
type, but at differing bit depths). I should probably update the API
so people can leave it blank if they dont know it, and to assume the
color-space name in that case).

-- Jeremy

[dbr/Ben]

You'll need to use the --shaperspace to make a LUT that goes from a non 0-1 space, otherwise you trying to do a lin-to-log in a 3D LUT.

If I understood the code right, it does..

CSP prelut: input to shaperspace as 1D LUT
3D LUT: shaperspace to output space

If omit the shaperspace arg, then it's all done in the cube (and the prelut is a no-op)

...so I think your display colourspace needs to have a 0-1 log input (just the kodak LUT). Then you would do:

--inputspace graded_linear --shaperspace jplog --outputspace kodak2383_dreamcolour

Not ideal, although you could possibly do the grade in the dreamcolor space by doing a log2lin, CDL then lin2log, and replace the graded_linear space with your scene_grey18

Ideally the Baker would inspect the transform op-tree and put as much of the 1D transform (the CDL and lin2log parts) in the prelut, and the rest in the cube.. Not sure how difficult this would be to achieve (think there's todos in the code about this)

- Ben

[Oliver Farkas]

Hey guys,

Ben, I've tried what you suggested. The input is graded scene linear, the shaper is lin to log and the output is a log to Kodak2383 on a DCI screen. I assumed this would work, but when I applied the generated lut on top of a scene linear exr, then the result I got was a blown out image: everything was fully bright, I could only see few parts of the image, all the rest was white.

I played around a bit with the settings. The scene_grey18 entry in the config file contains no transform whatsoever, so I assumed the next would do nothing at all. 

ociobakelut --inputspace scene_grey18 --outputspace scene_grey18

But the highlights get clamped. This means that it's not the jplinlog or the print lut that's causing the clamping. 

The exr files do have rgb values that go over 1.0, so maybe this problem's got to do something with that... but I'm not too sure what's happening. I'll try to dig into the code to see if I can find where this is coming from.

Thanks,

Oliver

[Jeremy Selan]

Oliver,

Sorry I haven't had a chance to look into this yet. I will do my best
to get to it first thing tomorrow. (Mon AM). My expectation is that
this shouldn't be too hard, OCIO is designed to work with HDR float32
-- and we use it internally in exactly the way you describe - so it's
likely just a minor bug you've run into first.

-- Jeremy

[Malcolm Humphreys]

Hi Oliver,

Ok I wrote all of this and then released are you trying to check these csp luts in the  nuke vectorfield node? nuke vectorfield node currently doesn't support the prelut section in the csp format you will just get a blown out image. Check the luts in RV and if it still doesn't work feel free to read on..

I played around a bit with the settings. The scene_grey18 entry in the config file contains no transform whatsoever, so I assumed the next would do nothing at all. 

ociobakelut --inputspace scene_grey18 --outputspace scene_grey18

But the highlights get clamped. This means that it's not the jplinlog or the print lut that's causing the clamping.

All 1D or 3D luts are bound limited in nature, even for half floats you would need a very large lut to cover all values. So I would expect a scene_grey18 -> scene_grey18 to reflect an identity lut which would clamp input values outside the 0.0 - 1.0 range.

I would hope this would be identical to the luts created for HP LCD but using a different cube for the Dreamcolors.

You should have a color space defined for each of your display devices, in your case the sRGB and Dreamcolor LCDs. ie.

  - !<ColorSpace>

    name: # device space

    ...

    from_reference: !<GroupTransform>

      children:

         - !<CDLTransform> # cool grade in linear (drd custom)

         - !<FileTransform> # jp lin to log 1D

         - !<FileTransform> # log to device cube

I would first check that each of these behave as expect in nuke using the OCIO node, if this does work (which I'm guessing does I would be surprised if it doesn't) this points to something going a bit wrong when baking. If it doesn't work something has gone a bit wrong with the truelight cube export.

Just check that you have the following at the top of your config.

- !<ColorSpace>

    name: scene_grey18

    family: lin

    bitdepth: 32f

    isdata: false

    gpuallocation: lg2

    gpumin: -15

    gpumax: 6

  - !<ColorSpace>

    name: scene_grey18_log

    family: log

    bitdepth: 10ui

    isdata: false

    gpuallocation: uniform

    gpumin: 0

    gpumax: 1

    from_reference: !<FileTransform> {src: jp_lin2log.lut, interpolation: linear}

I would expect the baking command line in this case would be something the lines of.

ociobakelut --iconfig ./config.ocio --inputspace scene_grey18 --shaperspace scene_grey18_log --outputspace <device space> --format cinespace

When the serialisation/baking of the device space happens the grade will also be taken into account. You shouldn't need to create a separate linearGraded colorspace as ben suggested. I haven't checked the code but I have a feeling this might not work as expected.

It should be noted that the shaperspace should only be used to allocate/shape the data and not contain colorimetry type transforms ie color grades.

If you can test exporting both a houdini and cinespace lut and see if you get the same results in RV and Mplay and let us know.

.malcolm

[Jeremy Selan]

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

[Oliver Farkas]

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? Or you used something else than ociobakelut? 

Thanks again guys, I appreciate it. 

Oliver

[Malcolm Humphreys]

Oliver Farkas <oliver...@gmail.com> 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.

--
Sent from my phone.