|
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:
2) In Nuke's Script Editor, run:
import PyOpenColorIO as OCIO print OCIO.version
3) Some might. I don't personally.
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?
|
|
|
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?
|
|
|
Jonas Lindfors <jonas.l...@...>
toggle quoted message
Show quoted text
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
--
|
Jonas Lindfors
VFX Artist
|
|
Constantly challenging ourselves and our clients
to engage the audience through innovation and creation
|
|
|
|
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
|
|
|
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
|
|
|
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.
|
|
|
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.
|
|
|
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
|
|
|
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
|
|
|
