For artists, it is preferable to have Nuke script resolution set up to be the same as the main plate resolution. But shot specs often require a crop / resize / reformat for output.
OP expects the nuke script resolution (generally: plate resolution), to be identical to output resolution.
To be able to publish different output, we must disable the write node validation.
There can be easily 20 different setups for how to go from source resolutions to the output resolutions. This often requires cropping and resizing, sometimes de-squeezing.
For example, source footage (and most of comping) is done in 4448x3096 ana 2:1, but output resolution is 4222x1768, pa 1.0. What we need is a way to be able to deliver shot10/4222x1768/shot10.1001.exr, with validation. For bigger projects, there can be 5 or 10 different delivery resolutions, so hardcoding folder name in anatomy template is not great.
Delivery - resolution in anatomy
Clients often require {width}x{height} subfolder for delivering image file sequences. OP has asset resolution in anatomy, is there a way how to inject the rendered resolution to anatomy for delivery action?
Review pixel aspect issues
There seem to be an issue with pixel aspect ratio when making reviews with ffmpeg. The actual (not asset) resolution is acquired by ffprobe, but pixel aspect is taken from the asset. This can produce bad aspect ratio outputs, like anamorphic slate for pa 1 output, or huge letterbox, when render pixel aspect differs from asset pixel aspect.
Maybe somehow flagging the expected resolution in settings /nuke/imageio/nodes/overrideNodes might work for validating?
How do you create your shots ?
Publishing from Hiero, exr sequences 99% of the time.
As far as I know the fix is
- set timeline to preferred output resolution
- untick source resolution to make it OFF
- republish Shot instances only
the Source resolution attribute is there only to tell publisher to inherit workfile/shot attributes from either Timeline or plate source
Let me know if that helps
Thank you, but I am happy with the way I setup shots. What I would prefer is to decouple working resolution from output resolution.
As far as I know that’s happens when toggling source resolution off does when publishing shots from Hiero
I am sorry for not being clear enough.
- Artists love to work in “source/plate resolution” being the same as Nuke script resolution.
- Artists have to often reformat the plate resolution to the “delivery resolution” at the bottom of the Nuke script.
- I wist to be able to do both: work in source/plate resolution, but output at different resolution and pixel aspect, ideally somehow telling the pipeline what the delivery resolution is.
What I can do now is:
- Work in “delivery resolution” (nuke script root set to delivery res - source resolution toggled off). Pipeline “knows the output”, but the work itself is unconfortable for artist, 'cause all the Nuke nodes default to nuke resolution, and artists have to be explicit while using “plate resolution”.
- Work in “source/plate resolution”. Nice for artists, but pipeline expects output with different resolution, so validators have to be off. If not only resolution but also pixel aspect differs, there are problems with slates and reviews.
We have encountered this as well on our last project. The Nuke scripts resolution had to be much bigger than the output due to overscan and 2d camera moves.
My suggestion would be to introduce delivery resolutions which are somehow linked to the shot/task.
When publishing the output resolution of a subset from Nuke would need to match one of the linked delivery resolutions.
Could maybe be combined with the delivery subset mentioned here; Separate delivery versions
At the moment only way to maintain the resolution flow as you suggest @jiri.sin is to connect/hack it via ExtractOIIOTranscode plugin. The name of the plugin suggests it is only for color conversion but since you can also use oiio arguments similarly to ffmpeg video filters, you could also introduce repositioning processes to match the delivery resolution from there.
Process would work somehow this way:
- publish shot instances from Hiero with source resolution enabled (plate resolution will become work resolution) - this way anatomy resolution and burnins will inherit the resolution farther downstream
1a. You can configure timeline soft-effects the way reposition nodes are part of effect family nodes for nuke Viewer Input Process nodes [VIPN](none-destructive way)
- In Nuke artist will work on plates resolution. And can preview the work via VIPN to see how it looks after all reformatting (included crops and pixel aspect decompression)
- Presets in
project_settings/global/publish/ExtractOIIOTranscode/profiles/ with reposition oiio arguments will make sure the delivery resolution is applied.
- Reviewing can be done on repos delivery or working resolution too.
1 Like
Neat! Now the only missing piece is the “effect to oiio convertor” that @max.pareschi mentioned, for artist friendy, publishable deloivery resolutions.
Thank you!
Yes ,you are right! Recently I have come across with this *.AMF. I am just assuming that it could be somehow utilized for this if OIIO will support it.
OCIO python api convertor
After just a quick look into it it might work with this ocio python api
Way I am thinking about it is following:
- we would take clients LUT files and publish them via TrayPublisher as *.amf product (subset) version
- We would rewrite the nuke loaded plugins for effects to utilize *.amf, rather then json or just add new plugin.
- during publishing form Nuke/Maya/etc host we will identify latest *.amf and convert it via ocio python api to aces compatible LUT so OIIO can use it.
But since this was just quick look I am not sure all of it can work or perhaps there is a better way to do it.
Hey @jakub.jezek nice find!
This will convert you color chain in .ctf files, which
Oiio will probably support .ctf files with the latest 2.4.*, using —ocio file transform.
I’d stay in config.ocio land though, lot easier to edit by hand and fix bugs if needed. Framestore provides configs on a shot by shot basis for instance.
Take a look at this: maxpareschi/DailiesMan
In the ColorTransformProcessor class I’m constructing a config on the fly to pass to oiiotool. Also, this would probably be nice to have as a config in nuke without loading effectjsons and turning the IP on.
1 Like
