Date   

Re: Add ExpressionTransform op

Marie Fetiveau <ma...@...>
 

Ok, thanks.

In the last commit of this PR (february 2015), an OCIO_USE_LLVM opt was added so I actually built this code without LLVM.

On Sat, May 23, 2015 at 5:10 AM, Malcolm Humphreys <malcolmh...@...> wrote:
We have been waiting for Mark to post headers for the new plugin API.

The idea is to keep the OCIO core free of heavy dependencies and for things like Expression, CTL and Truelight to be supplied by plugins (which are optional and can have heavy link dependencies).

Merging this pull request would force all the third party apps to start compiling and linking to LLVM.

.malcolm

On 22/05/2015, at 10:49 PM, Marie Fetiveau wrote:

Helloo,

Someone knows why it's on hold ?

Thanks,

Marie

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.



--
Marie Fétiveau
Color / IO / Comp Pipeline TD
_____________________

      


Re: Add ExpressionTransform op

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

We have been waiting for Mark to post headers for the new plugin API.

The idea is to keep the OCIO core free of heavy dependencies and for things like Expression, CTL and Truelight to be supplied by plugins (which are optional and can have heavy link dependencies).

Merging this pull request would force all the third party apps to start compiling and linking to LLVM.

.malcolm


On 22/05/2015, at 10:49 PM, Marie Fetiveau wrote:

Helloo,

Someone knows why it's on hold ?

Thanks,

Marie

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Add ExpressionTransform op

Marie Fetiveau <ma...@...>
 

Helloo,

Someone knows why it's on hold ?

Thanks,

Marie


Re: Support for OpenGL/GLSL > 2.0?

mark.alex...@...
 

texture3D() is also deprecated in GLSL 1.30, so it should be returning the texture() version for 1.30. An additional enum shouldn't be needed since GLSL is forward-compatible from 1.30 onwards. It's between 1.20 (GL2.x) and 1.30 (GL3.0) that there's a big break in the language.


On Thursday, May 21, 2015 at 6:41:04 AM UTC-4, Boon Hean Low wrote:
Hi everyone,

I saw that the GpuLanguage enum goes only up to GLSL 1.3, are there any plans to support anything higher? I'm using getGpuShaderText() to get the fragment shader snippets but its still using texture3D() which is deprecated in OpenGL 4.0 which I'm using now.

thanks
Boon


Support for OpenGL/GLSL > 2.0?

Boon Hean Low <boonhe...@...>
 

Hi everyone,

I saw that the GpuLanguage enum goes only up to GLSL 1.3, are there any plans to support anything higher? I'm using getGpuShaderText() to get the fragment shader snippets but its still using texture3D() which is deprecated in OpenGL 4.0 which I'm using now.

thanks
Boon


Re: multiple config file

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

Merging/hierarchical configs have been discussed in the past, but I suspect will not happen any time soon (it is a difficult problem to solve)

The best solution/alternative I am aware of is to generate your configs via a Python script. For example have a function which produces your base OCIO.Config object, then a function which does show-specific modifications and writes out a show-specific config

That way you have a single source for all your common colorspaces etc, while still preserving a self-contained config.ocio for each show

There is examples of creating configs from Python in the OpenColorIO-configs repository
- Ben

Sent from my phone

On 29 Apr 2015, at 12:30, lucien...@... wrote:

Hi guys,

How can I set up my pipeline so I have multiple config file building my color management profile.

The idea is to have config at facility level and then have show specific but that would add to the facility level config.

I hope that makes sense.

The bottleneck for me is the OCIO env is not a ':' seperated list of path but pointing to a file only.

Anyone has a workaround?

cheers

Lucien

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


multiple config file

lucien...@...
 

Hi guys,

How can I set up my pipeline so I have multiple config file building my color management profile.

The idea is to have config at facility level and then have show specific but that would add to the facility level config.

I hope that makes sense.

The bottleneck for me is the OCIO env is not a ':' seperated list of path but pointing to a file only.

Anyone has a workaround?

cheers

Lucien


Re: Review: added ociobuildicc app

Gerardo <gerard...@...>
 

Hello,

Just to say thanks and let you know that last versions of LittleCMS are able to perform color conversions in unbounded full floating point mode and generates ICC v4.3 profiles. latest LCMS version is 2.6/2.7
v4.3 profiles (including cLUT profiles) are able to work in unbounded FP domain, so results won't be clipped to 16-bpc.

Greetings,



Gerardo


 


Re: Python apply .cube ?

tre...@...
 

to answer my own question:
It seems I had the wrong idea about how the FileTransform worked.
From Configs/nuke-default/make.py :
create the colorspace, then appy using oiio.ImageBufAlgo.colorconvert

cs = OCIO.ColorSpace(name='sRGB')
cs.setDescription("Standard RGB Display Space")
cs.setBitDepth(OCIO.Constants.BIT_DEPTH_F32)
cs.setAllocation(OCIO.Constants.ALLOCATION_UNIFORM)
cs.setAllocationVars([RANGE[0], RANGE[1]])

t = OCIO.FileTransform('srgb.spi1d', interpolation=OCIO.Constants.INTERP_LINEAR)
cs.setTransform(t, OCIO.Constants.COLORSPACE_DIR_TO_REFERENCE)
config.addColorSpace(cs)


Python apply .cube ?

tre...@...
 

Please help!
I am trying to load in a file, resize it, apply a .cube LUT then write it out.
I have the following so far, but I'm falling over between the oiio > ocio parts (one using an oiio.ImgBuf and the other using a pixel array)
Have I missed something ? Is there an easier way to apply a .cube LUT to an image.
Thanks for any pointers !
Trevor

    #load in file & resize
        origBuffer = oiio.ImageBuf(aFile)
        resizeBuffer = oiio.ImageBuf(oiio.ImageSpec (1920, 972, 3, oiio.FLOAT))
        oiio.ImageBufAlgo.resize(resizeBuffer, origBuffer)

        config = OCIO.Config()

        transform = OCIO.FileTransform(src = self.LUT, interpolation = self.interpolation, direction = OCIO.Constants.TRANSFORM_DIR_FORWARD)
        processor = config.getProcessor(transform)

        pixels=self.inputNode.get_pixels()
        img = processor.applyRGBA(pixels)
    img.write(outputPath)


Pull request for custom transforms

Lukas Stockner <lukas.s...@...>
 

Hello,

I decided to implement the custom transform idea I posted earlier and send a pull request: https://github.com/imageworks/OpenColorIO/pull/390

The implementation is quite short and simple, it just exposes a class that new Transforms can inherit. By implementing all the functions, it can then be used just like regular transforms.
This is particularly useful for customizing a OCIO-based color pipeline, since own additions might be needed.
In my case, this functionality is required for implementing a tonemapping operator in Blender, which uses OCIO for its color management. Currently, the only two options are to either maintain a modified version of OCIO, or to implement it alongside OCIO before or after the Processor is called. With this change, it would be possible to implement the tonemapper as a Transform and directly use it in the DisplayTransform.

An example that shows how a custom transform looks like are these two files (header and source):
http://www.pasteall.org/56658
http://www.pasteall.org/56657

So, I hope that this feature will be accepted, and will of course fix any issues that might be present.

Best regards,
Lukas Stockner


Re: Precision of float values in config generated from Python

Dithermaster <dither...@...>
 

You need to print and later parse 8 digits to uniquely capture a float.

For those craving more information: https://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2/

///d@


On Fri, Jan 30, 2015 at 6:32 PM, Haarm-Pieter Duiker <li...@...> wrote:
Thanks for digging into this, and my apologies for missing the obvious limit of float precision. I was running into an issues where the limited precision is combined with high-intensity values to produce different results than the reference implementation. I've found a workaround though. More precision preserved throughout the process would still be appreciated.

HP




On Fri, Jan 30, 2015 at 3:53 AM, Kevin Wheatley <kevin.j....@...> wrote:
There are cases in the code where the precision of the formatting is
used to generate Cache Ids, changing the precision here would change
the behavior  there are also cases with luts where certain precision
limits are assumed, my conclusion would thus be getting to full float
precision should be doable, but with careful adjustments, in
particular there might not be enough test coverage to ensure
maintaining the behaviour exactly.

Going to double precision to go beyond a maximum of 9 digits is a
different matter, does it make a visible difference tot he images?

Kevin

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Re: Precision of float values in config generated from Python

Haarm-Pieter Duiker <li...@...>
 

Thanks for digging into this, and my apologies for missing the obvious limit of float precision. I was running into an issues where the limited precision is combined with high-intensity values to produce different results than the reference implementation. I've found a workaround though. More precision preserved throughout the process would still be appreciated.

HP




On Fri, Jan 30, 2015 at 3:53 AM, Kevin Wheatley <kevin.j....@...> wrote:
There are cases in the code where the precision of the formatting is
used to generate Cache Ids, changing the precision here would change
the behavior  there are also cases with luts where certain precision
limits are assumed, my conclusion would thus be getting to full float
precision should be doable, but with careful adjustments, in
particular there might not be enough test coverage to ensure
maintaining the behaviour exactly.

Going to double precision to go beyond a maximum of 9 digits is a
different matter, does it make a visible difference tot he images?

Kevin

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Re: Precision of float values in config generated from Python

Kevin Wheatley <kevin.j....@...>
 

There is also a bug in yaml-cpp which prevents this in
src/emitterstate.cpp it needs fixing to read:

bool EmitterState::SetFloatPrecision(int value, FMT_SCOPE scope)
{
if(value < 0 || value > (2 +
std::numeric_limits<float>::digits * 3010/10000))
return false;
_Set(m_floatPrecision, value, scope);
return true;
}

bool EmitterState::SetDoublePrecision(int value, FMT_SCOPE scope)
{
if(value < 0 || value > (2 +
std::numeric_limits<double>::digits * 3010/10000))
return false;
_Set(m_doublePrecision, value, scope);
return true;
}

Then in OCIO's code you need to add something like:

out.SetFloatPrecision(2 +
std::numeric_limits<float>::digits * 3010/10000);
out.SetDoublePrecision(2 +
std::numeric_limits<double>::digits * 3010/10000);

To the save function in OCIOYaml.cpp (near line 1664)

At least by that point ociocheck will read and write a config file
with more precision :-)

Kevin


Re: Precision of float values in config generated from Python

Kevin Wheatley <kevin.j....@...>
 

There are cases in the code where the precision of the formatting is
used to generate Cache Ids, changing the precision here would change
the behavior there are also cases with luts where certain precision
limits are assumed, my conclusion would thus be getting to full float
precision should be doable, but with careful adjustments, in
particular there might not be enough test coverage to ensure
maintaining the behaviour exactly.

Going to double precision to go beyond a maximum of 9 digits is a
different matter, does it make a visible difference tot he images?

Kevin


Re: Precision of float values in config generated from Python

Kevin Wheatley <kevin.j....@...>
 

On Fri, Jan 30, 2015 at 8:50 AM, Kevin Wheatley
<kevin.j....@...> wrote:
sounds like limits of float precision to me. that would mean being
'double' clean through the code,
looking through the code the matrix is stored as single precision
float and the bindings to python also assume as such, the image
processing also works as float, storing the matrix as doubles would be
possible, at the expense of some performance loss in processing
(speculation on my part :-). This assumes your python uses doubles
internally (likely the case).

Separate but related note:

there is some scattering of precision assumptions through the code
too, though these are mostly limited to output of files...

FLOAT_DECIMALS is set to 7 and there is a DOUBLE_DECIMALS used to
output things, however it should really be using something like:

2 + std::numeric_limits<Target>::digits * 3010/10000;

(or max_digits10() if we allow it)

Which would make the values in the code incorrect...

see http://www2.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1822.pdf
(or http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF)

However be aware there are 'limitations' on some platforms (MSVC 7.1
for instance) where you can not rely on round tripping of values in
their standard library (dinkumware).

I might see if I can knock up a patch for the output precision problems.

Kevin


Re: Precision of float values in config generated from Python

Kevin Wheatley <kevin.j....@...>
 

sounds like limits of float precision to me. that would mean being
'double' clean through the code,

Kevin


Precision of float values in config generated from Python

Haarm-Pieter Duiker <li...@...>
 

Hello,

Is there a way to configure the precision used for floating-point values stored in a config?

I have a Python script that generates a config based on a bunch of inputs, including a number of matrices that are declared in Python like so:

matrix = [0.6954522414, 0.1406786965, 0.1638690622,
                   0.0447945634, 0.8596711185, 0.0955343182,
                   -0.0055258826, 0.0040252103, 1.0015006723]

Matrices are added to a MatrixTransform through calls something like this:

ocio_transform = ocio.MatrixTransform()
ocio_transform.setMatrix(matrix)


We end up with a statement in the config that looks something like the following:

...
    to_reference: !<MatrixTransform> {matrix: [0.695452, 0.140679, 0.163869, 0, 0.0447946, 0.859671, 0.0955343, 0, -0.00552588, 0.00402521, 1.0015, 0, 0, 0, 0, 1]}
...

Ignore the padding from 3x3 to 4x4. The values in the config print with 6, 7 or 8 decimals. The input values had 10. 

Is there any way to preserve the precision of the original values? Would it be better to use the spimtx files to store these values?

Thanks in advance for your help,
HP





Re: ACES 1.0 released

Haarm-Pieter Duiker <li...@...>
 

Hi Steve,

These all seem like fair points. I'll take a look at this tomorrow and update the config. 

The questions around the linear range covered by ACEScc may need a bit more investigation. 

HP



On Wednesday, January 28, 2015, Steve Agland <sag...@...> wrote:
Hi HP,

I'm looking into rolling an internal project's OCIO configuration forward to use as much of your ACES 1.0 config as possible. I've run into a couple of issues and wanted to run them by you.

Firstly, the allocation for most of the linear spaces (including ACEScg, and our current working space "Linear - P3-D60") is currently defined as:

    allocation: uniform
    allocationvars: [0, 1]

This causes clipping of values > 1 when converting from the linear space into an Output Transform. It seems to only be a problem in certain OCIO implementations (I believe those using the GPU code path). In our case is was first noticed in RV. Changing these allocation settings to something like this seems to resolve the problem:

    allocation: lg2
    allocationvars: [-8.5, 5, .003]

I'm not sure if those values are optimal. Since it's only for interactive display it's probably fine. Using the lg2 allocation method seems to be the recommended approach for linear spaces.


The second issue I've run into is with experimenting with the ACEScc space for use in grading/DI.

We're using Nucoda. The current test workflow is I'm delivering ACEScc-encoded proxies of the final comps to DI, and supplying them with a couple of baked LUTs for display (ACEScc -> P3-DCI) and for a hypothetical future archive master (ACEScc -> ACES2065-1). This seems to work well for interactive grading and display with the few production images we've tested but I'm concerned about preserving as much information as possible in the final ACES master.

The ACEScc_to_ACES.spi1d LUT bundled with the config has a range of 0.0 - 1.0. I think this could be wider. (Also, should this file perhaps should be called ACEScc_to_ACESccLin.sp1 since it doesn't include the matrix transformation?).

The S-2014-003 document (Annex A, pp. 10) suggests that negative ACEScc values are to be expected - either from very dark linear values (< 7.25 stops below 18% middle grey), or from colors outside the AP1 gamut. At the other end, a value of 1.0 in ACEScc maps to ~223 in ACESccLin, but the spec suggests that the ACEScc -> ACESccLin conversion formula doesn't clip until you reach a linear value of 65504 (pp. 9). This seems to correspond to a value of about 1.468 in ACEScc. At the low end the curve seems to hit linear 0 at about -0.358.

It seems like these values ( -0.358, 1.468 ) might be a reasonable range to use in the ACEScc_to_ACESccLin LUT - perhaps with more samples - in order to preserve more information when transforming in and out of ACEScc.

To test this I generated my own alternative ACEScc_to_ACES.spi1d with that range and tried a back-and-forth conversion: ACES -> ACEScc -> ACES. It seems to better preserve very dark (esp. black) and very very bright values in the admittedly contrived syntheticChart.01.exr ACES test image. In practice maybe this isn't going to matter much but it seems like an opportunity for a little more accuracy for no extra cost.

That's all a long way of saying "can we change a few of these numbers?" :)  Let me know what you think.

Cheers

Steve


On 14 January 2015 at 05:53, Haarm-Pieter Duiker <li...@...> wrote:
Hello,

The ACES 1.0 Developer Release is officially available! Full product information can be found on the revamped website, http://www.oscars.org/aces. To give you a preview, the ACES 1.0 release includes the following components:
  • Core ACES color transformation implemented in the Color Transformation Language (CTL)
  • Documentation on the expected use of these transforms
  • Technical specifications for other ACES core components
  • Documentation for implementers and end users
  • Test images in a variety of color encodings and formats, demonstrating the results of applying core ACES transformations
  • An OpenColorIO (OCIO) configuration package for core ACES transforms
The components of the ACES release can be found here
    Thanks for your feedback on the needs of the ACES OCIO config in particular and the system in general.

    Please take a look at the source code, documentation, configs and let us know what you think. Send in feedback on this list, the ACES Google Group or the direct email ac...@... address.

    Thanks again for all the feedback. Please keep it coming.
    HP

    --
    You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
    For more options, visit https://groups.google.com/d/optout.

    --
    You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
    For more options, visit https://groups.google.com/d/optout.


    Re: ACES 1.0 released

    Steve Agland <sag...@...>
     

    Hi HP,

    I'm looking into rolling an internal project's OCIO configuration forward to use as much of your ACES 1.0 config as possible. I've run into a couple of issues and wanted to run them by you.

    Firstly, the allocation for most of the linear spaces (including ACEScg, and our current working space "Linear - P3-D60") is currently defined as:

        allocation: uniform
        allocationvars: [0, 1]

    This causes clipping of values > 1 when converting from the linear space into an Output Transform. It seems to only be a problem in certain OCIO implementations (I believe those using the GPU code path). In our case is was first noticed in RV. Changing these allocation settings to something like this seems to resolve the problem:

        allocation: lg2
        allocationvars: [-8.5, 5, .003]

    I'm not sure if those values are optimal. Since it's only for interactive display it's probably fine. Using the lg2 allocation method seems to be the recommended approach for linear spaces.


    The second issue I've run into is with experimenting with the ACEScc space for use in grading/DI.

    We're using Nucoda. The current test workflow is I'm delivering ACEScc-encoded proxies of the final comps to DI, and supplying them with a couple of baked LUTs for display (ACEScc -> P3-DCI) and for a hypothetical future archive master (ACEScc -> ACES2065-1). This seems to work well for interactive grading and display with the few production images we've tested but I'm concerned about preserving as much information as possible in the final ACES master.

    The ACEScc_to_ACES.spi1d LUT bundled with the config has a range of 0.0 - 1.0. I think this could be wider. (Also, should this file perhaps should be called ACEScc_to_ACESccLin.sp1 since it doesn't include the matrix transformation?).

    The S-2014-003 document (Annex A, pp. 10) suggests that negative ACEScc values are to be expected - either from very dark linear values (< 7.25 stops below 18% middle grey), or from colors outside the AP1 gamut. At the other end, a value of 1.0 in ACEScc maps to ~223 in ACESccLin, but the spec suggests that the ACEScc -> ACESccLin conversion formula doesn't clip until you reach a linear value of 65504 (pp. 9). This seems to correspond to a value of about 1.468 in ACEScc. At the low end the curve seems to hit linear 0 at about -0.358.

    It seems like these values ( -0.358, 1.468 ) might be a reasonable range to use in the ACEScc_to_ACESccLin LUT - perhaps with more samples - in order to preserve more information when transforming in and out of ACEScc.

    To test this I generated my own alternative ACEScc_to_ACES.spi1d with that range and tried a back-and-forth conversion: ACES -> ACEScc -> ACES. It seems to better preserve very dark (esp. black) and very very bright values in the admittedly contrived syntheticChart.01.exr ACES test image. In practice maybe this isn't going to matter much but it seems like an opportunity for a little more accuracy for no extra cost.

    That's all a long way of saying "can we change a few of these numbers?" :)  Let me know what you think.

    Cheers

    Steve


    On 14 January 2015 at 05:53, Haarm-Pieter Duiker <li...@...> wrote:
    Hello,

    The ACES 1.0 Developer Release is officially available! Full product information can be found on the revamped website, http://www.oscars.org/aces. To give you a preview, the ACES 1.0 release includes the following components:
    • Core ACES color transformation implemented in the Color Transformation Language (CTL)
    • Documentation on the expected use of these transforms
    • Technical specifications for other ACES core components
    • Documentation for implementers and end users
    • Test images in a variety of color encodings and formats, demonstrating the results of applying core ACES transformations
    • An OpenColorIO (OCIO) configuration package for core ACES transforms
    The components of the ACES release can be found here
      Thanks for your feedback on the needs of the ACES OCIO config in particular and the system in general.

      Please take a look at the source code, documentation, configs and let us know what you think. Send in feedback on this list, the ACES Google Group or the direct email ac...@... address.

      Thanks again for all the feedback. Please keep it coming.
      HP

      --
      You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
      For more options, visit https://groups.google.com/d/optout.

      821 - 840 of 2242