Date   

Re: Yaml-cpp version / windows build

dbr/Ben <dbr....@...>
 

Sounds good!

I seem to recall Malcolm mentioning that an updated yaml-cpp would allow tidying up the config syntax a bit - allowing "-FileTransform{src:blah}" instead of "-!<FileTransform>{src:blah}", maybe? No idea if this is something we'd get "for free", or if it would require code changes, becoming incompatible with existing configs and other bad things...
- Ben

On 18/05/2011, at 2:33, Jeremy Selan <jeremy...@...> wrote:

FYI,

The Foundry has successfully gotten OCIO working on Windows, but it
required bumping up to the latest stable yaml-cpp version.  So just a
heads up, that library version will be changing soon. (along with a
few other misc. patches).  This wont effect binary compatibility - I
just wanted to keep people in the loop (for those working on the ext
dir).

-- Jeremy


Review: Windows Support Bugfixes

Jeremy Selan <jeremy...@...>
 

https://github.com/imageworks/OpenColorIO/pull/117

Added a bunch of windows build fixes. Thanks to the Foundry for
providing this hitlist. Biggest change of note is the updated from
yaml-r423 to yaml-r482. This was a yaml major version change, and
required internal updates to use the new API. Known issue: Only
addresses windows build issues in the core library, still have to
address the src/nuke subdirectory.

-- Jeremy


Re: External Dependencies

dbr/Ben <dbr....@...>
 

Heh, an OCIO image viewer for iPad? \o/

I've compiled OCIO via the Xcode project generator a while ago, when adding the CSP prelut support (to get Xcode's nice error reporting) - wasn't for iOS, but the only problem I vaguely recall was something minor related to a Python header path or something

On 18/05/2011, at 2:12, Jeremy Selan <jeremy...@...> wrote:

We can certainly wait. I'll do all my development on a local
(jeremys) topic branch, which should more than suffice until around
siggraph.

-- Jeremy

On Tue, May 17, 2011 at 9:26 AM, Malcolm Humphreys
<malcolmh...@...> wrote:
Can I give it a go before you decide? I was looking at andriod porting a
while back as well which I guess is along the same lines.

.malcolm

On 18 May, 2011,at 02:15 AM, Jeremy Selan <jeremy...@...> wrote:

Folks,

I've been trying to get OCIO compiled for the iPad (think siggraph
tech demo), and I've been having a very hard time getting the XCode
cmake exporter to generate a working project. I've followed all the
online instructions, upgraded to the latest cmake, and even
investigated not using xcode and just cross-compiling to create a
static arm library - but no success thus far. Has anyone else given
this a shot? I've pinged a few people in the cmake / ios community,
and their universal recommendation is, if possible, to not rely on
cmake to generate the xcode project but it instead just add the
library to your native project as source files.

For the core OCIO library this would be rather simple, with the
exception of two libraries cmake pulls at build time from ext:
tinyxml, yaml-cpp.

What would people's thoughts be on pulling these libs back into
src/core (as they used to be)? All the other libraries
(lcms,sphinx,...) would remain in ext. This would allow people to
easily build the core library, even in circumstances where cmake is
not available / appropriate. (Basically all you'd have to do is
provide the constants in the OpenColorABI.h and the rest would be
simple.) I really like the cleanliness of the current cmake build
system, but I imagine in the context of high performance mobile
devices this will come up more and more, and my gut feel is that any
native cmake -> xcode (or equivalent) process will be fragile in the
long term.

-- Jeremy


Yaml-cpp version / windows build

Jeremy Selan <jeremy...@...>
 

FYI,

The Foundry has successfully gotten OCIO working on Windows, but it
required bumping up to the latest stable yaml-cpp version. So just a
heads up, that library version will be changing soon. (along with a
few other misc. patches). This wont effect binary compatibility - I
just wanted to keep people in the loop (for those working on the ext
dir).

-- Jeremy


Re: External Dependencies

Jeremy Selan <jeremy...@...>
 

We can certainly wait. I'll do all my development on a local
(jeremys) topic branch, which should more than suffice until around
siggraph.

-- Jeremy

On Tue, May 17, 2011 at 9:26 AM, Malcolm Humphreys
<malcolmh...@...> wrote:
Can I give it a go before you decide? I was looking at andriod porting a
while back as well which I guess is along the same lines.

.malcolm

On 18 May, 2011,at 02:15 AM, Jeremy Selan <jeremy...@...> wrote:

Folks,

I've been trying to get OCIO compiled for the iPad (think siggraph
tech demo), and I've been having a very hard time getting the XCode
cmake exporter to generate a working project. I've followed all the
online instructions, upgraded to the latest cmake, and even
investigated not using xcode and just cross-compiling to create a
static arm library - but no success thus far. Has anyone else given
this a shot? I've pinged a few people in the cmake / ios community,
and their universal recommendation is, if possible, to not rely on
cmake to generate the xcode project but it instead just add the
library to your native project as source files.

For the core OCIO library this would be rather simple, with the
exception of two libraries cmake pulls at build time from ext:
tinyxml, yaml-cpp.

What would people's thoughts be on pulling these libs back into
src/core (as they used to be)? All the other libraries
(lcms,sphinx,...) would remain in ext. This would allow people to
easily build the core library, even in circumstances where cmake is
not available / appropriate. (Basically all you'd have to do is
provide the constants in the OpenColorABI.h and the rest would be
simple.) I really like the cleanliness of the current cmake build
system, but I imagine in the context of high performance mobile
devices this will come up more and more, and my gut feel is that any
native cmake -> xcode (or equivalent) process will be fragile in the
long term.

-- Jeremy


Re: External Dependencies

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

Can I give it a go before you decide? I was looking at andriod porting a while back as well which I guess is along the same lines.

.malcolm

On 18 May, 2011,at 02:15 AM, Jeremy Selan <jere...@...> wrote:

Folks,

I've been trying to get OCIO compiled for the iPad (think siggraph
tech demo), and I've been having a very hard time getting the XCode
cmake exporter to generate a working project. I've followed all the
online instructions, upgraded to the latest cmake, and even
investigated not using xcode and just cross-compiling to create a
static arm library - but no success thus far. Has anyone else given
this a shot? I've pinged a few people in the cmake / ios community,
and their universal recommendation is, if possible, to not rely on
cmake to generate the xcode project but it instead just add the
library to your native project as source files.

For the core OCIO library this would be rather simple, with the
exception of two libraries cmake pulls at build time from ext:
tinyxml, yaml-cpp.

What would people's thoughts be on pulling these libs back into
src/core (as they used to be)? All the other libraries
(lcms,sphinx,...) would remain in ext. This would allow people to
easily build the core library, even in circumstances where cmake is
not available / appropriate. (Basically all you'd have to do is
provide the constants in the OpenColorABI.h and the rest would be
simple.) I really like the cleanliness of the current cmake build
system, but I imagine in the context of high performance mobile
devices this will come up more and more, and my gut feel is that any
native cmake -> xcode (or equivalent) process will be fragile in the
long term.

-- Jeremy


External Dependencies

Jeremy Selan <jeremy...@...>
 

Folks,

I've been trying to get OCIO compiled for the iPad (think siggraph
tech demo), and I've been having a very hard time getting the XCode
cmake exporter to generate a working project. I've followed all the
online instructions, upgraded to the latest cmake, and even
investigated not using xcode and just cross-compiling to create a
static arm library - but no success thus far. Has anyone else given
this a shot? I've pinged a few people in the cmake / ios community,
and their universal recommendation is, if possible, to not rely on
cmake to generate the xcode project but it instead just add the
library to your native project as source files.

For the core OCIO library this would be rather simple, with the
exception of two libraries cmake pulls at build time from ext:
tinyxml, yaml-cpp.

What would people's thoughts be on pulling these libs back into
src/core (as they used to be)? All the other libraries
(lcms,sphinx,...) would remain in ext. This would allow people to
easily build the core library, even in circumstances where cmake is
not available / appropriate. (Basically all you'd have to do is
provide the constants in the OpenColorABI.h and the rest would be
simple.) I really like the cleanliness of the current cmake build
system, but I imagine in the context of high performance mobile
devices this will come up more and more, and my gut feel is that any
native cmake -> xcode (or equivalent) process will be fragile in the
long term.

-- Jeremy


Review: Refactored baker code to allow for more advanced lut output

Jeremy Selan <jeremy...@...>
 

https://github.com/imageworks/OpenColorIO/pull/116

This addresses oliver's bug where an HDR lin -> Dreamcolor ociobakelut
command was clipping the highlights.
After this fix, you can get a proper output .csp both with and without
the --shaper specified. (if the shaper is not
specified, it will fall back on the allocation for the input space,
and for oliver's linear example (lg2, -7.5, 4) will match
the 'log' shaper space almost exactly.

There is one known regression in this code - I have temporarily
disabled the .hdl lut baking as I have not ported that code.
But I wanted to get this checkin in before then, as it's such a large
change (in terms of number of lines of code).

Other changes:
* Added .3dl baking
* Added Processor.hasChannelCrosstalk()
* Exposed both FormatName + FormatExtension
* FileFormats can register multiple names. (ex: lustre 3dl / flame 3dl)
* Baker defaults are format specific
* ociobakeluts has cleaned up syntax, fewer args needed in most cases

The bakelut logic has been moved from the Baker.cpp, into each output format.
This can eventually be re-refactored, but in the meantime until we have more
examples I think we can get higher quality (format specific) color output
by doing the logic in each outputter.

Remaining tasks:
* update houdini lut baker to work again. (currently disabled)
* let the .csp output dynamically pick between a 1d and 3d output (now
that hasChannelCrosstalk is exposed, this will be trivial)

-- Jeremy


Review: misc python updates

Jeremy Selan <jeremy...@...>
 

https://github.com/imageworks/OpenColorIO/pull/114

* PyColorSapce supports kwarg initialization
* Exposed ClearAllCaches to python

-- Jeremy


Review: Added OCIO_VERSION_HEX to public header for easy version comparison

Jeremy Selan <jeremy...@...>
 

https://github.com/imageworks/OpenColorIO/pull/112

This exposes a single 4-byte hex number, e.g. 0x01050200 == 1.5.2

Use this for numeric comparisons, e.g. #if OCIO_VERSION_HEX >= ...
Note: in the case where SOVERSION is overridden at compile-time, this
will reflect the original API version number.

Code concept is stolen from cpython source.

Addresses issue
https://github.com/imageworks/OpenColorIO/issues/65

-- Jeremy


OCIO 0.8.1 Released

Jeremy Selan <jeremy...@...>
 

Version 0.8.1 (May 9 2011):
* New roles: TEXTURE_PAINT + MATTE_PAINT
* Mari API Example (src/mari)
* FileFormat registry updated to allow Windows + Debug support
* boost_ptr build compatibility option

-- Jeremy


Review: FileFormat registry refactor

Jeremy Selan <jeremy...@...>
 

https://github.com/imageworks/OpenColorIO/pull/111

FileFormat registry refactor

The registration mechanism is now less fragile, using the 'construct
on first use' approach rather than relying on static initialization to
register each format. This is a more portable implementation (should
work on windows), and also avoid some issues we've been seeing when
using gcc debug versions of the library.

-- Jeremy


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.


Re: ociobakelut clamps tops?

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

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


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


Re: ociobakelut clamps tops?

Jeremy Selan <jeremy...@...>
 

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


Re: ociobakelut clamps tops?

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

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

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



Re: ociobakelut clamps tops?

Jeremy Selan <jeremy...@...>
 

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

On Sun, May 1, 2011 at 10:48 PM, Oliver Farkas <oliver...@...> wrote:
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




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


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.

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


Re: ociobakelut clamps tops?

dbr/Ben <dbr....@...>
 

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


Re: ociobakelut clamps tops?

Jeremy Selan <jeremy...@...>
 

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

1721 - 1740 of 2243