Date   

Problem in CDL implementation

Robert Minsk <Robert...@...>
 

According to the ASC-CDL standard "To maintain intended behavior of signs under exponentiation, we limit the Slope and Offset combined value to 0 to 1 (inclusive)..... out = Clamp((in*slope) + offset)^power." Internally OCIO implements the CDL transform by a ScaleOffsetOp (MatrixOp) followed by an ExponentOp followed by a SaturationOp (Matrix). The ExponentOp only clamps data less than zero and does not clamp data greater than one. The ExponentOp also has the behavior that if the exponent is one then no clamping is done (NoOp). The extended range of the ExponentOp in this case becomes a problem when the CDL saturation is not one.


How do address this problem with minimal disruption? How many pipelines depend on OCIO implementation of the CDL SOP returning extended range?


Adding some sort of strict compliance parameter to the CDLTransform would be pretty easy to implement.  We would either have to add a ClampTransform or add a parameter to the ExponentTransform to clamp.


How would we address adding a strict compliance parameter to .cc and .ccc files? FileTransforms already have a "cccid" parameter that is only used for .ccc files. It seems like we could get in trouble if we keep adding specialized parameters to the FileTransform. Could some sort of generic string->string dictionary parameter be added to FileTransform that would be passed to each of the readers? If OCIO adds a FileTransform plugin API in the future then the dictionary could be useful.

This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.


Yaml related warning message when compiling OCIO

etienne....@...
 

Hi,

I get a Yaml related warning message when building OCIO (branch: master 64adcad300adfd166280d2e7b1fb5c3ce7dca482)

I'm on CentOS 6.5, and here's my cmake log:

Python library: /usr/lib64/python2.6/config/libpython2.6.so

Create sphinx conf.py from conf.py.in

Copying doc to staging area

Copy extra doc files to staging area

Extracting .rst files from C++ headers

Create OpenColorABI.h from OpenColorABI.h.in

Setting OCIO SOVERSION to: 1

Setting OCIO SOVERSION to: 1

Create OpenColorIO.pc from OpenColorIO.pc.in

OIIO not found. Specify OIIO_PATH to locate it

Found OpenGL library /usr/lib64/libGLU.so;/usr/lib64/libGL.so;/usr/lib64/libSM.so;/usr/lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/libXext.so

Found OpenGL includes /usr/include

Found GLUT library /root/pipe_ready/utils/freeglut/2.8.1/lib/libglut.a;/root/pipe_ready/utils/libXmu/1.1.1/lib/libXmu.a;/root/pipe_ready/utils/libXi/1.6.2/lib/libXi.a

Found GLEW library /root/pipe_ready/utils/glew/1.10.0/lib/libGLEW.a

Found GLEW includes /root/pipe_ready/utils/glew/1.10.0/include

PYTHON_VARIANT_PATH: lib/python2.6/site-packages

Configuring done

Generating done


Here's the warning message:


[ 87%] Building CXX object src/core/CMakeFiles/OpenColorIO_STATIC.dir/OCIOYaml.cpp.o
In file included from /root/OpenColorIO-master/dist/ext/dist/include/yaml-cpp/emitter.h:10,
                 from /root/OpenColorIO-master/dist/ext/dist/include/yaml-cpp/yaml.h:9,
                 from /root/OpenColorIO-master/src/core/OCIOYaml.cpp:70:
/root/OpenColorIO-master/dist/ext/dist/include/yaml-cpp/binary.h: In constructor ‘YAML::Binary::Binary(const unsigned char*, size_t)’:
/root/OpenColorIO-master/dist/ext/dist/include/yaml-cpp/binary.h:21: warning: declaration of ‘size’ shadows a member of 'this'
/root/OpenColorIO-master/dist/ext/dist/include/yaml-cpp/binary.h:21: warning: declaration of ‘data’ shadows a member of 'this'
/root/OpenColorIO-master/src/core/OCIOYaml.cpp: In function ‘void OpenColorIO::v1::<unnamed>::save(YAML::Emitter&, const OpenColorIO::v1::Config*)’:
/root/OpenColorIO-master/src/core/OCIOYaml.cpp:1668: warning: comparison between signed and unsigned integer expressions
/root/OpenColorIO-master/src/core/OCIOYaml.cpp:1699: warning: comparison between signed and unsigned integer expressions
/root/OpenColorIO-master/src/core/OCIOYaml.cpp:1714: warning: comparison between signed and unsigned integer expressions
/root/OpenColorIO-master/src/core/OCIOYaml.cpp:1719: warning: comparison between signed and unsigned integer expressions
/root/OpenColorIO-master/src/core/OCIOYaml.cpp:1757: warning: comparison between signed and unsigned integer expressions
/root/OpenColorIO-master/src/core/OCIOYaml.cpp:1771: warning: comparison between signed and unsigned integer expressions
[ 87%] Building CXX object src/core/CMakeFiles/OpenColorIO_STATIC.dir/LookParse.cpp.o
...
[100%] Building CXX object src/apps/ociobakelut/CMakeFiles/ociobakelut.dir/ocioicc.cpp.o
Linking CXX executable ociobakelut
[100%] Built target ociobakelut


I'm wondering if I should be concerned with that message or just ignore it because as you can see the build completes.

Thanks in advance


displayCache and the active displays

Rod Bogart <bog...@...>
 

We notice that there is undesirable interaction between the new displayCache and the set of active displays.

Previously, it was reasonable to have displays which were not in the active list. However, in 1.0.9, the displayCache culls the list of displays, even when writing out a config.

So, given this config:
ocio_profile_version: 1

search_path: luts
strictparsing: true
luma: [0.2126, 0.7152, 0.0722]

description: Check for active displays bug

displays:
  AAA:
    - !<View> {name: Film, colorspace: lnf}
  BBB:
    - !<View> {name: Film, colorspace: lnf}
  CCC:
    - !<View> {name: Film, colorspace: lnf}

active_displays: [AAA, BBB]
active_views: [Film]

colorspaces:
  - !<ColorSpace>
    name: lnf
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Linear colorspace

      

    isdata: false
    allocation: lg2
    allocationvars: [-15, 6]

We can then run this python script to try to read it and write it. The result is that the getNumDisplays call only finds two displays, when there are three. The expectation would be for all three to be written to the new output config.
config = OCIO.GetCurrentConfig()

print(config.getNumDisplays())

fileHandle = open( "bugout.ocio", mode='w' )
fileHandle.write( config.serialize() )
fileHandle.close()


The resulting config looks like this:
ocio_profile_version: 1

search_path: luts
strictparsing: true
luma: [0.2126, 0.7152, 0.0722]

description: Check for active displays bug


roles:
  {}

displays:
  AAA:
    - !<View> {name: Film, colorspace: lnf}
  BBB:
    - !<View> {name: Film, colorspace: lnf}

active_displays: [AAA, BBB]
active_views: [Film]

colorspaces:
  - !<ColorSpace>
    name: lnf
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Linear colorspace

      

    isdata: false
    allocation: lg2
    allocationvars: [-15, 6]


Can we get clarity on the intent of the display cache, and how active displays is supposed to affect it (or not)?

Thanks,
RGB


Re: Reversed transform for a OCIO::DisplayTransform

Troy Sobotka <troy.s...@...>
 

On Apr 21, 2014 1:53 PM, "Dmitry Kazakov" <dimu...@...> wrote:

> But, speaking truly, I didn't fully understand what is 1D transform... is it some term? Could you give me a link to some info or documentation?

A 1D LUT is where a basic “input in” equals “input out.” It can only be used to adjust transfer curves, and is completely invertible.

A 3D LUT is required to adjust saturation intents. Here a single input value can shift values in other channels, and as Mr. Gritz succinctly outlined in the OIIO response, one value out may have more than one entry point, and therefore this is a typically non-invertible transform.

> 3) The color selectors are effectively simple gradients generated in HSV or HSL color spaces [0].

Note here the L or V is color space relative based on the resultant luminance (Y in XYZ) of your three primaries. So L will be different across spaces with different primaries and need to be calculated differently with different weights I believe.

> 2) Right now color selectors generate HSV using QColor object. The HSV color is first converted to RGB by Qt, we assume this color being sRGB, and then convert (using lcms2) into the color space of the image. That is if we have an image in scRGB color space, then the conversions chain is the following: HSV->sRGB->scRGB

This likely means an artist can never select the gamut range that sRGB cannot reach, yet is clearly within scRGB's gamut. This cripples the wider gamut space somewhat.

> 3) Later this color (in scRGB) is converted to the monitor profile in either way: using OCIO or lcms2 with converting it to the monitor profile (say, monitor_sRGB).

Not quite that simple I believe.

To do this with OCIO, you would need to craft a 3D LUT of your display's profile with a specific destination space, and snap it into the OCIO chain _before_ the sRGB values are transfer / TRC curved. Applying the transform on transfer / TRC curved values will give incorrect results.

So linear scRGB values could go to XYZ, then through the display profile 3D LUT to get to say sRGB, then apply the sRGB 1D transfer curve.

> Obviously, we should disable the lcms color management when using OCIO, because the latter one has it's own definition of the source colorspace [1].

And this would require a bit of artist know-how, as I cannot see a way to do it automatically.

> Probably, I should generate color from HSV not using sRGB, but somehow differently?

It should be possible to create a wheel that uses the primaries of scRGB (wider gamut) and select from that. The out of gamut values would effectively be rendered as an absolute colorimetric clipped version.

Little tricky to get the value selected on a reverse transform, however. Maybe keep an off-screen buffer of the untransformed source space color picker, pre-destination transform[1]? Mr. Selan?

> The reverse gamma and exposure would then be applied to the sRGB, right before it is converted to the image color space. I guess it is correct, isn't it?

The typical order for changing color spaces is:

A) Invert any TRC / transfer curve on a source space to get to linearized values.
B) Convert the RGB primaries to XYZ.
C) Convert the XYZ primaries to RGB of the destination. This can be combined with the matrix from B.
D) Apply the destination TRC / transfer curve.

Note that in B and C your white point _must_ be aligned via adaptation matrices on the RGB spaces. Bradford or CAT02, for example.

I apologize for chiming in here, but I thought I could at least hint at some potential issues.

With respect,
TJS

[1] Where a display profile is likely an irreversible 3D LUT in most instances. Not a concern if it is purely a matrix transform for primaries.


Re: Reversed transform for a OCIO::DisplayTransform

Dmitry Kazakov <dimu...@...>
 

Hi, Jeremy!

Thank you for clarifications about 3D-lut! I google'd for it and now I think I understand why the reverse transformation is not possible. But, speaking truly, I didn't fully understand what is 1D transform... is it some term? Could you give me a link to some info or documentation?

Well, I also did some refactoring to the Krita's code so I can state the problem a bit more clearly. I will try to explain the problem again more detailed, if you catch where I am wrong, please tell me:

Requirements:

1) We have an image that may have a arbitrary color space. For example, scRGB 16bit float, which is linear.
2) We also have color selectors, which are gui elements for choosing the color by the painter. Obviously, the chosen color should coincide with the one that produced when painted on the image.
3) The color selectors are effectively simple gradients generated in HSV or HSL color spaces [0].

Implementation:

1) We have image colorspace managed by lcms2
2) Right now color selectors generate HSV using QColor object. The HSV color is first converted to RGB by Qt, we assume this color being sRGB, and then convert (using lcms2) into the color space of the image. That is if we have an image in scRGB color space, then the conversions chain is the following: HSV->sRGB->scRGB
3) Later this color (in scRGB) is converted to the monitor profile in either way: using OCIO or lcms2 with converting it to the monitor profile (say, monitor_sRGB).

That means that the color goes through the following chains:

When we generate the color: HSV->sRGB->scRGB
When we display the color in image color space on the monitor using lcms2: scRGB->monitor_sRGB
When we display the color in image color space on the monitor using OCIO: scRGB->OCIO

Obviously, we should disable the lcms color management when using OCIO, because the latter one has it's own definition of the source colorspace [1].

So, this is what I have now. Such approach seems to be logical, but I'm not sure it is totally correct. If you see any issue in it (especially, in this HSV part), please tell me :) Probably, I should generate color from HSV not using sRGB, but somehow differently?

The next step for me would be to implement support for OCIO-based reverse exposure and gamma thing for the selectors themselves. I'm going to put it into the first conversion chain (which converts HSV to sRGB and then to the image color space). The reverse gamma and exposure would then be applied to the sRGB, right before it is converted to the image color space. I guess it is correct, isn't it?

If you are still reading this mail, thank you! :) I would really appreciate your comments and feedback :)


[0] - could anyone suggest me something to read about HSV/HSL color spaces? It seems lcms2 doesn't have built-in implementation of them so we should generate it somehow using Lab or something...
[1] - Am I right in this assumption? I guess, yes, but I'm not totally sure. How the OCIO-enabled software is expected to behave in the case?



On Sat, Apr 19, 2014 at 8:29 AM, Jeremy Selan <jeremy...@...> wrote:
Hi!

A bit more info to add to the conversation. Apologies for now chiming in sooner...

As folks have noted, in many real-world color configurations the viewing transform is includes a 3D-LUT in the chain. While 1-D LUTs, matrices, and a few other analytical operators in OCIO are automatically inverted, OCIO does not attempt to do auto-calculate the inverse of 3D-LUTs as this is non-trivial, often ambiguous (in the case of many -> one color mappings, and low-fidelity / error prone).

In the applications I've had a change to integrate with OCIO, this assumption (the non invertibility of the display transform) makes creating a color picker more challenging.  As others have noted, one implementation which avoids this issue is to not generate the pure color gradient in 'display-space', but instead to apply generate color ramps in some intermediate space, and then to apply the display transform to the color picker display itself.

This begs the question of what intermediate space to use for color ramp / color picker math. In our experience using linear tends not to work very well, but any modestly perceptually uniform space looks pretty good.  The critical part is that this intermediate space must be an invertible conversion away from linear (1D lots work great for this), and that 0.0 maps to black.   So you synthesize the gradient assuming its natively in this intermediate space.  apply the forwards 3d viewing transform for display, and then back project (which you can do as it's invertible) into scene-linear.

In spi profiles, this 'color picker' role is a 1d approximation of the viewing transform, except with black pinned at 0.0 in both color spaces to make sure hsv math works out.

Sorry if this is confusing! :)

-- Jeremy



On Tue, Apr 15, 2014 at 5:59 AM, Dmitry Kazakov <dimu...@...> wrote:
Hi, All!

Thank you for your replies! Now I understood that not every display transform is revertible :) So I will have to refactor our color selectors code to make it work with color proof'ed colors :(


On Sat, Apr 12, 2014 at 6:06 AM, bsloan <bsl...@...> wrote:
For most workflows that use a 3D LUT to render extended dynamic range images, it is not necessary to reverse the operation on the picked color. Your application should just look up the un-transformed pixel value from the image (not the displayed frame buffer), based on the selection position.

It would be *very* handy if your application would render the various color pickers and swatches through the OCIO display transform as well. Photoshop does not do this. 




On Friday, April 11, 2014 10:24:38 AM UTC-7, Dmitry Kazakov wrote:
Hi, all!

I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able not only to display a color on screen (which we do using DisplayTransform), but also to pick an already displayed color back into app (for usage in color selectors or for drag-and-dropped colors). So, effectively, I need to get a reversed transform for a DisplayTransform. But it seems to be explicitly prohibited (it throws an exception in the case). I'm wondering, is it possible to get a reversed transform for a DisplayTransform without reimplementing it completely using GroupTransform?

Thank you in advance!

[0] - krita.org

--
Dmitry Kazakov

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



--
Dmitry Kazakov

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



--
Dmitry Kazakov


Re: Reversed transform for a OCIO::DisplayTransform

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

Hi!

A bit more info to add to the conversation. Apologies for now chiming in sooner...

As folks have noted, in many real-world color configurations the viewing transform is includes a 3D-LUT in the chain. While 1-D LUTs, matrices, and a few other analytical operators in OCIO are automatically inverted, OCIO does not attempt to do auto-calculate the inverse of 3D-LUTs as this is non-trivial, often ambiguous (in the case of many -> one color mappings, and low-fidelity / error prone).

In the applications I've had a change to integrate with OCIO, this assumption (the non invertibility of the display transform) makes creating a color picker more challenging.  As others have noted, one implementation which avoids this issue is to not generate the pure color gradient in 'display-space', but instead to apply generate color ramps in some intermediate space, and then to apply the display transform to the color picker display itself.

This begs the question of what intermediate space to use for color ramp / color picker math. In our experience using linear tends not to work very well, but any modestly perceptually uniform space looks pretty good.  The critical part is that this intermediate space must be an invertible conversion away from linear (1D lots work great for this), and that 0.0 maps to black.   So you synthesize the gradient assuming its natively in this intermediate space.  apply the forwards 3d viewing transform for display, and then back project (which you can do as it's invertible) into scene-linear.

In spi profiles, this 'color picker' role is a 1d approximation of the viewing transform, except with black pinned at 0.0 in both color spaces to make sure hsv math works out.

Sorry if this is confusing! :)

-- Jeremy



On Tue, Apr 15, 2014 at 5:59 AM, Dmitry Kazakov <dimu...@...> wrote:
Hi, All!

Thank you for your replies! Now I understood that not every display transform is revertible :) So I will have to refactor our color selectors code to make it work with color proof'ed colors :(


On Sat, Apr 12, 2014 at 6:06 AM, bsloan <bsl...@...> wrote:
For most workflows that use a 3D LUT to render extended dynamic range images, it is not necessary to reverse the operation on the picked color. Your application should just look up the un-transformed pixel value from the image (not the displayed frame buffer), based on the selection position.

It would be *very* handy if your application would render the various color pickers and swatches through the OCIO display transform as well. Photoshop does not do this. 




On Friday, April 11, 2014 10:24:38 AM UTC-7, Dmitry Kazakov wrote:
Hi, all!

I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able not only to display a color on screen (which we do using DisplayTransform), but also to pick an already displayed color back into app (for usage in color selectors or for drag-and-dropped colors). So, effectively, I need to get a reversed transform for a DisplayTransform. But it seems to be explicitly prohibited (it throws an exception in the case). I'm wondering, is it possible to get a reversed transform for a DisplayTransform without reimplementing it completely using GroupTransform?

Thank you in advance!

[0] - krita.org

--
Dmitry Kazakov

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



--
Dmitry Kazakov

--
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: Reversed transform for a OCIO::DisplayTransform

Dmitry Kazakov <dimu...@...>
 

Hi, All!

Thank you for your replies! Now I understood that not every display transform is revertible :) So I will have to refactor our color selectors code to make it work with color proof'ed colors :(


On Sat, Apr 12, 2014 at 6:06 AM, bsloan <bsl...@...> wrote:
For most workflows that use a 3D LUT to render extended dynamic range images, it is not necessary to reverse the operation on the picked color. Your application should just look up the un-transformed pixel value from the image (not the displayed frame buffer), based on the selection position.

It would be *very* handy if your application would render the various color pickers and swatches through the OCIO display transform as well. Photoshop does not do this. 




On Friday, April 11, 2014 10:24:38 AM UTC-7, Dmitry Kazakov wrote:
Hi, all!

I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able not only to display a color on screen (which we do using DisplayTransform), but also to pick an already displayed color back into app (for usage in color selectors or for drag-and-dropped colors). So, effectively, I need to get a reversed transform for a DisplayTransform. But it seems to be explicitly prohibited (it throws an exception in the case). I'm wondering, is it possible to get a reversed transform for a DisplayTransform without reimplementing it completely using GroupTransform?

Thank you in advance!

[0] - krita.org

--
Dmitry Kazakov

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



--
Dmitry Kazakov


Re: Reversed transform for a OCIO::DisplayTransform

bsloan <bsl...@...>
 

For most workflows that use a 3D LUT to render extended dynamic range images, it is not necessary to reverse the operation on the picked color. Your application should just look up the un-transformed pixel value from the image (not the displayed frame buffer), based on the selection position.

It would be *very* handy if your application would render the various color pickers and swatches through the OCIO display transform as well. Photoshop does not do this. 



On Friday, April 11, 2014 10:24:38 AM UTC-7, Dmitry Kazakov wrote:
Hi, all!

I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able not only to display a color on screen (which we do using DisplayTransform), but also to pick an already displayed color back into app (for usage in color selectors or for drag-and-dropped colors). So, effectively, I need to get a reversed transform for a DisplayTransform. But it seems to be explicitly prohibited (it throws an exception in the case). I'm wondering, is it possible to get a reversed transform for a DisplayTransform without reimplementing it completely using GroupTransform?

Thank you in advance!

[0] - krita.org

--
Dmitry Kazakov


Re: Reversed transform for a OCIO::DisplayTransform

Joseph Slomka <joseph...@...>
 

Remember that colorspaces can be defined to and from the reference. You can manually define the inverse and come up with an inverse 3d lut for the color picker that is close enough to fully inverted.

I don't believe that OCIO inverts any 3d luts, even if you had a unity lut where rgb in = rgb out.

Typically the design of OCIO does not automatically do anything that will get you into trouble. You have to deliberately make those choices. 


Example code below.

-Joseph

cs = OCIO.ColorSpace(family='kodak',name='kdk2383')
cs.setDescription("kdk2383: Kodak Vision stock")
cs.setBitDepth(OCIO.Constants.BIT_DEPTH_UINT10)

# this sets the conversion to reference XYZ from film log
groupTransform = OCIO.GroupTransform()
groupTransform.push_back(OCIO.FileTransform('2383_to_bt1886.3dl',interpolation=OCIO.Constants.INTERP_LINEAR))
groupTransform.push_back(OCIO.ColorSpaceTransform(src='bt1886', dst='lxyz'))
cs.setTransform(groupTransform, OCIO.Constants.COLORSPACE_DIR_TO_REFERENCE)
config.addColorSpace(cs)

# this sets the conversion from reference XYZ to film log values
groupTransform = OCIO.GroupTransform()
groupTransform.push_back(OCIO.ColorSpaceTransform(src='lxyz', dst='bt1886'))
groupTransform.push_back(OCIO.FileTransform('bt1886_to_2383.3dl',interpolation=OCIO.Constants.INTERP_LINEAR))
cs.setTransform(groupTransform, OCIO.Constants.COLORSPACE_DIR_FROM_REFERENCE)
config.addColorSpace(cs)


On Fri, Apr 11, 2014 at 4:29 PM, Kevin Wheatley <kevin.j....@...> wrote:
As Piotr points out this is in general not mathematically possible, in particular if any LUTs are not invertible, you'll not be able to do this. in a 1D sense imagine if you have a curve which has a turning point which results in there being multiple cases where two values of x give y having the same value, when generalised into a 3D LUT this problem becomes even more difficult to invert in a general sense even in typical outputs this is not necessarily going to give you predictable outcomes (typical for a display transform emulating another device/output especially a subtractive one like film prints or other CMY(K) outputs). These 3D luts often feature gamut compression which is where a lot of the loss comes from.

In specific cases there can be techniques to invert, but these need hand selecting, which is probably why OCIO won't do it, something like Argyll CMS or another ICC profile tool might do something for you, which might be interesting to implement, alternatively the CTL code has a scattered data interpolation code that might work.

Kevin


On Fri, Apr 11, 2014 at 10:29 PM, Piotr Stanczyk <piotr.s...@...> wrote:
From what I remember, you can do this if the transforms are analytical. If you are referring to a baked in file based one then you will have to provide your own from for that. 

Piotr




On 11 April 2014 10:24, Dmitry Kazakov <dimu...@...> wrote:
Hi, all!

I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able not only to display a color on screen (which we do using DisplayTransform), but also to pick an already displayed color back into app (for usage in color selectors or for drag-and-dropped colors). So, effectively, I need to get a reversed transform for a DisplayTransform. But it seems to be explicitly prohibited (it throws an exception in the case). I'm wondering, is it possible to get a reversed transform for a DisplayTransform without reimplementing it completely using GroupTransform?

Thank you in advance!

[0] - krita.org

--
Dmitry Kazakov

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

--
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: Reversed transform for a OCIO::DisplayTransform

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

As Piotr points out this is in general not mathematically possible, in particular if any LUTs are not invertible, you'll not be able to do this. in a 1D sense imagine if you have a curve which has a turning point which results in there being multiple cases where two values of x give y having the same value, when generalised into a 3D LUT this problem becomes even more difficult to invert in a general sense even in typical outputs this is not necessarily going to give you predictable outcomes (typical for a display transform emulating another device/output especially a subtractive one like film prints or other CMY(K) outputs). These 3D luts often feature gamut compression which is where a lot of the loss comes from.

In specific cases there can be techniques to invert, but these need hand selecting, which is probably why OCIO won't do it, something like Argyll CMS or another ICC profile tool might do something for you, which might be interesting to implement, alternatively the CTL code has a scattered data interpolation code that might work.

Kevin


On Fri, Apr 11, 2014 at 10:29 PM, Piotr Stanczyk <piotr.s...@...> wrote:
From what I remember, you can do this if the transforms are analytical. If you are referring to a baked in file based one then you will have to provide your own from for that. 

Piotr




On 11 April 2014 10:24, Dmitry Kazakov <dimu...@...> wrote:
Hi, all!

I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able not only to display a color on screen (which we do using DisplayTransform), but also to pick an already displayed color back into app (for usage in color selectors or for drag-and-dropped colors). So, effectively, I need to get a reversed transform for a DisplayTransform. But it seems to be explicitly prohibited (it throws an exception in the case). I'm wondering, is it possible to get a reversed transform for a DisplayTransform without reimplementing it completely using GroupTransform?

Thank you in advance!

[0] - krita.org

--
Dmitry Kazakov

--
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: Reversed transform for a OCIO::DisplayTransform

Piotr Stanczyk <piotr.s...@...>
 

From what I remember, you can do this if the transforms are analytical. If you are referring to a baked in file based one then you will have to provide your own from for that. 

Piotr




On 11 April 2014 10:24, Dmitry Kazakov <dimu...@...> wrote:
Hi, all!

I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able not only to display a color on screen (which we do using DisplayTransform), but also to pick an already displayed color back into app (for usage in color selectors or for drag-and-dropped colors). So, effectively, I need to get a reversed transform for a DisplayTransform. But it seems to be explicitly prohibited (it throws an exception in the case). I'm wondering, is it possible to get a reversed transform for a DisplayTransform without reimplementing it completely using GroupTransform?

Thank you in advance!

[0] - krita.org

--
Dmitry Kazakov

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


Reversed transform for a OCIO::DisplayTransform

Dmitry Kazakov <dimu...@...>
 

Hi, all!

I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able not only to display a color on screen (which we do using DisplayTransform), but also to pick an already displayed color back into app (for usage in color selectors or for drag-and-dropped colors). So, effectively, I need to get a reversed transform for a DisplayTransform. But it seems to be explicitly prohibited (it throws an exception in the case). I'm wondering, is it possible to get a reversed transform for a DisplayTransform without reimplementing it completely using GroupTransform?

Thank you in advance!

[0] - krita.org

--
Dmitry Kazakov


Uses of OCIO Looks?

Rod Bogart <bog...@...>
 

If you are using Looks heavily (and successfully), I’d like to hear from you.

Currently, the documentation is somewhat inaccurate on the format of the definition and usage of Looks, so I’m wondering to what degree folks have taken advantage of them.

They seem to be a great way to build pipelines with intentional steps (i.e. separate operations for Neutral Grades and Primary Grades followed by an overall Show Look). The specification of process_space is super helpful to allow LUTs to operate on the kind of data they expect. And they can be applied with +/- to allow specific inversion setups. So, that’s all good.

Any info you can share would be appreciated: positive results, hassles, example configs, whatever.

Thanks in advance,
RGB


Re: Allow config's context to be replaced?

Nathan Rusch <natha...@...>
 

Ah cool, that could be quite handy.

Just for posterity, the biggest problem with trying to take a dynamic approach in Nuke is timing. Ideally, when a user opens a script, one would be able to look at the incoming script path, decide what config they need, load it into the process environment, and then proceed to load the script. However, because the `onScriptLoad` callback currently runs after all of the nodes being loaded from the script have been created, swapping out the config will screw up any saved knob values on config-dependent OCIO nodes.

I've requested the current callback be broken into beforeScriptLoad and afterScriptLoad callbacks, but I'm not very optimistic about a change like that ever being implemented. It's possible to handle most of the cases where switching is required by monkey-patching nuke.scriptOpen with your own function and handling things in there, but in the end, the $OCIO environment variable is the only foolproof way to go.


-Nathan


On Thursday, February 6, 2014 7:21:45 PM UTC-8, Jeremy Selan wrote:
Cool.

In the medium term, we hope to do a cleanup of the OCIO API to make it
easy to install as a system library in a binary compatible manner.
That way, should similar circumstances arise again you could just load
the latest OCIO on your system and then move the library that ships
with the commercial app out of the way.

If memory serves, Mari ships with a recent OpenColorIO.so, so if you
have an install of that it would probably work to copy the .so from
Mari into the Nuke install.

-- Jeremy

On Thu, Feb 6, 2014 at 6:24 PM, Nathan Rusch <nath...@...> wrote:
> Foundry bug ID is 40576 in case anyone comes across this later and wants to
> poke them about it.
>
>
>
> On Thursday, February 6, 2014 9:54:26 AM UTC-8, Nathan Rusch wrote:
>>
>> Thanks Jeremy. Good to know I'm not missing something.
>>
>> Unfortunately The Foundry have a tendency to drag their feet when it comes
>> to updating third-party libraries, so they're still shipping OCIO 1.0.7
>> (even in Nuke 8... a little disappointing). I've got a request in with them,
>> and I'll throw the reference number in this thread once I get one back in
>> case anyone else wants to help apply more pressure. Tweak also seem to be
>> using 1.0.7 in RV 4 as well.
>>
>> Anyway, 1.0.7 doesn't provide a Config.addEnvironmentVar method, so it
>> looks like I may be stuck with replacing the config outright or swapping out
>> the OCIO libraries that ship with Nuke. I'll hold out hope for the future
>> though...
>>
>> Thanks again for the info.
>>
>>
>> -Nathan
>>
>>
>> On Wednesday, February 5, 2014 9:44:01 PM UTC-8, Jeremy Selan wrote:
>>>
>>> It was definitely our intent to have a setCurrentContext, that looks
>>> like an oversight.
>>>
>>> In the meantime, can you see if your config object has a
>>> "addEnvironmentVar" option?  This was introduced rather recently, so I
>>> am not sure if it's available in Nuke, but this would allow you to
>>> modify value of existing entries in the context, and also add new
>>> ones).
>>>
>>> -- Jeremy
>>>
>>> On Wed, Feb 5, 2014 at 4:06 PM, Nathan Rusch <nath...@...> wrote:
>>> > Hey all,
>>> >
>>> > I'm wondering if there has been any thought or discussion internally
>>> > about
>>> > allowing a config's Context to be replaced in place. I've been looking
>>> > at
>>> > ways to change the context variables of the active config on the fly
>>> > using
>>> > the Python bindings, and actually having them affect the existing
>>> > processing
>>> > environment, but after perusing the library and binding sources, it
>>> > seems
>>> > there isn't any way to do this currently.
>>> >
>>> > Some of the machinery is already there: You can get an editable copy of
>>> > the
>>> > active config's current context and modify its context variables to
>>> > your
>>> > heart's content. However, at that point, there isn't really anything
>>> > useful
>>> > you can do with that object unless you're actually doing color
>>> > processing
>>> > yourself. I was hoping to find a way to inject the updated context back
>>> > into
>>> > the currently active config via Python, to affect all future processor
>>> > lookups within Nuke, but there's a distinct lack of symmetry to the
>>> > interface in that regard.
>>> >
>>> > What I'm hoping for:
>>> >
>>> > config = ocio.GetCurrentConfig()
>>> > ctx = config.getCurrentContext().createEditableCopy()
>>> > ctx.setStringVar('FOO', 'BAR')
>>> > config.setCurrentContext(ctx)  # <-- The missing link
>>> >
>>> > Unless I'm mistaken, the only way to do something like this right now
>>> > (at
>>> > either the C++ or Python level) would be to modify the process
>>> > environment
>>> > (not ideal), and then call
>>> > ocio.SetCurrentConfig(ocio.Config.CreateFromEnv()), which feels...
>>> > dirty.
>>> >
>>> > Now, I'm guessing this isn't the first time you've crossed paths with
>>> > an
>>> > idea like this, so I feel like it's worth asking: Am I overlooking
>>> > something
>>> > blatantly obvious here? I've done my best to sniff out any existing
>>> > functionality like this, but haven't found anything. However, if this
>>> > is in
>>> > fact a nonexistent feature, I'm wondering if there is a specific reason
>>> > for
>>> > excluding it, and if you would be willing to consider adding it in the
>>> > future.
>>> >
>>> > Thanks for any information,
>>> >
>>> > -Nathan
>>> >
>>> > P.S. In the case of Nuke, I know it's possible to work around this
>>> > using
>>> > node-level context overrides and making Nuke do the environment lookups
>>> > for
>>> > you using TCL, but that's far from an ideal solution when a simple
>>> > context
>>> > replacement would let me do the same thing much more cleanly (and
>>> > doesn't
>>> > address other applications).
>>> >
>>> > --
>>> > 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-d...@....
>>> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


Re: OSX 10.9 compile expectations?

Rod Bogart <bog...@...>
 

Agreed.  I inserted unistd.h above the #elif, and it compiles fine on 10.9.

RGB

On Feb 9, 2014, at 5:23 PM, Colin Doncaster <colin.d...@...> wrote:

It looks like PathUtils.cpp needs unistd.h included.  

Looking at the source there’s:

#if defined(__APPLE__) && !defined(__IPHONE__)
#include <crt_externs.h> // _NSGetEnviron()
#elif !defined(WINDOWS)
#include <unistd.h>
extern char **environ;
#endif

so I’m not too sure how one would want to rework those conditionals. 

Mavericks headers are closer to Linux now, there’s a few projects I’ve rebuilt now that require the __APPLE__ defines to compile. 

Cheers

On Feb 8, 2014, at 6:14 PM, Rod Bogart <bog...@...> wrote:

Do we expect 10.9 to properly compile the git master version of OpenColorIO?

Steps to reproduce:
   “Clone in Desktop” to download software
   Cmake (with defaults) to populate build dir
   cd build
   make
[ 38%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/ParseUtils.cpp.o
[ 39%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/PathUtils.cpp.o
/Users/ocio/OpenColorIO/src/core/PathUtils.cpp:154:15: error: 
      no member named 'getcwd' in the global namespace
            ::getcwd(path, MAXPATHLEN);
            ~~^
1 error generated.

Will continue to debug, but thought I’d ask if someone has been here first…

RGB

--
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/groups/opt_out.


--
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/groups/opt_out.


Re: OSX 10.9 compile expectations?

Colin Doncaster <colin.d...@...>
 

It looks like PathUtils.cpp needs unistd.h included.  

Looking at the source there’s:

#if defined(__APPLE__) && !defined(__IPHONE__)
#include <crt_externs.h> // _NSGetEnviron()
#elif !defined(WINDOWS)
#include <unistd.h>
extern char **environ;
#endif

so I’m not too sure how one would want to rework those conditionals. 

Mavericks headers are closer to Linux now, there’s a few projects I’ve rebuilt now that require the __APPLE__ defines to compile. 

Cheers

On Feb 8, 2014, at 6:14 PM, Rod Bogart <bog...@...> wrote:

Do we expect 10.9 to properly compile the git master version of OpenColorIO?

Steps to reproduce:
   “Clone in Desktop” to download software
   Cmake (with defaults) to populate build dir
   cd build
   make
[ 38%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/ParseUtils.cpp.o
[ 39%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/PathUtils.cpp.o
/Users/ocio/OpenColorIO/src/core/PathUtils.cpp:154:15: error: 
      no member named 'getcwd' in the global namespace
            ::getcwd(path, MAXPATHLEN);
            ~~^
1 error generated.

Will continue to debug, but thought I’d ask if someone has been here first…

RGB

--
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/groups/opt_out.


Re: Digest for ocio...@googlegroups.com - 3 Messages in 1 Topic

Joseph Goldstone <jgold...@...>
 


On Feb 9, 2014, at 12:43 PM, <ocio...@...> <ocio...@...> wrote:


No, but 338 does:


Rod, if you can have a go at this, it would be much appreciated; I’ve lived in a Mac monoculture for so long that I have no clue how to produce modern portable headers.

—joseph


Re: OSX 10.9 compile expectations?

Rod Bogart <bog...@...>
 

Thanks.

Yes, it is the master branch. I have not yet spent time on the fix, but I believe you are correct; it should just be headers.

RGB

On Feb 8, 2014, at 4:46 PM, Jeremy Selan <jeremy...@...> wrote:

I haven't yet updated by OSX dev machine to 10.9 yet, so unfortunately
I can't test this at home. (Sounds like a good weekend project
though).

When I browse the open issues list,
https://github.com/imageworks/OpenColorIO/issues?state=open

there is a topic for compiliation problems on 10.9,
https://github.com/imageworks/OpenColorIO/issues/340

but it doesn't mention getcwd.

I'm not sure how you did the git checkout, but can you confirm if
you're on master or instead the tagged 1.0.9 release? The sha for
master is 63c6bde2, the sha for 1.0.9 is 2b12063e22

We'd very much welcome a patch if you'd like to take a stab at getting
this working. (probably a simple header fix?) :)

-- Jeremy

On Sat, Feb 8, 2014 at 3:14 PM, Rod Bogart <bog...@...> wrote:
Do we expect 10.9 to properly compile the git master version of OpenColorIO?

Steps to reproduce:
"Clone in Desktop" to download software
Cmake (with defaults) to populate build dir
cd build
make
[ 38%] Building CXX object
src/core/CMakeFiles/OpenColorIO.dir/ParseUtils.cpp.o
[ 39%] Building CXX object
src/core/CMakeFiles/OpenColorIO.dir/PathUtils.cpp.o
/Users/ocio/OpenColorIO/src/core/PathUtils.cpp:154:15: error:
no member named 'getcwd' in the global namespace
::getcwd(path, MAXPATHLEN);
~~^
1 error generated.

Will continue to debug, but thought I'd ask if someone has been here first...

RGB

--
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/groups/opt_out.
--
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/groups/opt_out.


Re: OSX 10.9 compile expectations?

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

I haven't yet updated by OSX dev machine to 10.9 yet, so unfortunately
I can't test this at home. (Sounds like a good weekend project
though).

When I browse the open issues list,
https://github.com/imageworks/OpenColorIO/issues?state=open

there is a topic for compiliation problems on 10.9,
https://github.com/imageworks/OpenColorIO/issues/340

but it doesn't mention getcwd.

I'm not sure how you did the git checkout, but can you confirm if
you're on master or instead the tagged 1.0.9 release? The sha for
master is 63c6bde2, the sha for 1.0.9 is 2b12063e22

We'd very much welcome a patch if you'd like to take a stab at getting
this working. (probably a simple header fix?) :)

-- Jeremy

On Sat, Feb 8, 2014 at 3:14 PM, Rod Bogart <bog...@...> wrote:
Do we expect 10.9 to properly compile the git master version of OpenColorIO?

Steps to reproduce:
"Clone in Desktop" to download software
Cmake (with defaults) to populate build dir
cd build
make
[ 38%] Building CXX object
src/core/CMakeFiles/OpenColorIO.dir/ParseUtils.cpp.o
[ 39%] Building CXX object
src/core/CMakeFiles/OpenColorIO.dir/PathUtils.cpp.o
/Users/ocio/OpenColorIO/src/core/PathUtils.cpp:154:15: error:
no member named 'getcwd' in the global namespace
::getcwd(path, MAXPATHLEN);
~~^
1 error generated.

Will continue to debug, but thought I'd ask if someone has been here first...

RGB

--
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/groups/opt_out.


OSX 10.9 compile expectations?

Rod Bogart <bog...@...>
 

Do we expect 10.9 to properly compile the git master version of OpenColorIO?

Steps to reproduce:
   “Clone in Desktop” to download software
   Cmake (with defaults) to populate build dir
   cd build
   make
[ 38%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/ParseUtils.cpp.o
[ 39%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/PathUtils.cpp.o
/Users/ocio/OpenColorIO/src/core/PathUtils.cpp:154:15: error: 
      no member named 'getcwd' in the global namespace
            ::getcwd(path, MAXPATHLEN);
            ~~^
1 error generated.

Will continue to debug, but thought I’d ask if someone has been here first…

RGB

901 - 920 of 2209