Reviewsubmission color_space

Pipeline Integrations
1

Hey everybody,

Is there something special I need to do to get the colorspace from Nuke into the reviewsubmission app?

I took over the hooks and everything works as expected. If I do a a simple “print colorspace” in the submit_for_review.py hook I see the the colorspace from the Nuke write node as expected.

But if I do a “print color_space” in the render_media.py hook in the reviewsubmission app it always returns None.

Am I missing something?

Cheers,

David

2 Likes
2

Ok, I did some digging and found out that in the app.py for the tk-multi-reviewsubmission app, there’s color_space = None specified.

This is in the render_and_submit_version arguments.
So when this is present, the colorspace from the Nuke Write nodes is not caried into the review submission app.

Is this there for a reason?
In the render_media.py hook for Nuke, there is an explicit line in the hook:
if color_space:
read[“colorspace”].setValue(color_space)

However, this off-course doesn’t work by default because the colorspace is never present.

I can fork the app and fix it myself, but I like to keep as many apps “vanilla” Shotgun, so they update automaticaly.

Cheers,

David

2 Likes
3

Hi @Davidvh,

Welcome to the community!
The colourspace setting is defined in the render_media.py hook in the review submission app, you can configure it there by adding the colourspace setting, so if I branch the hook I would add the setting write_node["colorspace"].setValue("Output - sRGB") ("I’ve used Output - sRGB as an example here, but you can set as you want) to where it makes sense in this block.

So the idea (I believe) behind having the colourspace defined separately was so that regardless of the colourspace set on your tk-write-node the reviewsubmission app would still write a default colourspace QT (generally sRGB) for upload.

Now things have moved on alot with colourspaces and the advent of ACES, so this might not be the best method for you, but with the hook you can define it as you like without branching the app.

-David

2 Likes
4

Hi David,

Thanks for the explanation. I already have that set for the output write node. That works fine and picks up the correct output space for the writenode.

But I’m talking about setting the colorspace for the read node that is spawned during the quicktime generation. That one relies on what comes in as color_space. So essentially the colorspace that is rendered with the Tk write nodes should be the same as the one used by the read node that is temporarily created during the quicktime render.

I’m indeed setting up an ACES pipeline, and there appear to be some edge cases where we still need to output files with specific colorspaces which are misinterpreted by OCIO. DPX files are a prime example. They can be Cineon, LogC, etc. So I need to be sure what is rendered with TK nodes are then properly interpreted in the review submission read node.

1 Like