In the ASWF Color Interop Forum recommendations, there is a color space "Unknown". This is intended to be used by application developers when they need to set the color space metadata in some file format if they don't actually know what the real color space is. This is intended to help avoid the common problem where developers simply "guess" and set something that turns out to be wrong.
The question then is what should happen when reading a file that is tagged with the color space "Unknown"?
If config authors include "Unknown" in their config pointing to whatever color space they want to use as a default for handling that scenario, then it requires no special action on the part of the application. This could be done by defining a new color space or role, or by adding an alias to an existing color space.
However, the config author may want the application to ask the user to identify the color space rather than relying on a default. This is historically indicated by setting the "strictparsing" attribute of the config to "true".
So a possible recommendation for app developers would be to proceed as follows:
Simply pass the color space to OCIO. If the config author has defined "Unknown", it will be handled at that time.
If it doesn't match a color space in the config, the app could check if the string is "Unknown" and if so, then check the config's strictparsing attribute. If it's true, the app should ask the user to select a color space. (Though config authors should be aware that it won't always be possible for an app to ask a user or otherwise suspend processing.)
If strictparsing is false, the app could use the file's path in the File Rules to obtain a color space. Or if the file either doesn't have a path, or it seems inappropriate to use it, the app could simply use the color space for the default File Rule.
Any thoughts?
How should this be handled in the built-in ACES configs?
Should we add an "unknown" alias to the "raw" colorspace, so nothing happens by default if other heuristics fail? it would mean that other heuristics would need to happen before checking the config? Hmmmm.
In the ASWF Color Interop Forum recommendations, there is a color space "Unknown". This is intended to be used by application developers when they need to set the color space metadata in some file format if they don't actually know what the real color space is. This is intended to help avoid the common problem where developers simply "guess" and set something that turns out to be wrong.
The question then is what should happen when reading a file that is tagged with the color space "Unknown"?
If config authors include "Unknown" in their config pointing to whatever color space they want to use as a default for handling that scenario, then it requires no special action on the part of the application. This could be done by defining a new color space or role, or by adding an alias to an existing color space.
However, the config author may want the application to ask the user to identify the color space rather than relying on a default. This is historically indicated by setting the "strictparsing" attribute of the config to "true".
So a possible recommendation for app developers would be to proceed as follows:
Any thoughts?
How should this be handled in the built-in ACES configs?