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

On Fri, Apr 29, 2011 at 9:58 AM, dbr/Ben <dbr....@...> wrote:

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

On 29/04/2011, at 2:56, Jeremy Selan <jeremy...@...> wrote:

> 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
>
> On Thu, Apr 28, 2011 at 1:20 AM, Oliver Farkas <oliver...@...> wrote:
>> 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
>>