Date   

Re: Question about IIF config

Marie Fétiveau <m...@...>
 

Great :)
That's much much better.
Thanks a lot !
I still have some small differencies comparing OCIOColorspaceNode and my two TuttleCTL nodes.
But I need to compare with CTLRender just to be sure it's not a pb with TuttleCTL.

I have another pb. When I export a 3DLUT thanks to ociobakeLut and compare the resulting LUT (using a VectorField node) with the output of a OCIOColorspace node, there a noticable shift. 
Here's my command : ociobakelut --inputspace aces --outputspace rrt_sRGB --format flame aces_to_ODT_sRGB.3dl

Assuming it's a LUT approximation problem, I tried to export 32, 64 and 128 segments LUTs. And indeed, the more I add segments, the less the shift is important.
But even at 128 segments (which is huge), there's still a tiny shift.

May be the RRT is so complex that a linear sampled LUT couldn't be enough ?

Anyway, on the way out I noticed a bug in ociobakeLut using the --cubesize option and exporting 3dl : the header is always computed for 17 segments.
For exemple with cubesize=32 :
header = 0 64 128 192 256 320 384 448 512 575 639 703 767 831 895 959 1023
should be = 0   33   66   99   132   165   198   231   264   297   330   363   396   429   462   495   528   561   594   627   660   693   726   759   792   825   858   891   924   957   990   1023

Thanks again.

Marie


On Wed, Oct 26, 2011 at 12:11 AM, Jeremy Selan <jeremy...@...> wrote:
I just rolled out a new iif profile, with updated 3dluts.

You'll note that inside the iif profile (in the lutimages subdir) are
the lattice images used to bake the rrt / odt into 3d luts. So you
should be able to use these image to bake any rrts you may be using
into a lut suitable for inclusion in the profile.

Please let me know if, using this updated approach, you are not able
to recreate an identical result.

-- Jeremy

On Mon, Oct 10, 2011 at 2:58 PM, Jeremy Selan <jeremy...@...> wrote:
> Your example looks good to me.  Can you test the sub components of
> your transform?
>
> If you skip the ctl nodes, and only try the log2lin portions, does
> that result in an identity transform?
>
> Feel free to send me your lut files / .nk files offline, I'd be happy
> to take a look as well.
>
> -- Jeremy
>
> 2011/10/5 Marie Fétiveau <m...@...>:
>> Thanks for the quick answer and the explanation :)
>> I tried this afternoon to create my own aceslg2_to_Rec709 LUT but I'm still
>> not sure to understand how it should work.
>> I started to give a quick try with the Nuke Log2Lin node to see what
>> happened.
>> So I connected a CMSTestPattern + a Nuke LogToLin node + my 2  CTL node (RRT
>> + ODT) + a generate LUT to create a logToLin_RRT_ODTr709.cube.
>> I also create a linToLog.cube (which correspond to Nuke LinToLog).
>> And I set the rrt_odt_r709 colorspace like this :
>> from_reference: !<GroupTransform>
>>       children:
>>         - !<FileTransform> {src: linToLog.cube, interpolation: linear}
>>         - !<FileTransform> {src: logToLin_RRT_ODTr709.cube, interpolation:
>> linear}
>> When I compare the two CTL nodes and the OCIOColorspace, that's not that bad
>> but there's a kind of offset + gamma shift...
>>  A picture is often better than a long talk away (I put the viewer in sRGB
>> instead linear to emphasize the shift on the screenshot).
>> Where's my mistake ?
>> Thanks a lot :)
>> Marie
>>
>> On Tue, Oct 4, 2011 at 7:24 PM, Jeremy Selan <jeremy...@...> wrote:
>>>
>>> Marie,
>>>
>>> Thanks for catching this!   The currently shipping IIF configuration
>>> is based on an older specification (I forget the exact version, but
>>> it's around 8 months old), so my hope is the versions will explain the
>>> differences you are seeing.  We've wanted to update to the latest RRT
>>> for awhile now, so let us take a stab at it and we'll see if it fixes
>>> everything.  We will also take care to note in the profile which RRT
>>> version it is specifically, to help avoid ambiguity in the future.
>>>
>>> The noise (discontinuity) you are seeing in the 3d RRT lut is an
>>> artifact of how we originally generated this table, we'll make sure
>>> it's all fixed in the updated version.
>>>
>>> The AllocationTransform you mention describes a linear -> log
>>> transform (a perfect mathematical log operator), where the range from
>>> ( 2^-10.4739 , 2^5.52607)  is rolled into (0.0-1.0) for sampling with
>>> a 3d lut.  The lut was generated by taking a 3d lattice image (0-1) ,
>>> unwarping it through the inverse of the transform, and then applying
>>> the analytical rrt.
>>>
>>> Thanks!
>>>
>>> -- Jeremy
>>>
>>>
>>> 2011/10/4 Marie Fétiveau <m...@...>:
>>> > Hello all !
>>> > I'm having a look at IIF config.ocio and I was wondering how you build
>>> > the aceslg2_to_Rec709.cube LUT for the rrt_odt_r709 colorspace.
>>> > I'm asking because when I compare an OCIOColorspace node (in : aces, out
>>> > :
>>> > rrt_odt_r709) and two TuttleCTL nodes (one with the RRT 2.2.1 and
>>> > another
>>> > with the REC701 softproof ODT), there are some differences :
>>> > - a small shift
>>> > - + some noise in yellows with OCIOColorspace node.
>>> > Here's a screenshot of my nuke scene and a jpg export
>>> > with TuttleCTL nodes
>>> > and an OpenColorIO Node.
>>> > For my tests, I'm using an XRite colorchart shot with a Red One and
>>> > exported
>>> > in EXR thanks to REDCineX (ACES option enabled).
>>> > am I mis-using the OCIOColorspace node ?
>>> > Anyway, I will be pleased to understand how the LUT was processed and
>>> > configured in the ocio config file.
>>> > I don't fully understand the purpose of the AllocationTransform vars
>>> > before
>>> > the FileTransform :
>>> > - !<ColorSpace>
>>> >     name: rrt_odt_r709
>>> >     family: rrt_odt_r709
>>> >     bitdepth: 32f
>>> >     isdata: false
>>> >     allocation: uniform
>>> >     allocationvars: [0, 1]
>>> >     from_reference: !<GroupTransform>
>>> >       children:
>>> >         - !<AllocationTransform> {allocation: lg2, vars: [-10.4739,
>>> > 5.52607]}
>>> >         - !<FileTransform> {src: aceslg2_to_Rec709.cube, interpolation:
>>> > linear}
>>> >
>>> >
>>> > Thanks a lot !
>>> > Marie
>>
>>
>


Re: Question about IIF config

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

I just rolled out a new iif profile, with updated 3dluts.

You'll note that inside the iif profile (in the lutimages subdir) are
the lattice images used to bake the rrt / odt into 3d luts. So you
should be able to use these image to bake any rrts you may be using
into a lut suitable for inclusion in the profile.

Please let me know if, using this updated approach, you are not able
to recreate an identical result.

-- Jeremy

On Mon, Oct 10, 2011 at 2:58 PM, Jeremy Selan <jeremy...@...> wrote:
Your example looks good to me.  Can you test the sub components of
your transform?

If you skip the ctl nodes, and only try the log2lin portions, does
that result in an identity transform?

Feel free to send me your lut files / .nk files offline, I'd be happy
to take a look as well.

-- Jeremy

2011/10/5 Marie Fétiveau <m...@...>:
Thanks for the quick answer and the explanation :)
I tried this afternoon to create my own aceslg2_to_Rec709 LUT but I'm still
not sure to understand how it should work.
I started to give a quick try with the Nuke Log2Lin node to see what
happened.
So I connected a CMSTestPattern + a Nuke LogToLin node + my 2  CTL node (RRT
+ ODT) + a generate LUT to create a logToLin_RRT_ODTr709.cube.
I also create a linToLog.cube (which correspond to Nuke LinToLog).
And I set the rrt_odt_r709 colorspace like this :
from_reference: !<GroupTransform>
      children:
        - !<FileTransform> {src: linToLog.cube, interpolation: linear}
        - !<FileTransform> {src: logToLin_RRT_ODTr709.cube, interpolation:
linear}
When I compare the two CTL nodes and the OCIOColorspace, that's not that bad
but there's a kind of offset + gamma shift...
 A picture is often better than a long talk away (I put the viewer in sRGB
instead linear to emphasize the shift on the screenshot).
Where's my mistake ?
Thanks a lot :)
Marie

On Tue, Oct 4, 2011 at 7:24 PM, Jeremy Selan <jeremy...@...> wrote:

Marie,

Thanks for catching this!   The currently shipping IIF configuration
is based on an older specification (I forget the exact version, but
it's around 8 months old), so my hope is the versions will explain the
differences you are seeing.  We've wanted to update to the latest RRT
for awhile now, so let us take a stab at it and we'll see if it fixes
everything.  We will also take care to note in the profile which RRT
version it is specifically, to help avoid ambiguity in the future.

The noise (discontinuity) you are seeing in the 3d RRT lut is an
artifact of how we originally generated this table, we'll make sure
it's all fixed in the updated version.

The AllocationTransform you mention describes a linear -> log
transform (a perfect mathematical log operator), where the range from
( 2^-10.4739 , 2^5.52607)  is rolled into (0.0-1.0) for sampling with
a 3d lut.  The lut was generated by taking a 3d lattice image (0-1) ,
unwarping it through the inverse of the transform, and then applying
the analytical rrt.

Thanks!

-- Jeremy


2011/10/4 Marie Fétiveau <m...@...>:
Hello all !
I'm having a look at IIF config.ocio and I was wondering how you build
the aceslg2_to_Rec709.cube LUT for the rrt_odt_r709 colorspace.
I'm asking because when I compare an OCIOColorspace node (in : aces, out
:
rrt_odt_r709) and two TuttleCTL nodes (one with the RRT 2.2.1 and
another
with the REC701 softproof ODT), there are some differences :
- a small shift
- + some noise in yellows with OCIOColorspace node.
Here's a screenshot of my nuke scene and a jpg export
with TuttleCTL nodes
and an OpenColorIO Node.
For my tests, I'm using an XRite colorchart shot with a Red One and
exported
in EXR thanks to REDCineX (ACES option enabled).
am I mis-using the OCIOColorspace node ?
Anyway, I will be pleased to understand how the LUT was processed and
configured in the ocio config file.
I don't fully understand the purpose of the AllocationTransform vars
before
the FileTransform :
- !<ColorSpace>
    name: rrt_odt_r709
    family: rrt_odt_r709
    bitdepth: 32f
    isdata: false
    allocation: uniform
    allocationvars: [0, 1]
    from_reference: !<GroupTransform>
      children:
        - !<AllocationTransform> {allocation: lg2, vars: [-10.4739,
5.52607]}
        - !<FileTransform> {src: aceslg2_to_Rec709.cube, interpolation:
linear}


Thanks a lot !
Marie


Updated IIF Color Configuration

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

The IIF color configuration has been updated to match the ut11
Reference Rendering Transform (RRT).

- Alex can probably better speak to the differences, but the major
visual difference in this RRT (compared to the prior OCIO profile) is
that high saturation inputs now maintain their luminance in the
rendered image, rather than being handled in a filmic (non-linear)
manner.

- This configuration addresses the color 'popping to magenta' issue
that was present in the prior OCIO IIF profile.

- This configuration includes the CTL / image reference used in
profile creation.

- Now that the IIF -> OCIO pipeline has been smoothed out (on our
end), we'll be much better able to stay in sync with IIF RRT
developments.

Download available:
http://github.com/imageworks/OpenColorIO-Configs/zipball/master
http://github.com/imageworks/OpenColorIO-Configs/tarball/master

-- Jeremy


Maya Viewport 2.0

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

Does anyone have any experience with Maya Viewport 2.0 color
management? We'd like to get the Maya / OCIO integration ball
rolling, and wondered who here has experience in that area.

-- Jeremy


JOBS: Sony Pictures Imageworks - Color Scientist

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

Hello!

Unfortunately, Joseph Slomka has decided to move on from Imageworks so
we're looking for a new color scientist (details below).

Please email me off-list if you have any referrals or specific questions.

Thanks!

-- Jeremy


Posting JOBS to ocio-dev

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

I'd like to encourage folks to utilize the ocio-dev as a resource for
job postings. The ocio-dev list is rather focused, so it seems nice
to be able to take advantage of it when a company is looking to fill a
color-specific role.

May I suggest the following guidelines for postings jobs to ocio-dev:

- Subject: "JOBS: ..."
- Postings must *directly* relate to color management in film
production, visual effects, animation, or gaming. Generic job
postings for lighters / compers / developers are not appropriate.

If anyone has any objections to this use of ocio-dev, please let me
know. Otherwise, I'll be posting another message momentarily... ;)

-- Jeremy


Re: CMake help

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

Good to know, thanks!

-- Jeremy

On Fri, Oct 14, 2011 at 5:06 PM, Ciaran <ciaran...@...> wrote:
I used the LD_PRELOAD hack to get around it - actually this is just a
manifestation of the more general nuke plugins linking to other libraries
linking issue and I'm not sure changing the rpath is the correct solution
anyway...


Re: CMake help

Ciaran <ciaran...@...>
 

I used the LD_PRELOAD hack to get around it - actually this is just a manifestation of the more general nuke plugins linking to other libraries linking issue and I'm not sure changing the rpath is the correct solution anyway...


Re: CMake help

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

Was hoping someone else would field this question...

Have you been able to figure it out yet? What platform are you on?
I'm not much of a cmake expert, unfortunately.

Are you familiar with readelf -a ? Check out runpath and rpath, and
if the nuke libs dir is being compiled in or not.

I also know that cmake variables that affect the rpath are:
INSTALL_RPATH_USE_LINK_PATH
along with
CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES

(where the all directories
listed in CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES will be removed
from the install RPATH)

-- Jeremy


Re: AllocationVars?

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

FYI - I've updated the website with the previous response to the
question. (In the upcoming weeks I'll be adding even more info /
examples about creating color configurations).

http://opencolorio.org/configurations/allocation_vars.html

-- Jeremy

On Mon, Sep 26, 2011 at 10:56 AM, Ciaran <ciaran...@...> wrote:
Could anybody say a little about what ColorSpace::setAllocation() and
ColorSpace::setAllocationVars() do?

I'm starting to get up and running writing my own luts into the spi1d format
for converting from float scene-linear to various outputs, which makes sense
so far.  I was cribbing from the spi-vfx python script which sets these and
I've found fiddling with the numbers drastically alters the quality of my
output.  I'm guessing this affects the resolution of some internal data used
for HDR->LDR but browsing the code doesn't make it clear how it works.  And
what is the origin of the [-15.0, 6.0] values used in spi-vfx?


CMake help

Ciaran <ciaran...@...>
 

Sorry, cmake is brand new to me and I figured it would be quicker to ask...

What would be the proper way to tell cmake to build the nuke plugins linking to the versions of libraries (libstdc++ etc) in the nuke install rather than the system ones?


Re: Question about IIF config

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

Your example looks good to me. Can you test the sub components of
your transform?

If you skip the ctl nodes, and only try the log2lin portions, does
that result in an identity transform?

Feel free to send me your lut files / .nk files offline, I'd be happy
to take a look as well.

-- Jeremy

2011/10/5 Marie Fétiveau <m...@...>:

Thanks for the quick answer and the explanation :)
I tried this afternoon to create my own aceslg2_to_Rec709 LUT but I'm still
not sure to understand how it should work.
I started to give a quick try with the Nuke Log2Lin node to see what
happened.
So I connected a CMSTestPattern + a Nuke LogToLin node + my 2  CTL node (RRT
+ ODT) + a generate LUT to create a logToLin_RRT_ODTr709.cube.
I also create a linToLog.cube (which correspond to Nuke LinToLog).
And I set the rrt_odt_r709 colorspace like this :
from_reference: !<GroupTransform>
      children:
        - !<FileTransform> {src: linToLog.cube, interpolation: linear}
        - !<FileTransform> {src: logToLin_RRT_ODTr709.cube, interpolation:
linear}
When I compare the two CTL nodes and the OCIOColorspace, that's not that bad
but there's a kind of offset + gamma shift...
 A picture is often better than a long talk away (I put the viewer in sRGB
instead linear to emphasize the shift on the screenshot).
Where's my mistake ?
Thanks a lot :)
Marie

On Tue, Oct 4, 2011 at 7:24 PM, Jeremy Selan <jeremy...@...> wrote:

Marie,

Thanks for catching this!   The currently shipping IIF configuration
is based on an older specification (I forget the exact version, but
it's around 8 months old), so my hope is the versions will explain the
differences you are seeing.  We've wanted to update to the latest RRT
for awhile now, so let us take a stab at it and we'll see if it fixes
everything.  We will also take care to note in the profile which RRT
version it is specifically, to help avoid ambiguity in the future.

The noise (discontinuity) you are seeing in the 3d RRT lut is an
artifact of how we originally generated this table, we'll make sure
it's all fixed in the updated version.

The AllocationTransform you mention describes a linear -> log
transform (a perfect mathematical log operator), where the range from
( 2^-10.4739 , 2^5.52607)  is rolled into (0.0-1.0) for sampling with
a 3d lut.  The lut was generated by taking a 3d lattice image (0-1) ,
unwarping it through the inverse of the transform, and then applying
the analytical rrt.

Thanks!

-- Jeremy


2011/10/4 Marie Fétiveau <m...@...>:
Hello all !
I'm having a look at IIF config.ocio and I was wondering how you build
the aceslg2_to_Rec709.cube LUT for the rrt_odt_r709 colorspace.
I'm asking because when I compare an OCIOColorspace node (in : aces, out
:
rrt_odt_r709) and two TuttleCTL nodes (one with the RRT 2.2.1 and
another
with the REC701 softproof ODT), there are some differences :
- a small shift
- + some noise in yellows with OCIOColorspace node.
Here's a screenshot of my nuke scene and a jpg export
with TuttleCTL nodes
and an OpenColorIO Node.
For my tests, I'm using an XRite colorchart shot with a Red One and
exported
in EXR thanks to REDCineX (ACES option enabled).
am I mis-using the OCIOColorspace node ?
Anyway, I will be pleased to understand how the LUT was processed and
configured in the ocio config file.
I don't fully understand the purpose of the AllocationTransform vars
before
the FileTransform :
- !<ColorSpace>
    name: rrt_odt_r709
    family: rrt_odt_r709
    bitdepth: 32f
    isdata: false
    allocation: uniform
    allocationvars: [0, 1]
    from_reference: !<GroupTransform>
      children:
        - !<AllocationTransform> {allocation: lg2, vars: [-10.4739,
5.52607]}
        - !<FileTransform> {src: aceslg2_to_Rec709.cube, interpolation:
linear}


Thanks a lot !
Marie


Re: Question about IIF config

Marie Fétiveau <m...@...>
 

Thanks for the quick answer and the explanation :)

I tried this afternoon to create my own aceslg2_to_Rec709 LUT but I'm still not sure to understand how it should work.

I started to give a quick try with the Nuke Log2Lin node to see what happened.

So I connected a CMSTestPattern + a Nuke LogToLin node + my 2  CTL node (RRT + ODT) + a generate LUT to create a logToLin_RRT_ODTr709.cube.
I also create a linToLog.cube (which correspond to Nuke LinToLog).

And I set the rrt_odt_r709 colorspace like this : 
from_reference: !<GroupTransform>
      children:
        - !<FileTransform> {src: linToLog.cube, interpolation: linear}
        - !<FileTransform> {src: logToLin_RRT_ODTr709.cube, interpolation: linear}  

When I compare the two CTL nodes and the OCIOColorspace, that's not that bad but there's a kind of offset + gamma shift...
 A picture is often better than a long talk away (I put the viewer in sRGB instead linear to emphasize the shift on the screenshot).

Where's my mistake ?

Thanks a lot :)

Marie


On Tue, Oct 4, 2011 at 7:24 PM, Jeremy Selan <jeremy...@...> wrote:
Marie,

Thanks for catching this!   The currently shipping IIF configuration
is based on an older specification (I forget the exact version, but
it's around 8 months old), so my hope is the versions will explain the
differences you are seeing.  We've wanted to update to the latest RRT
for awhile now, so let us take a stab at it and we'll see if it fixes
everything.  We will also take care to note in the profile which RRT
version it is specifically, to help avoid ambiguity in the future.

The noise (discontinuity) you are seeing in the 3d RRT lut is an
artifact of how we originally generated this table, we'll make sure
it's all fixed in the updated version.

The AllocationTransform you mention describes a linear -> log
transform (a perfect mathematical log operator), where the range from
( 2^-10.4739 , 2^5.52607)  is rolled into (0.0-1.0) for sampling with
a 3d lut.  The lut was generated by taking a 3d lattice image (0-1) ,
unwarping it through the inverse of the transform, and then applying
the analytical rrt.

Thanks!

-- Jeremy


2011/10/4 Marie Fétiveau <m...@...>:
> Hello all !
> I'm having a look at IIF config.ocio and I was wondering how you build
> the aceslg2_to_Rec709.cube LUT for the rrt_odt_r709 colorspace.
> I'm asking because when I compare an OCIOColorspace node (in : aces, out :
> rrt_odt_r709) and two TuttleCTL nodes (one with the RRT 2.2.1 and another
> with the REC701 softproof ODT), there are some differences :
> - a small shift
> - + some noise in yellows with OCIOColorspace node.
> Here's a screenshot of my nuke scene and a jpg export with TuttleCTL nodes
> and an OpenColorIO Node.
> For my tests, I'm using an XRite colorchart shot with a Red One and exported
> in EXR thanks to REDCineX (ACES option enabled).
> am I mis-using the OCIOColorspace node ?
> Anyway, I will be pleased to understand how the LUT was processed and
> configured in the ocio config file.
> I don't fully understand the purpose of the AllocationTransform vars before
> the FileTransform :
> - !<ColorSpace>
>     name: rrt_odt_r709
>     family: rrt_odt_r709
>     bitdepth: 32f
>     isdata: false
>     allocation: uniform
>     allocationvars: [0, 1]
>     from_reference: !<GroupTransform>
>       children:
>         - !<AllocationTransform> {allocation: lg2, vars: [-10.4739,
> 5.52607]}
>         - !<FileTransform> {src: aceslg2_to_Rec709.cube, interpolation:
> linear}
>
>
> Thanks a lot !
> Marie


Re: Question about IIF config

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

Marie,

Thanks for catching this! The currently shipping IIF configuration
is based on an older specification (I forget the exact version, but
it's around 8 months old), so my hope is the versions will explain the
differences you are seeing. We've wanted to update to the latest RRT
for awhile now, so let us take a stab at it and we'll see if it fixes
everything. We will also take care to note in the profile which RRT
version it is specifically, to help avoid ambiguity in the future.

The noise (discontinuity) you are seeing in the 3d RRT lut is an
artifact of how we originally generated this table, we'll make sure
it's all fixed in the updated version.

The AllocationTransform you mention describes a linear -> log
transform (a perfect mathematical log operator), where the range from
( 2^-10.4739 , 2^5.52607) is rolled into (0.0-1.0) for sampling with
a 3d lut. The lut was generated by taking a 3d lattice image (0-1) ,
unwarping it through the inverse of the transform, and then applying
the analytical rrt.

Thanks!

-- Jeremy


2011/10/4 Marie Fétiveau <m...@...>:

Hello all !
I'm having a look at IIF config.ocio and I was wondering how you build
the aceslg2_to_Rec709.cube LUT for the rrt_odt_r709 colorspace.
I'm asking because when I compare an OCIOColorspace node (in : aces, out :
rrt_odt_r709) and two TuttleCTL nodes (one with the RRT 2.2.1 and another
with the REC701 softproof ODT), there are some differences :
- a small shift
- + some noise in yellows with OCIOColorspace node.
Here's a screenshot of my nuke scene and a jpg export with TuttleCTL nodes
and an OpenColorIO Node.
For my tests, I'm using an XRite colorchart shot with a Red One and exported
in EXR thanks to REDCineX (ACES option enabled).
am I mis-using the OCIOColorspace node ?
Anyway, I will be pleased to understand how the LUT was processed and
configured in the ocio config file.
I don't fully understand the purpose of the AllocationTransform vars before
the FileTransform :
- !<ColorSpace>
    name: rrt_odt_r709
    family: rrt_odt_r709
    bitdepth: 32f
    isdata: false
    allocation: uniform
    allocationvars: [0, 1]
    from_reference: !<GroupTransform>
      children:
        - !<AllocationTransform> {allocation: lg2, vars: [-10.4739,
5.52607]}
        - !<FileTransform> {src: aceslg2_to_Rec709.cube, interpolation:
linear}


Thanks a lot !
Marie


Question about IIF config

Marie Fétiveau <m...@...>
 

Hello all !

I'm having a look at IIF config.ocio and I was wondering how you build the aceslg2_to_Rec709.cube LUT for the rrt_odt_r709 colorspace.

I'm asking because when I compare an OCIOColorspace node (in : aces, out : rrt_odt_r709) and two TuttleCTL nodes (one with the RRT 2.2.1 and another with the REC701 softproof ODT), there are some differences :
- a small shift
- + some noise in yellows with OCIOColorspace node.

Here's a screenshot of my nuke scene and a jpg export with TuttleCTL nodes and an OpenColorIO Node.
For my tests, I'm using an XRite colorchart shot with a Red One and exported in EXR thanks to REDCineX (ACES option enabled).

am I mis-using the OCIOColorspace node ?

Anyway, I will be pleased to understand how the LUT was processed and configured in the ocio config file.
I don't fully understand the purpose of the AllocationTransform vars before the FileTransform :
- !<ColorSpace>
    name: rrt_odt_r709
    family: rrt_odt_r709
    bitdepth: 32f
    isdata: false
    allocation: uniform
    allocationvars: [0, 1]
    from_reference: !<GroupTransform>
      children:
        - !<AllocationTransform> {allocation: lg2, vars: [-10.4739, 5.52607]}
        - !<FileTransform> {src: aceslg2_to_Rec709.cube, interpolation: linear}



Thanks a lot !

Marie


OpenColorIO Version 1.0 is released

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

Friends,

We've just officially released version 1.0, now available for download here:
http://github.com/imageworks/OpenColorIO/zipball/v1.0.0
http://github.com/imageworks/OpenColorIO/tarball/v1.0.0

I would recommend all users bump up to this version at their
convenience. We've been using it internally since RC1 was released,
and have not run into any difficulties.

The changes against 1.0RC1 are minimal (the only one of note is a fix
related to Truelight LUT reading).

Enjoy!

-- Jeremy


Re: AllocationVars?

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

Yes, that important functionality is under documented. I'll try to
update the headers / documentation this week. But in the meantime...

The allocation / allocation vars are utilized using during GPU 3dlut /
shader text generation. (Processor::getGpuShaderText,
Processor::getGpuLut3D).

If, in the course of GPU processing, a 3D lut is required, the
"allocation / allocation vars" direct how OCIO should sample the
colorspace, with the intent being to maintain maximum fidelity and
minimize clamping.

Currently support allocations / variables:

// ALLOCATION_UNIFORM::
//
// 2 vars: [min, max]
//
// ALLOCATION_LG2::
//
// 2 vars: [lg2min, lg2max]
// 3 vars: [lg2min, lg2max, linear_offset]

So say you have an srgb image (such as an 8-bit tif), where you know
the data ranges between 0.0 - 1.0 (after converting to float). If you
wanted to apply a 3d lut to this data, there is no danger in sampling
that space uniformly and clamping data outside (0,1). So for this
colorspace we would tag it:

allocation: uniform
allocationvars: [0.0, 1.0]
(These are the defaults, so the tagging could also be skipped.)

But what if you were actually first processing the data, where
occasionally small undershoot and overshoot values were encountered?
If you wanted OCIO to preserve this overshoot / undershoot pixel
information, you would do so by modifying the allocation vars.

allocation: uniform
allocationvars: [-0.125, 1.125]

This would mean that any image data originally within [-0.125, 1.125]
will be preserved during GPU processing. (Protip: Data outside this
range *may* actually be preserved in some circumstances - such as if a
3d lut is not needed - but it's not required to be preserved).

So why not leave this at huge values (such as [-1000.0, 1000.0]) all
the time? Well, there's a cost to supporting this larger dynamic
range, and that cost is reduced precision within the 3D luts sample
space. So in general you're best served by using sensible
allocations (the smallest you can get away with, but no smaller).

Now in the case of high-dynamic range color spaces (such as float
linear), a uniform sampling is not sufficient because the max value we
need to preserve is so high.

Say you were using a 32x32x32 3d lookup table (a common size). Middle
gray is at 0.18, and specular values are very much above that. Say
the max value we wanted to preserve in our coding space is 256.0, each
3d lut lattice coordinates would represent 8.0 units of linear light!
That means the vast majority of the perceptually significant portions
of the space wouldnt be sampled at all!

unform allocation from 0-256:
0
8.0
16.0
...
240.0
256.0

So another allocation is defined, lg2:

- !<ColorSpace>
name: linear
description: |
Scene-linear, high dynamic range. Used for rendering and compositing.
allocation: lg2
allocationvars: [-8, 8]

In this case, we're saying that the appropriate ways to sample the 3d
lut are logarithmically, from 2^-8 stops to 2^8 stops.

Sample locations:
2^-8: 0.0039
2^-7: 0.0078
2^-6: 0.0156
...
2^0: 1.0
...
2^6: 64.0
2^7: 128.0
2^8: 256.0

Which gives us a much better perceptual sampling of the space.

The one downside of this approach is that it can't represent 0.0,
which is why we optionally allow a 3d allocation var, a black point
offset. If you need to preserve 0.0 values, and you have a high
dynamic range space, you can specify a small offset.

Example:
allocation: lg2
allocationvars: [-8, 8, 0.00390625]


The [-15.0, 6.0] values in spi-vfx come from the fact that all of the
linearizations provided in that profile span the region from 2^-15
stops, to 2^6 stops. One could probably change that black point to a
higher number (such as -8), but if you raised it too much you would
start seeing black values be clipped. Conversely, on the high end
one could raise it a bit but if you raised it too far the precision
would suffer around gray, and if you lowered it further you'd start to
see highlight clipping.

I hope this makes sense. (I wrote this in a hurry). Please let me
know if you need further clarification.

-- Jeremy

On Mon, Sep 26, 2011 at 10:56 AM, Ciaran <ciaran...@...> wrote:
Could anybody say a little about what ColorSpace::setAllocation() and
ColorSpace::setAllocationVars() do?

I'm starting to get up and running writing my own luts into the spi1d format
for converting from float scene-linear to various outputs, which makes sense
so far.  I was cribbing from the spi-vfx python script which sets these and
I've found fiddling with the numbers drastically alters the quality of my
output.  I'm guessing this affects the resolution of some internal data used
for HDR->LDR but browsing the code doesn't make it clear how it works.  And
what is the origin of the [-15.0, 6.0] values used in spi-vfx?


AllocationVars?

Ciaran <ciaran...@...>
 

Could anybody say a little about what ColorSpace::setAllocation() and ColorSpace::setAllocationVars() do?

I'm starting to get up and running writing my own luts into the spi1d format for converting from float scene-linear to various outputs, which makes sense so far.  I was cribbing from the spi-vfx python script which sets these and I've found fiddling with the numbers drastically alters the quality of my output.  I'm guessing this affects the resolution of some internal data used for HDR->LDR but browsing the code doesn't make it clear how it works.  And what is the origin of the [-15.0, 6.0] values used in spi-vfx?


Review: Fixed Truelight LUT reading bug

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

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

Oh no!

Today, in the normal course of production work (debugging why our
editorial deliverables didn't match on-set reference), we discovered
that OCIO is not applying Truelight LUTs correctly. The shaper lut
scaling had an off by one error, which lead to Truelight LUTs
appearing too dim by a factor of roughly lut3dsize/(lut3dsize+1). (~6%
for a 17x17x17).

This was doubly unfortunate as even though we had a test suite, the
problem slipped through because our original Truelight LUTs used for
validation were generated incorrectly! This commit updates Truelight
LUT support to match the reference specification, as posted on the
official filmlight website.

Additional updates:
- Truelight LUTs that only specify the 1D or 3D component are now
supported. (per spec)
- Truelight LUT reading now properly ignores data past the '# end'
tag. (per spec)

Remaining Issue: 1D shaper luts (InputLUT) using integer encodings (vs
float) are not supported.
This will be added once suitable examples can be found. (The Truelight
docs do not include an example).

I'm very glad we found this before the official 1.0.0 release, and my
deepest apologies are extended to anyone this may have affected.

In this upcoming week, I will go through all the other LUT formats,
find the original reference documentation, and test all formats again
to validate there are no other hidden surprises.

This will be rolled into both the 0.8 and 1.0 branches.

-- Jeremy


Re: FileTransform interface changes

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

Hi,

The shaper interpolation should be what we agreed.

Interpolation FileTransform::getShaperInterpolation() const;
void FileTransform::setShaperInterpolation(Interpolation interp);
bool FileTransform::hasShaper();

The normal interpolation should stay as it is.

Would FileTransform::setOptionString(...) introduce the same complexity?
 
It would be get to the same end, so yes it would be similar.

Say you wanted to create the OCIOFileTransform in nuke. In this
system, would you expect to see a single knob, 'optionString', or
multiple knobs (cccid, etc)? If a single knob is exposed, how would
the user know what to set? Would we just provide helptext which
documented the options?
 
That would be up to the client app to parse and display as it wishes, it would be nice in the nuke case to have multiple knobs.

What would the string format be? JSON/YAML?
 
I would go for something simple as it would be replaced in 2.0 anyway. I would go for a ';' separated list of key=value pairs.

What keys would be supported in 1.0? shaper interpolation + cccid?
How about normal interpolation?
 
For now it would be just be 'cccid'. This just allows to add additional options between 1.0 and 20 if it's needed with out changing the public interface.

.malcolm

-- Jeremy

On Fri, Sep 16, 2011 at 2:40 AM, Malcolm Humphreys
<malcolmh...@...> wrote:
>
> Could we find a halfway point?
> FileTransform::getOptionString()
> FileTransform::setOptionString(const char * id)
>
> This could take a 'token1=value1;token2=value2' string. This is a bit ugly
> but does allow for the interface to be not so format specific while also
> allowing to add other options if they are needed for fixing bugs on the path
> to 2.0.
>
> eg.
> FileTransform::setOptionString("CCCId=myfavshot;");

1601 - 1620 of 2243