Topics

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


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


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.


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.


jonas.l...@...
 

Hi guys. Does anyone know if this is solved? Is it possible to use variables to point to a colorspace?


On Thursday, June 12, 2014 at 1:14:36 AM UTC+2, 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


Patrick Hodoul <patric...@...>
 

Please refer to pull request #477


On Thursday, November 2, 2017 at 12:12:47 PM UTC-4, jonas...@... wrote:
Hi guys. Does anyone know if this is solved? Is it possible to use variables to point to a colorspace?

On Thursday, June 12, 2014 at 1:14:36 AM UTC+2, 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


Jonas Lindfors <jonas.l...@...>
 

Awesome!

On Mon, Nov 6, 2017 at 9:48 PM, Patrick Hodoul <patric...@...> wrote:
Please refer to pull request #477


On Thursday, November 2, 2017 at 12:12:47 PM UTC-4, jonas...@... wrote:
Hi guys. Does anyone know if this is solved? Is it possible to use variables to point to a colorspace?

On Thursday, June 12, 2014 at 1:14:36 AM UTC+2, 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 a topic in the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ocio-dev/Pj3SJs-hW6U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
CHIMNEY
Jonas Lindfors
VFX Artist

CHIMNEY
Skeppsbron 38
111 30 Stockholm
Mobile: +46 706 530 538
www.chimneygroup.com

Constantly challenging ourselves and our clients
to engage the audience through innovation and creation


anthony.kramer@...
 

I've been trying to chase down this feature from the old google group. It looks like it was added (pull #477) but in the current version of Nuke I'm on (11.3v2) it doesn't seem to work. So it brings up a few questions:

1) Does the foundry use the releases from the master OCIO repository on github?
2) If so, how do we know what version of OCIO is in the Nuke release?
3) Are many of you using your own builds to replace the foundry's version packaged with nuke?


Michael Dolan
 

Hi Anthony,

The functionality in PR #477 was released with OCIO 1.1.0, which is included in VFX Reference Platform CY2019. Foundry hasn't gotten Nuke onto CY2019 quite yet. Nuke 11.3v3 ships with OCIO 1.0.9. To answer your other questions:

1) They would be pulling from a release tag (https://github.com/imageworks/OpenColorIO/tree/v1.0.9), not from master. Master is OCIO's dev branch.
2) In Nuke's Script Editor, run:

import PyOpenColorIO as OCIO
print OCIO.version

3) Some might. I don't personally.

On Mon, Apr 22, 2019, 8:29 AM , <anthony.kramer@...> wrote:
I've been trying to chase down this feature from the old google group. It looks like it was added (pull #477) but in the current version of Nuke I'm on (11.3v2) it doesn't seem to work. So it brings up a few questions:

1) Does the foundry use the releases from the master OCIO repository on github?
2) If so, how do we know what version of OCIO is in the Nuke release?
3) Are many of you using your own builds to replace the foundry's version packaged with nuke?