search

ynput / OpenPype

OpenPype has been surpassed by AYON and is now read only.
https://ayon.ynput.io
MIT License
286 stars 129 forks source link

Global: colorspace workflow support Display and View inputs #4504

Open jakubjezek001 opened 1 year ago

jakubjezek001 commented 1 year ago

Is your feature request related to a problem? Please describe. A the moment we only support colorspace input from DCC, but we will need to support to make it more universal because Transcoding can be targeted with Colorspace or Display & View preference.

Describe the solution you'd like We need to be able to store display and view keys in colorspaceData on instance's representation. Also need to consider to enhance File Rules settings data model with Display and View.

[cuID:OP-4995]

tokejepsen commented 1 year ago

This already happens in the PR, right? https://github.com/ynput/OpenPype/pull/4291/files#diff-19eb0ff46fbda7281bf0d947a160f8b50bd67c54929efa69e161074f9f78066eR122-R124

jakubjezek001 commented 1 year ago

This already happens in the PR, right? #4291 (files)

Yes and no. We are using the data in the mentioned transcoding exctractor, but it expects we do have them in colorspaceData on a representation. Although Maya is adding them in some cases Nuke/Hiero/Davinci/Flame/Fusion and some others are not.

There are two ways to add them. Once would be to set them in Settings for the project in imageio (like nuke does for baking) or equaier them from DCC active Viewer (similarly Maya does for playblast).

BigRoy commented 1 year ago

Yes and no. We are using the data in the mentioned transcoding exctractor, but it expects we do have them in colorspaceData on a representation. Although Maya is adding them in some cases Nuke/Hiero/Davinci/Flame/Fusion and some others are not.

There are two ways to add them. Once would be to set them in Settings for the project in imageio (like nuke does for baking) or equaier them from DCC active Viewer (similarly Maya does for playblast).

I still don't fully grasp the issue here. Could you break it down into baby steps for me? :)

jakubjezek001 commented 1 year ago

I'll give an example from the Nuke point of view. Right now we have a baking process (ExctractReviewDataMov). Back in days, we didn't have the OIIO transcoding functionality in OP, so the only way to secure colorspace consistency for reviewable video files was by defining screen space (view & display) to bake into; from any of defined scene space (working space usually linear or acescg). For this process to be complete, we have to define what is the baking screen space we want to use so it is baked into intermediate mov file which is then used in ExctractReview for generating other representations regarding defined output presets.

So now we're almost able to do the same with the current OIIO transcoding workflow, except we're missing the part where we would collect the current display.

Therefore we would need to modify the current workflow so that we can get a consistent colorspace management with OIIO transcoding. We could do this by either providing a way to collect the actual viewer settings and assign them to the output file or by getting definitions from imageio settings where the production can be locked on baking display/view manually. Both methods should allow us to securely define the colorspace for our output representations and ensure colorspace consistency for the baking process.