-
Notifications
You must be signed in to change notification settings - Fork 129
colorspace distribution #2579
Comments
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 |
was implemented with #4195 |
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:
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]
The text was updated successfully, but these errors were encountered: