Date   

Re: Brew install OCIO breaking under 10.9.3

Alex Fry <al...@...>
 

Ignore this...

It was something broken in my brew..


On Sun, Jun 29, 2014 at 4:41 PM, Alex Fry <al...@...> wrote:
Hey guys

"brew install opencolorio" is currently failing for me under MacOSX 10.9.3
Was this working a few weeks back?

-Alex

192-168-1-7:~ alex$ brew install opencolorio

==> Downloading https://github.com/imageworks/OpenColorIO/archive/v1.0.9.tar.gz

Already downloaded: /Library/Caches/Homebrew/opencolorio-1.0.9.tar.gz

==> Downloading https://github.com/imageworks/OpenColorIO/commit/ebd6efc036b6d0b17c869e3342f17f9c5ef8bbfc.diff

Already downloaded: /Library/Caches/Homebrew/opencolorio--patch-f4acc4028090ea8d438c6e0093e931afd836314c.diff

==> Patching

patching file export/OpenColorIO/OpenColorABI.h.in

patching file export/OpenColorIO/OpenColorIO.h

==> cmake -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/opencolorio/1.0.9 -DCMAKE_BUILD_TYPE=None -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_VERBOSE_MAKEFILE=ON -Wno-dev -DCM

==> make

Linking CXX static library libOpenColorIO.a

[100%] Built target OpenColorIO_STATIC

Linking CXX executable ociobakelut

[100%] Built target ociobakelut

make: *** [all] Error 2


READ THIS: https://github.com/Homebrew/homebrew/wiki/troubleshooting




Brew install OCIO breaking under 10.9.3

Alex Fry <al...@...>
 

Hey guys

"brew install opencolorio" is currently failing for me under MacOSX 10.9.3
Was this working a few weeks back?

-Alex

192-168-1-7:~ alex$ brew install opencolorio

==> Downloading https://github.com/imageworks/OpenColorIO/archive/v1.0.9.tar.gz

Already downloaded: /Library/Caches/Homebrew/opencolorio-1.0.9.tar.gz

==> Downloading https://github.com/imageworks/OpenColorIO/commit/ebd6efc036b6d0b17c869e3342f17f9c5ef8bbfc.diff

Already downloaded: /Library/Caches/Homebrew/opencolorio--patch-f4acc4028090ea8d438c6e0093e931afd836314c.diff

==> Patching

patching file export/OpenColorIO/OpenColorABI.h.in

patching file export/OpenColorIO/OpenColorIO.h

==> cmake -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/opencolorio/1.0.9 -DCMAKE_BUILD_TYPE=None -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_VERBOSE_MAKEFILE=ON -Wno-dev -DCM

==> make

Linking CXX static library libOpenColorIO.a

[100%] Built target OpenColorIO_STATIC

Linking CXX executable ociobakelut

[100%] Built target ociobakelut

make: *** [all] Error 2


READ THIS: https://github.com/Homebrew/homebrew/wiki/troubleshooting



OpenColorIO COP2 nodes for Houdini as Nuke counterparts

wagen...@...
 


------------------------------------------------------------------------------------ 
------------------------------------------------------------------------------------

OpenColorIO COP2 nodes for Houdini as Nuke counterparts 
An unofficial HDK plugin to bring Nukes well known OCIO nodes to Houdinis compositing network. 

------------------------------------------------------------------------------------ 
------------------------------------------------------------------------------------


Hi guys,

this is my first post on the mailing list. I'm a Technical Direction Student from Filmakademie in Germany
and i created an OCIO plugin for Houdinis compositing network that aims to bring Nukes OCIO nodes to Houdini.
Please feel free to have a look ;)

------------------------------------------------------------------------------------ 
------------------------------------------------------------------------------------


OpenColorIO COP2 nodes? 

As an integral part of VFX and Animation pipelines, it makes sense for Houdini to support OCIO. 
A possible use case for example could be, to grade backdrops when rendering.


Here is a little introduction video 

And some images: 

  • Tab Menu
  • OCIOCDLTransformApplies an ASC CDL (American Society of Cinematographers Color Decision List) grade based on the OpenColorIO Library
  • OCIOColorspaceApply a color transformation based on a .ocio file. Ocio files are yaml based and describe the complete available colorenvironment. The color environment in turn usualy consists of a dozen Lut files which describe transformations to/from the reference color space to the target space.
  • OCIOFileTransformAccepts a path to a specific color lut file and does a color transformation based on it.
  • OCIOLogConvertDo a color transformation from Lin to Log, or the other way round, based on the Lin and Log roles of the given .ocio config file. 
------------------------------------------------------------------------------------ 
------------------------------------------------------------------------------------


Plugin Status 
Please note that the plugin is currently in alpha status. There are still bugs here and there but i guess it's best to release it now, so maybe it will get some true battle testing. 
Should you find bugs, please feel free to submit them on the github issue tracker
Also please feel free to fork or clone the repo and build the plugin for your platform. I currently only supply precompiled binaries for H13 for windows, built with msvc11. 
(I want to supply Linux binaries as well, since i know about its importance in the Houdini community, as soon as i have a Linux build setup up and running). 

Git Repository 

------------------------------------------------------------------------------------ 
------------------------------------------------------------------------------------


Download and additional information 
Additional information can be found on my website. 
Download the precompiled binaries here (H13, Win, MSVC11) 
The download contains example images and scenes. 

I hope the plugin is of use to somebody Wink
------------------------------------------------------------------------------------ 
------------------------------------------------------------------------------------

In case you are interested in following some forum discussions on some Houdini forums:
Official SideFX forum (contains a probably interesting poll)


AllocationVars and Allocation tags problem

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

Good morning!

I have finally developed that OCIO enabled color selectors feature in Krita (some time ago I asked about reversed Display transformations in this list to make this feature). You can read about the details about that work at [1].

But now I have another problem which is related to 'allocation' and 'allocationvars' feature of OCIO. The point is, here in Krita we use openGL shaders to do color processing and the default range for the 3D-lut [-15.0, 6.0] seems to be too wide in some circumstances. I tested the our color selectors functionality on a special config by Troy Sobotka [2] and I have heavy rounding/clipping when using shaders.

Here is how the image looks when calculating on CPU:
http://dimula73.narod.ru/krita_allocation_var_CPU.png

The cause of this problem is too wide range for the 'allocatiovars' used in config, which is actually standard spi-vfx value. If I change the value to, say, [-10.0, 5.0] then the quality of the transformation becomes ok and the shaders generate the image looking exactly like on CPU.

Can we (OCIO and/or Krita) do something with it? What I'm thinking about is: it is quite rare usecase when the application (e.g. Krita) needs to display the whole range of the image colors. That is, most of the time we display only a small subset of the image colors, say, [0.0, 1.0] or [0.0, exposition]. Can we adjust the allocationvars dynamically according to the currently displayed gamut?

Some crazy idea:

The application might notice the DisplayTransform about what output colors are actually needed. For shader-based rendering it'll be [0.0, 1.0] obviously. Then OCIO might walk through the chain of transformations and adjust their allocation values according to the values really needed. Obviously enough one would need to obtain reverse transformations for that, which is impossible... But given that 3D-lut in the shader is an approximation anyway, the range can be acquired using random sampling of the space defined in allocationvars and used for generation of the 3D-lut.

I understand that this is optimization, but it can not only fix problems with such corner-cases like [2], but also give much better quality of the GPU-based rendering of the image. the 3D-luts generated by OCIO would be more dense, and would nor waste the range on values which will never be displayed anyway.

What do you think about this idea?


Re: Using environment variables/context to point to a colorspace

donat...@...
 


Hi,

Thanks for the ticket.

I could indeed implement a callback for the OCIO colorspace nodes. I already have some code that sets the context variables of the OCIO ColorSpace node. The problem is then for the viewer dropdown menu. It would not be very convenient in Nuke's UI to have to add somewhere a button to control the viewer dropdown menu.

In my previous implementation of OCIO I created different colorspaces such as "ShotViewAlexa", "ShotViewRedGamma3". These colorspaces were meant for Nuke's viewer. They convert from linear to the cam colorspace, then add a 3d lut specific to the shot. This was kind of problematic because users sometimes were using the wrong colorspace. I'd rather have a single colorspace for showing the shot specific grade. 

In the meantime I did find a workaround. I'm defining my 'shotView' colorspace as being a transfrom from Linear to the Camera Colorspace, then I apply a shot specific 3dl lut.

In my config file it's like this : 

        - !<ColorSpaceTransform> {src: Flat, dst: linear}   # Flat is a balanced linear colorspace
        - !<FileTransform> {src: Camera/$CAMERA/$CAMERA_main.spi1d, interpolation: linear, direction: inverse}
        - !<FileTransform> {src: Camera/$CAMERA/$CAMERA_post.spi1d, interpolation: linear} 
        - !<FileTransform> {src: $EVENT_Grade.3dl, interpolation: linear}

So If I feed the correct $CAMERA context it resolves correctly. The 'problem' is that for each camera colorspace I have to use the exact same steps. In this case I have two 1d luts applied. If at some time I need to add a matrix transform for a particular camera, I will need to add an identity matrix for every other camera.

So I think pointing to colorspaces using context variables would make OCIO much more flexible. I hope this makes sense...

Regards.

Donat Van Bellinghen


On Thursday, June 12, 2014 3:10:34 PM UTC+2, dbr/Ben wrote:
Made a ticket about this,

As an alternative, could you do something with Python in Nuke? Maybe a menu item or addOnUserCreate callback which automatically creates the appropriately configured OCIOColorspace node
- Ben

On 12/06/2014, at 2:38 PM, Robert Minsk wrote:

Unfortunately the current version of OCIO only uses context variables when resolving file paths.  Context variables are only used in search paths and the src parameter for a FileTransform.

On Wednesday, June 11, 2014 4:14:36 PM UTC-7, do...@... wrote:
Hi,

I did post this question to OCIO-users and did not get any reaction, so I'm trying here as it might be a question related to development. Anyway I'm sorry if this is against posting rules.



I've been implementing OCIO at our company. Thanks a lot for your efforts with this project, it is making things a lot easier for me, and more future proof.

I'm using per-shot viewer luts using context variables inside the OCIO nodes in Nuke. That works like it is supposed to. 

I'm facing some difficulties from the fact that on our projects (mostly television commercials) we frequently get footage shot with different cameras. I'd like to find a system to avoid having to tell the artist which camera has been used for which shot. I'd like to define a 'CameraRaw' colorspace that would point to other colorspaces in function of a context. So for example I would define it like this :


- !<ColorSpace>
    name: CameraRaw
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Camera Raw depends on context
    isdata: false
    allocation: uniform
    allocationvars: [-0.125, 1.125]
    from_reference: !<ColorSpaceTransform> {src: linear, dst: $CAMERARAW}

I tried this and in Nuke I used an OCIO colorspace node, setting the out colorspace to CameraRaw, and setting the context of the node of key1 =CAMERARAW and value1 = Alexa_Rec709
Of course the Alexa_Rec709 colorspace is also defined in the config file.

When I do this get an error from Nuke's viewer. OCIOColorSpace1: BuildColorSpaceOps failded, null dstColorSpace.

I'm not sure this is a bug report or a feature request. Anyway I think it would be quite valuable to be able to use context variables/environement variables to not only point to files on the disk but to other colorspaces as well.

Regards

Donat Van Bellinghen

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


Re: Problem in CDL implementation

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

Could some sort of generic string->string dictionary parameter be added to FileTransform that would be passed to each of the readers?

This was discussed a while ago in "[ocio-dev] FileTransform interface changes",

..and would become a nonissue with (fairly large) change implemented:


On 29/05/2014, at 2:54 AM, rmi...@... wrote:

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.


--
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: Yaml related warning message when compiling OCIO

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

Belated reply, but, those warnings can (hopefully) be ignored if you are just building OCIO

The problem is because "Config::getNumEnvironmentVars" returns an "int", when it should probably return an "unsigned int" (because there can't possibly be negative number of env-vars). The warning occurs because comparing int with unsigned int can act in strange ways (like claiming -5 is greater than 2)

On 01/05/2014, at 4:41 AM, etienne....@... wrote:

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

--
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: Using environment variables/context to point to a colorspace

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

Made a ticket about this,

As an alternative, could you do something with Python in Nuke? Maybe a menu item or addOnUserCreate callback which automatically creates the appropriately configured OCIOColorspace node
- Ben

On 12/06/2014, at 2:38 PM, Robert Minsk wrote:

Unfortunately the current version of OCIO only uses context variables when resolving file paths.  Context variables are only used in search paths and the src parameter for a FileTransform.

On Wednesday, June 11, 2014 4:14:36 PM UTC-7, do...@... wrote:
Hi,

I did post this question to OCIO-users and did not get any reaction, so I'm trying here as it might be a question related to development. Anyway I'm sorry if this is against posting rules.



I've been implementing OCIO at our company. Thanks a lot for your efforts with this project, it is making things a lot easier for me, and more future proof.

I'm using per-shot viewer luts using context variables inside the OCIO nodes in Nuke. That works like it is supposed to. 

I'm facing some difficulties from the fact that on our projects (mostly television commercials) we frequently get footage shot with different cameras. I'd like to find a system to avoid having to tell the artist which camera has been used for which shot. I'd like to define a 'CameraRaw' colorspace that would point to other colorspaces in function of a context. So for example I would define it like this :


- !<ColorSpace>
    name: CameraRaw
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Camera Raw depends on context
    isdata: false
    allocation: uniform
    allocationvars: [-0.125, 1.125]
    from_reference: !<ColorSpaceTransform> {src: linear, dst: $CAMERARAW}

I tried this and in Nuke I used an OCIO colorspace node, setting the out colorspace to CameraRaw, and setting the context of the node of key1 =CAMERARAW and value1 = Alexa_Rec709
Of course the Alexa_Rec709 colorspace is also defined in the config file.

When I do this get an error from Nuke's viewer. OCIOColorSpace1: BuildColorSpaceOps failded, null dstColorSpace.

I'm not sure this is a bug report or a feature request. Anyway I think it would be quite valuable to be able to use context variables/environement variables to not only point to files on the disk but to other colorspaces as well.

Regards

Donat Van Bellinghen

--
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: Using environment variables/context to point to a colorspace

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

Unfortunately the current version of OCIO only uses context variables when resolving file paths.  Context variables are only used in search paths and the src parameter for a FileTransform.


On Wednesday, June 11, 2014 4:14:36 PM UTC-7, do...@... wrote:
Hi,

I did post this question to OCIO-users and did not get any reaction, so I'm trying here as it might be a question related to development. Anyway I'm sorry if this is against posting rules.



I've been implementing OCIO at our company. Thanks a lot for your efforts with this project, it is making things a lot easier for me, and more future proof.

I'm using per-shot viewer luts using context variables inside the OCIO nodes in Nuke. That works like it is supposed to. 

I'm facing some difficulties from the fact that on our projects (mostly television commercials) we frequently get footage shot with different cameras. I'd like to find a system to avoid having to tell the artist which camera has been used for which shot. I'd like to define a 'CameraRaw' colorspace that would point to other colorspaces in function of a context. So for example I would define it like this :


- !<ColorSpace>
    name: CameraRaw
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Camera Raw depends on context
    isdata: false
    allocation: uniform
    allocationvars: [-0.125, 1.125]
    from_reference: !<ColorSpaceTransform> {src: linear, dst: $CAMERARAW}

I tried this and in Nuke I used an OCIO colorspace node, setting the out colorspace to CameraRaw, and setting the context of the node of key1 =CAMERARAW and value1 = Alexa_Rec709
Of course the Alexa_Rec709 colorspace is also defined in the config file.

When I do this get an error from Nuke's viewer. OCIOColorSpace1: BuildColorSpaceOps failded, null dstColorSpace.

I'm not sure this is a bug report or a feature request. Anyway I think it would be quite valuable to be able to use context variables/environement variables to not only point to files on the disk but to other colorspaces as well.

Regards

Donat Van Bellinghen


Re: Good Morning!

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

Looking at the code OCIO implements Matrix*RGBA (column vector).  In matrix operations RGBA*transpose(matrix) = matrix*RGBA.  If you feel you are getting the wrong multiplication order then try using the transpose of the matrix.


On Wednesday, June 11, 2014 6:40:33 AM UTC-7, Joshua Jackson wrote:
My name is Joshua Jackson.  I'm writing a custom configuration with ocio and have a quick question:
Can I apply Matrix Transforms in a different order than RGB x MTX x etc... ?
For Chromatic Adaptation Transforms, it is neccessary to apply a matrix in a different order to the given RGB/XYZ/etc. ( MTX x RGB x etc.)

Thank you so much for your time!

--
Joshua Jackson
Executive Producer
First Five Years Productions, LLC
________________________________________


Using environment variables/context to point to a colorspace

do...@...
 

Hi,

I did post this question to OCIO-users and did not get any reaction, so I'm trying here as it might be a question related to development. Anyway I'm sorry if this is against posting rules.



I've been implementing OCIO at our company. Thanks a lot for your efforts with this project, it is making things a lot easier for me, and more future proof.

I'm using per-shot viewer luts using context variables inside the OCIO nodes in Nuke. That works like it is supposed to. 

I'm facing some difficulties from the fact that on our projects (mostly television commercials) we frequently get footage shot with different cameras. I'd like to find a system to avoid having to tell the artist which camera has been used for which shot. I'd like to define a 'CameraRaw' colorspace that would point to other colorspaces in function of a context. So for example I would define it like this :


- !<ColorSpace>
    name: CameraRaw
    family: ""
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Camera Raw depends on context
    isdata: false
    allocation: uniform
    allocationvars: [-0.125, 1.125]
    from_reference: !<ColorSpaceTransform> {src: linear, dst: $CAMERARAW}

I tried this and in Nuke I used an OCIO colorspace node, setting the out colorspace to CameraRaw, and setting the context of the node of key1 =CAMERARAW and value1 = Alexa_Rec709
Of course the Alexa_Rec709 colorspace is also defined in the config file.

When I do this get an error from Nuke's viewer. OCIOColorSpace1: BuildColorSpaceOps failded, null dstColorSpace.

I'm not sure this is a bug report or a feature request. Anyway I think it would be quite valuable to be able to use context variables/environement variables to not only point to files on the disk but to other colorspaces as well.

Regards

Donat Van Bellinghen


Good Morning!

Joshua Jackson <joshua.a...@...>
 

My name is Joshua Jackson.  I'm writing a custom configuration with ocio and have a quick question:
Can I apply Matrix Transforms in a different order than RGB x MTX x etc... ?
For Chromatic Adaptation Transforms, it is neccessary to apply a matrix in a different order to the given RGB/XYZ/etc. ( MTX x RGB x etc.)

Thank you so much for your time!

--
Joshua Jackson
Executive Producer
First Five Years Productions, LLC
________________________________________


No way to retreive "non-active" displays

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

If I have a config with displays "a", "b", "c" and an active_display list of "a" there is no way to get to displays "b" and "c".  In fact reading in a config file and writing it back out will only write out display "a".  Should we add a methods to get the total number of displays not filtered by the active list and a method to retrieve the "non-active" displays?


Re: Building "universal" binaries for MacOS

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

Success!  Now to make sure I have the same version on linux (in case anything else changed from 1.0.9), then build for Windows (fingers crossed that there's no glitches there!), and I'm ready to start integrating it into our software!


On Friday, May 30, 2014 1:51:06 PM UTC-5, rmi...@... wrote:
If you do another pull the cmake file should use the internal lcms by default.

On Friday, May 30, 2014 10:19:00 AM UTC-7, Andrea Mantler wrote:
Yeah, I'm working at getting a universal version compiled now.  Thanks!

On Friday, May 30, 2014 11:50:22 AM UTC-5, rmi...@... wrote:
> ld: warning: in /opt/local/lib/liblcms2.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

Your liblcms2 is not a universal library.  I guess it came from homebrew.  It would be very hard to detect if the system liblcms2 contains all the right architectures for the current build.  I guess some of flag could be added to the cmake file to force it to use its internal liblcms2.

On Thursday, May 29, 2014 3:00:35 PM UTC-7, Andrea Mantler wrote:
Curses... google ate my reply!  A summary of what I wrote:

1.  Doing some more testing with yesterday's version, I noticed that changing the order of x86_64 and i386 changed the architecture that the two libraries are built in (it builds whichever comes first).
2.  Today's version is progress!  (Yay!  Thanks!)  tinyxml and yaml-cpp are being built as x86_64 & i386 fat binaries!  However, now it's erroring out in ociobakelut, due to the following:

ld: warning: in /opt/local/lib/liblcms2.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

I'm looking into this now...

Thanks!
Andrea

On Thursday, May 29, 2014 1:23:04 PM UTC-5, rmi...@... wrote:
It is fun to getting quoting rules right in cmake.  Please pull the git repo again and test again.

On Wednesday, May 28, 2014 11:27:29 AM UTC-7, 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!


On Friday, May 30, 2014 1:51:06 PM UTC-5, rmi...@... wrote:
If you do another pull the cmake file should use the internal lcms by default.

On Friday, May 30, 2014 10:19:00 AM UTC-7, Andrea Mantler wrote:
Yeah, I'm working at getting a universal version compiled now.  Thanks!

On Friday, May 30, 2014 11:50:22 AM UTC-5, rmi...@... wrote:
> ld: warning: in /opt/local/lib/liblcms2.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

Your liblcms2 is not a universal library.  I guess it came from homebrew.  It would be very hard to detect if the system liblcms2 contains all the right architectures for the current build.  I guess some of flag could be added to the cmake file to force it to use its internal liblcms2.

On Thursday, May 29, 2014 3:00:35 PM UTC-7, Andrea Mantler wrote:
Curses... google ate my reply!  A summary of what I wrote:

1.  Doing some more testing with yesterday's version, I noticed that changing the order of x86_64 and i386 changed the architecture that the two libraries are built in (it builds whichever comes first).
2.  Today's version is progress!  (Yay!  Thanks!)  tinyxml and yaml-cpp are being built as x86_64 & i386 fat binaries!  However, now it's erroring out in ociobakelut, due to the following:

ld: warning: in /opt/local/lib/liblcms2.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

I'm looking into this now...

Thanks!
Andrea

On Thursday, May 29, 2014 1:23:04 PM UTC-5, rmi...@... wrote:
It is fun to getting quoting rules right in cmake.  Please pull the git repo again and test again.

On Wednesday, May 28, 2014 11:27:29 AM UTC-7, 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...@...
 

If you do another pull the cmake file should use the internal lcms by default.


On Friday, May 30, 2014 10:19:00 AM UTC-7, Andrea Mantler wrote:
Yeah, I'm working at getting a universal version compiled now.  Thanks!

On Friday, May 30, 2014 11:50:22 AM UTC-5, rmi...@... wrote:
> ld: warning: in /opt/local/lib/liblcms2.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

Your liblcms2 is not a universal library.  I guess it came from homebrew.  It would be very hard to detect if the system liblcms2 contains all the right architectures for the current build.  I guess some of flag could be added to the cmake file to force it to use its internal liblcms2.

On Thursday, May 29, 2014 3:00:35 PM UTC-7, Andrea Mantler wrote:
Curses... google ate my reply!  A summary of what I wrote:

1.  Doing some more testing with yesterday's version, I noticed that changing the order of x86_64 and i386 changed the architecture that the two libraries are built in (it builds whichever comes first).
2.  Today's version is progress!  (Yay!  Thanks!)  tinyxml and yaml-cpp are being built as x86_64 & i386 fat binaries!  However, now it's erroring out in ociobakelut, due to the following:

ld: warning: in /opt/local/lib/liblcms2.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

I'm looking into this now...

Thanks!
Andrea

On Thursday, May 29, 2014 1:23:04 PM UTC-5, rmi...@... wrote:
It is fun to getting quoting rules right in cmake.  Please pull the git repo again and test again.

On Wednesday, May 28, 2014 11:27:29 AM UTC-7, 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...@...>
 

Yeah, I'm working at getting a universal version compiled now.  Thanks!


On Friday, May 30, 2014 11:50:22 AM UTC-5, rmi...@... wrote:
> ld: warning: in /opt/local/lib/liblcms2.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

Your liblcms2 is not a universal library.  I guess it came from homebrew.  It would be very hard to detect if the system liblcms2 contains all the right architectures for the current build.  I guess some of flag could be added to the cmake file to force it to use its internal liblcms2.

On Thursday, May 29, 2014 3:00:35 PM UTC-7, Andrea Mantler wrote:
Curses... google ate my reply!  A summary of what I wrote:

1.  Doing some more testing with yesterday's version, I noticed that changing the order of x86_64 and i386 changed the architecture that the two libraries are built in (it builds whichever comes first).
2.  Today's version is progress!  (Yay!  Thanks!)  tinyxml and yaml-cpp are being built as x86_64 & i386 fat binaries!  However, now it's erroring out in ociobakelut, due to the following:

ld: warning: in /opt/local/lib/liblcms2.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

I'm looking into this now...

Thanks!
Andrea

On Thursday, May 29, 2014 1:23:04 PM UTC-5, rmi...@... wrote:
It is fun to getting quoting rules right in cmake.  Please pull the git repo again and test again.

On Wednesday, May 28, 2014 11:27:29 AM UTC-7, 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...@...
 

> ld: warning: in /opt/local/lib/liblcms2.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

Your liblcms2 is not a universal library.  I guess it came from homebrew.  It would be very hard to detect if the system liblcms2 contains all the right architectures for the current build.  I guess some of flag could be added to the cmake file to force it to use its internal liblcms2.

On Thursday, May 29, 2014 3:00:35 PM UTC-7, Andrea Mantler wrote:
Curses... google ate my reply!  A summary of what I wrote:

1.  Doing some more testing with yesterday's version, I noticed that changing the order of x86_64 and i386 changed the architecture that the two libraries are built in (it builds whichever comes first).
2.  Today's version is progress!  (Yay!  Thanks!)  tinyxml and yaml-cpp are being built as x86_64 & i386 fat binaries!  However, now it's erroring out in ociobakelut, due to the following:

ld: warning: in /opt/local/lib/liblcms2.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

I'm looking into this now...

Thanks!
Andrea

On Thursday, May 29, 2014 1:23:04 PM UTC-5, rmi...@... wrote:
It is fun to getting quoting rules right in cmake.  Please pull the git repo again and test again.

On Wednesday, May 28, 2014 11:27:29 AM UTC-7, 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...@...>
 

Curses... google ate my reply!  A summary of what I wrote:

1.  Doing some more testing with yesterday's version, I noticed that changing the order of x86_64 and i386 changed the architecture that the two libraries are built in (it builds whichever comes first).
2.  Today's version is progress!  (Yay!  Thanks!)  tinyxml and yaml-cpp are being built as x86_64 & i386 fat binaries!  However, now it's erroring out in ociobakelut, due to the following:

ld: warning: in /opt/local/lib/liblcms2.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

I'm looking into this now...

Thanks!
Andrea

On Thursday, May 29, 2014 1:23:04 PM UTC-5, rmi...@... wrote:
It is fun to getting quoting rules right in cmake.  Please pull the git repo again and test again.

On Wednesday, May 28, 2014 11:27:29 AM UTC-7, 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...@...
 

It is fun to getting quoting rules right in cmake.  Please pull the git repo again and test again.


On Wednesday, May 28, 2014 11:27:29 AM UTC-7, 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! 

881 - 900 of 2217