Re: ociobakelut clamps tops?

Oliver Farkas <oliver...@...>

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.


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) 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

Join to automatically receive all group messages.