Date   

Re: Building "universal" binaries for MacOS

Andrea Mantler <man...@...>
 

Trying this method, and not using the flag -DCMAKE_OSX_ARCHITECTURES=x86_64;i386 compiled (etc) with no errors, however, when I look at the .a and .dylib files using lipo -info, I get:
    Non-fat file: <filename> is architecture: x86_64
(So this didn't work either.)


On Wednesday, May 28, 2014 1:01:55 PM UTC-5, rmi...@... wrote:
I am working on a patch right now but it looks like you may be able to use CMAKE_TOOLCHAIN_FILE in the meantime.  You would make a file Toolchain-osx-fat.cmake with:
SET(CMAKE_OSX_ARCHITECTURES x86_64 i386)

Then use the flag -DCMAKE_TOOLCHAIN_FILE=<path to file>/Toolchain-osx-fat.cmake where <path to file> is the full path to Toolchain-osx-fat.cmake

I am currently not in a position to test this.  Please tell me if it works.

On Monday, May 26, 2014 2:12:58 PM UTC-7, Andrea Mantler wrote:
I would like to build fat binaries with x86_64 and i386 architecture support.  I've tried passing the flag
    -DCMAKE_OSX_ARCHITECTURES=x86_64;i386
to cmake, but it appears that flag isn't being carried down to the building of libtinyxml.a and libyaml-cpp.a:

    ld: warning: in ../../ext/dist/lib/libtinyxml.a, file was built for unsupported file format which is not the architecture being linked (i386)
    ld: warning: in ../../ext/dist/lib/libyaml-cpp.a, file was built for unsupported file format which is not the architecture being linked (i386)

(Note:  I get the same errors if I try to build for just i386.)

Does anyone have any suggestions for what I can try?  Thanks! 


Re: Building "universal" binaries for MacOS

Andrea Mantler <man...@...>
 

It didn't work, same error message.  :(


On Wednesday, May 28, 2014 1:27:29 PM UTC-5, rmi...@... wrote:
I have created a new CMakeLists.txt file but I currently do not have a way to test it.  If someone could please test the CMakeOSXArch branch on the rminsk/OpenColorIO repository (git clone -b CMakeOSXArch https://github.com/rminsk/OpenColorIO.git).

Thanks

On Monday, May 26, 2014 2:12:58 PM UTC-7, Andrea Mantler wrote:
I would like to build fat binaries with x86_64 and i386 architecture support.  I've tried passing the flag
    -DCMAKE_OSX_ARCHITECTURES=x86_64;i386
to cmake, but it appears that flag isn't being carried down to the building of libtinyxml.a and libyaml-cpp.a:

    ld: warning: in ../../ext/dist/lib/libtinyxml.a, file was built for unsupported file format which is not the architecture being linked (i386)
    ld: warning: in ../../ext/dist/lib/libyaml-cpp.a, file was built for unsupported file format which is not the architecture being linked (i386)

(Note:  I get the same errors if I try to build for just i386.)

Does anyone have any suggestions for what I can try?  Thanks! 


Re: Building "universal" binaries for MacOS

Andrea Mantler <man...@...>
 

Thanks!  I'll give this a try!


On Wednesday, May 28, 2014 1:27:29 PM UTC-5, rmi...@... wrote:
I have created a new CMakeLists.txt file but I currently do not have a way to test it.  If someone could please test the CMakeOSXArch branch on the rminsk/OpenColorIO repository (git clone -b CMakeOSXArch https://github.com/rminsk/OpenColorIO.git).

Thanks

On Monday, May 26, 2014 2:12:58 PM UTC-7, Andrea Mantler wrote:
I would like to build fat binaries with x86_64 and i386 architecture support.  I've tried passing the flag
    -DCMAKE_OSX_ARCHITECTURES=x86_64;i386
to cmake, but it appears that flag isn't being carried down to the building of libtinyxml.a and libyaml-cpp.a:

    ld: warning: in ../../ext/dist/lib/libtinyxml.a, file was built for unsupported file format which is not the architecture being linked (i386)
    ld: warning: in ../../ext/dist/lib/libyaml-cpp.a, file was built for unsupported file format which is not the architecture being linked (i386)

(Note:  I get the same errors if I try to build for just i386.)

Does anyone have any suggestions for what I can try?  Thanks! 


Re: Building "universal" binaries for MacOS

rmi...@...
 

I have created a new CMakeLists.txt file but I currently do not have a way to test it.  If someone could please test the CMakeOSXArch branch on the rminsk/OpenColorIO repository (git clone -b CMakeOSXArch https://github.com/rminsk/OpenColorIO.git).

Thanks


On Monday, May 26, 2014 2:12:58 PM UTC-7, Andrea Mantler wrote:
I would like to build fat binaries with x86_64 and i386 architecture support.  I've tried passing the flag
    -DCMAKE_OSX_ARCHITECTURES=x86_64;i386
to cmake, but it appears that flag isn't being carried down to the building of libtinyxml.a and libyaml-cpp.a:

    ld: warning: in ../../ext/dist/lib/libtinyxml.a, file was built for unsupported file format which is not the architecture being linked (i386)
    ld: warning: in ../../ext/dist/lib/libyaml-cpp.a, file was built for unsupported file format which is not the architecture being linked (i386)

(Note:  I get the same errors if I try to build for just i386.)

Does anyone have any suggestions for what I can try?  Thanks! 


Re: Building "universal" binaries for MacOS

rmi...@...
 

I am working on a patch right now but it looks like you may be able to use CMAKE_TOOLCHAIN_FILE in the meantime.  You would make a file Toolchain-osx-fat.cmake with:
SET(CMAKE_OSX_ARCHITECTURES x86_64 i386)

Then use the flag -DCMAKE_TOOLCHAIN_FILE=<path to file>/Toolchain-osx-fat.cmake where <path to file> is the full path to Toolchain-osx-fat.cmake

I am currently not in a position to test this.  Please tell me if it works.


On Monday, May 26, 2014 2:12:58 PM UTC-7, Andrea Mantler wrote:
I would like to build fat binaries with x86_64 and i386 architecture support.  I've tried passing the flag
    -DCMAKE_OSX_ARCHITECTURES=x86_64;i386
to cmake, but it appears that flag isn't being carried down to the building of libtinyxml.a and libyaml-cpp.a:

    ld: warning: in ../../ext/dist/lib/libtinyxml.a, file was built for unsupported file format which is not the architecture being linked (i386)
    ld: warning: in ../../ext/dist/lib/libyaml-cpp.a, file was built for unsupported file format which is not the architecture being linked (i386)

(Note:  I get the same errors if I try to build for just i386.)

Does anyone have any suggestions for what I can try?  Thanks! 


Re: Problem in CDL implementation

rmi...@...
 

I agree that the default behavior for the CDLTransform should not change.  It would most likely break some facilities color pipelines if we did change the default.  Many other tools do implement CDL that conform to the specification and we need a way to support that also.


On Friday, May 23, 2014 10:52:57 AM UTC-7, Joe wrote:
Robert,

Although we can conform to anything For our on-set tools we have made a match to how Nuke's OCIOCDLTransform node works.  This made the most sense because our main goal with CDL is to allow VFX facilities to match the look the cinematographers dials for dailies.  Additionally the ACES workflow does not clamp values above 1.0.

We are not using OCIO but we do try to closely match OCIO implementation for VFX integration as we capture and color a significant amount of footage that goes to vfx. 

Adding the clamp and a flag should not be to troublesome but the default  behavior, if the tag is absent, should be the current non-clamping behavior.

-Joseph

Joseph Slomka
Color Scientist
Fotokem Industries







On Fri, May 23, 2014 at 10:07 AM, Robert Minsk <Robert...@methodstudios.com> wrote:

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.

--
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/d/optout.


Building "universal" binaries for MacOS

Andrea Mantler <man...@...>
 

I would like to build fat binaries with x86_64 and i386 architecture support.  I've tried passing the flag
    -DCMAKE_OSX_ARCHITECTURES=x86_64;i386
to cmake, but it appears that flag isn't being carried down to the building of libtinyxml.a and libyaml-cpp.a:

    ld: warning: in ../../ext/dist/lib/libtinyxml.a, file was built for unsupported file format which is not the architecture being linked (i386)
    ld: warning: in ../../ext/dist/lib/libyaml-cpp.a, file was built for unsupported file format which is not the architecture being linked (i386)

(Note:  I get the same errors if I try to build for just i386.)

Does anyone have any suggestions for what I can try?  Thanks! 


Re: Problem in CDL implementation

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

Robert,

Although we can conform to anything For our on-set tools we have made a match to how Nuke's OCIOCDLTransform node works.  This made the most sense because our main goal with CDL is to allow VFX facilities to match the look the cinematographers dials for dailies.  Additionally the ACES workflow does not clamp values above 1.0.

We are not using OCIO but we do try to closely match OCIO implementation for VFX integration as we capture and color a significant amount of footage that goes to vfx. 

Adding the clamp and a flag should not be to troublesome but the default  behavior, if the tag is absent, should be the current non-clamping behavior.

-Joseph

Joseph Slomka
Color Scientist
Fotokem Industries







On Fri, May 23, 2014 at 10:07 AM, Robert Minsk <Robert...@...> wrote:

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.

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


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

901 - 920 of 2217