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

colorspace distribution #2579

Closed jakubjezek001 closed 1 year ago

jakubjezek001 commented 2 years ago

Discussed in https://github.com/pypeclub/OpenPype/discussions/2574

Originally posted by **jakubjezek001** January 21, 2022 # Problem At the moment we are storing color space information in the form of string which is usually a name of used profile of an DCC's object we are publishing. Those profiles can vary from DCC to DCC. We are not storing type of color management and its config version or even working space from which the profile was transferring. # Scerario where it breaks This could be causing confusion in future. I am, for example, now working on Flame integration and its way of understanding color space and naming convention is completely different from standardized forms in OCIO. Also since we are storing the colorspace attribute only on version and not on particular representataions this can also by wrong. For example I will be publishing clip which is set to Rec709 and this will be added to version data, but from that clip I will be transcoding during publishing to another two different formats with each different color profile. Then at the time of loading the clip into Nuke its read node will be set to Rec709 as the data are taken from version data. # Solution proposal ## Colorspace attribute as dictionary To make our lives in the future more relaxed I am proposing to convert color space information to dictionary. Where: ``` { "spaceManagement": "ocio", "spaceType": "aces", "spaceVersion": "1.1.0", "spaceCustomConfigPath": "", "spaceWorkingProfile": "ACES - ACEScg", "outColorProfile": "Output - Rec.709" } ``` Most of the data could be taken from our settings `project_anatomy/imageio` so to get them from there and distribute downstream would not be that difficult. ## Colorspace attribute stored up to representation level Next, we will need to store colorspace attribute up to representation level. This way we would be able to load data with corect colorspace and in case we are loading into scene where different colorspace management and type is used we could create dynamically colorspace conversions. As you could understand this could be of course a hierarchical attribure which would be stored from project down to representation data but perhpas even better to have them on object attributes so they could be validated. In case of missing data those would be inherited from level above.

[cuID:OP-2479]

antirotor commented 2 years ago

What about some type of abstraction. As we hit the issue @BigRoy mentioned with Maya - where there are basically different names for the same color profile - and we need to deal with it, I have a feeling we need to find common ground between DCCs and their versions.

For example stuff rendered out of Maya 2020 that is color managed with profile scene-linear Rec 709/sRGB (and that will be stored on representation data) you will need to load into Nuke, where this profile will have completely different name and we will need to handle cumbersome mapping between those. What about providing our on OCIO file and reference all those profile names from there - and if mapping is needed, than do mapping only between DCC version and our OCIO? And if studio has it's own OCIO config, it should work almost the same?

jakubjezek001 commented 1 year ago

was implemented with https://github.com/ynput/OpenPype/pull/4195