I find the Blender color Management a bit messy and full of non standard options.
Colorspace naming
is a total mess across all various softwares unfortunately…
A clean, complete yet simple way to name a colorspace is the following:
[gamut name] - [transform curve name]
(the gamut is made of 4 informations: 3 primaries and the white point coordinate)
Very strict consistency for naming colorspaces may make their name a bit longer but it eliminates all confusion, which is really needed.
examples:
sRGB - sRGB
sRGB - Rec709 (rec709 is based on sRGB gamut)
sRGB - linear
ACEScg - linear (or ‘AP1 - linear’ if you want to be completely correct, but that’s pushing it)
Raw - linear
Color management can be made VERY simple yet complete:
All you need is to specify:
Internal colorspace
Displace device colorspace
My proposition for internal colospace options:
sRGB - linear (the world most famous and used gamut)
ACEScg - linear (the best and most used in professional productions)
ACES2065-1 - linear (the ultimate colorspace, only useful for experimenting)
Raw - linear (for purely technical reasons)
All in linear only, why ? Because it’s simply stupid to work in any other mode than linear, so my turn to ask: why even bother offering an option that is only leading to bad practices and issues?
My proposition for display color space options:
sRGB - sRGB (most of commercial monitors)
sRGB - Rec709 (professional monitors)
Rec2020 - Rec2020 (4kTVs)
Raw - linear
(I might forget some here)
All other technical aspects should not be exposed because there are misleading and/or not useful.
Even in very professional software, the option are as simple as this because, this set tof option is simply what is needed.
I hope Blender devs can have a look and though about this, leading more people rending in the correct colorspace conditions and with way less technical issues as a result.
You will receive better answer if you mention related devs to the matter, for example @brecht, but I’m not sure if he is the one you should mention.
Writing out all this without reaching anyone, specially if it’s something too technical, will make this post to die unseen probably, I saw it right now just because you just wrote an answer to yourself, but I had no idea this thread existed at all, that’s why it’s better to mention matter related devs or users, you will for sure receive feedback
(keep in mind that this forum is very active and there are tons of comments on a daily basis, a post will go unseen easily)
There are plans to upgrade the standard configuration to add more color spaces. I would add P3 to the list of displays color spaces you listed, since it’s pretty common. I’d expect a modern professional monitor to have a wider gamut like P3 rather than Rec.709.
It’s unclear what you mean regarding “internal color space”. There is no option in Blender to choose that, it’s controlled by the OpenColorIO configuration. From a practical point of view, the only scene linear color spaces that I think make sense to support by default are Rec.709 linear and ACEScg. Raw is non-color data so makes no sense, and a wide gamut like ACES2065-1 is not going to work well with various tools and not worth investing the time I think. Supporting more scene linear color spaces is challenging in terms of interop, since importers/exporters need to be adapted, .blend files are not reusable for different scene linear color spaces, etc.
Your explanation leaves out view transforms. The main reason more displays have not been added yet is because the Filmic view transform is hardcoded for sRGB, so it’s not trivial to use it for more displays. We plan to add the ACES RRT transform relatively soon, since it’s standard and can be more easily made to work for multiple displays.
As for the naming, improvements are possible but I disagree with most suggested changes.
Rec.709 came before sRGB. As I understand it, calling a display color spaces “sRGB - Rec709” is rather odd since that Rec.709 space is what was used for televisions before sRGB was introduced for computer monitors.
It would also be more correct to call the linear color space Rec.709 Linear, since the thing that distinguishes sRGB is the transfer curve, and it is not used for the linear color space.
Raw in Blender and other applications refers to non-color data. So it’s not “linear”, it’s not a color at all.
There is some motivation for calling the scene linear color space just “Linear”. It makes .blend files more reusable with different OpenColorIO configurations using the same conventions in some ways. It has downsides as well though, and arguably could be changed for clarity, or both could be available for different use cases.
There’s not a lot in the current configuration that I think can be left out easily, maybe one or two color spaces. For example the reason Log and DCI XYZ color spaces were added was because there was a need to output files with such color space for cinema projection.
Please have a look at Davinci Resolve. (It’s free for non commercial use)
For color spaces management they have a list of gamut + list of associated gamma
(ex sRGB/SRGB, Rec709/ Rec709 (maybe better than my proposition indeed), ACEScg/linear) It’s clean and near perfect.
It’s quite one of the best color grading piece of software in the industry, so no risk at having it as a reference.
I prefer having no transform curve option because they are bound to working color space and monitor.
Aces RRT is the obvious choice when working with ACES by example. But why not having it too.
See the red becomes orange and blue becomes purple, which is what Troy has been talking about it being broken.
Or are the official devs having different ideas? I am curious.
I have no real say in what gets included in Blender or not. I simply believe it’s a horrible idea to try and include an overly complex mess that doesn’t do anything as a subset, and instead encourage people to simply download and use the official repository.
It’s a bad idea, as we can already see with a broken variant of ACES lingering around in Blender forever. Flatly a poor decision.
