Re: [Synfig-devl] Synfig Color Management

[Robert Q. <da...@de...>]

Howdy everyone.

On May 7, 2013, at 4:32 AM, Carlos López González <gen...@gm...> wrote:

> Since it is planned for 0.64.1 to fix the "gamma issue" I asked to Timotheé Giet for help on that matter. 
> 
> I would like to write down a blueprint for color management in Synfig (and then fix the weirdness of the hardcored gamma) but due to my lack of knowledge I needed external help.
> 
> The idea is to do a first draft and refine it once I understand better what's done currently in the code and what should be done in general. 
> 
> Inputs are welcome!


For what it's worth, color theory just happens to be a topic I've become much more knowledgeable about in the 10 years (!!!!) since I started writing Synfig.

I've done what I call a "buddhist enlightenment cycle" regarding the evolution of my opinion of Synfig's color management. At first I thought it was great. Then, after I learned much more about the true nature of color, I realized that it was not so great. Now that I've learned even more, I've come to realize that the state of things isn't nearly as bad as I once thought.

Problems arise because the expected behavior wasn't well codified or explained, and the user interface wasn't terribly helpful at making this clear, either. I'll try to elaborate on the original intentions here and make some suggestions that might help address this "gamma" issue I keep hearing about.

For the record, the native colorspace of Synfig is:

ITU-R BT.709 color primaries, (The same ones that sRGB use)
The color channels are only quantized at output and are physically linear. (e.g. "1.0" is intended to have twice as many photons as "0.5") This has some very nice properties, which I'll go into later.
The colorspace is white-point independent. A value of "1.0" in all three color channels is defined to be "white". As a result, the white point of the output medium must be defined and adjusted appropriately. (Thinking back on this one, this aspect of the definition could probably use some more work)

Values for the individual channels are physically linear—a gamma of 1.0. This allows for colorimetrically correct mixing of colors. This is one of the reasons why antialiased edges look so good in Synfig. The idea is that gamma conversion (or, more appropriately, "colorspace conversion") is always performed on output. Having a physically linear native colorspace is a really really really good thing. Again, I'll elaborate on this in a moment.

Now, because we are using the Rec.709 chromaticities, you might expect for the gamut of Synfig to be no larger than that of Rec.709 or sRGB. This is, however, not the case. The gamut of Synfig's internal color format covers the entire gamut of human color vision. This is possible by allowing one or two of the components to go negative. If you want to represent a color that is out of the traditional Rec.709 gamut (and there are a *lot* of real colors that aren't in that gamut), you will need to drive some (but never all) of the channels negative. Microsoft and HP do a similar trick with scRGB. Since the native colorspace is physically linear, all of the math (blurring, for example) works out just fine.

Synfig's gamut practically unbounded and includes colors which are completely imaginary. These color values are still useful, however, for special effects.

If you would like to input colors from a larger colorspace (like Adobe RGB, or even BetaRGB), this is simply an exercise of extending the Color class to have the appropriate getters and setters that would to the conversion to and from the native colorspace transparently. I would recommend doing this rather than changing the native primaries.

(Despite the fact that Synfig's native colorspace has gamut that covers 100% of human vision, Synfig Studio (at least the last time I checked) doesn't support wide-gamut displays or do any sort of color correction to adjust for the monitor being used)

Now, what people aren't necessarily used to is the gamma of Synfig's native colorspace: A physically-linear 1.0 gamma. Doing this has tons of benefits. Here is a list of things that look great with a gamma of 1.0:

Soft shadows
Antialiasing
Image interpolation (both magnification and magnification)
Image compositing with or without an alpha channel

The problem with using a gamma of 1.0 in a tool intended for artists is that it isn't perceptually uniform. A value of twice the the intensity is perceived to be only about a fourth as bright to human vision. This is why I added the (somewhat misnamed) "Visually linear" option for the color picker, which basically applied a gamma shift to the color values from the color picker to make picking colors more perceptually uniform(which, by the way, is a much better term than "visually linear").

Adding the "visually linear" mode to the color picker settings was a good start, but this applied only to color selection. The colors, once selected, were still blended using the physically linear model. However, there are  a few cases where artists don't want physically linear color mixing. A great example is gradients.

I think a great step toward rectifying this would be to add the ability for certain types of layers to specify the color-mixing algorithm. The most obvious candidates are the gradient layers. Off the top of my head, I can imagine the following color mixing options being useful:

Physically Linear (what happens currently)
"sRGB" (which would be mixing the colors with a 2.2 gamma, similar to mixing colors in sRGB)
Perceptually Uniform by mixing in the CIELAB colorspace
Perceptually Uniform by mixing in the CIELUV colorspace

I think if this could be implemented and the default for gradient layers be set to 'sRGB' then this would alleviate much of the perceived "gamma issues" in Synfig. Note that in the absence of this parameter being specified when loading from SIF, it should default to Physically Linear, for backward-compatibility. sRGB-mixing should only be the default in newly created layers.

Additionally, it may be useful to change how the "Hue", "Saturation", and "Brightness" controls on the color picker work. First a little history and a confession: I arbitrarily chose the matrix for the "YUV" getters/setters. I can't even remember which matrix it was. It could have been Rec.601, or Rec.709. Whatever it was, I did it because I wanted a "hue" value for artists to be able to futz with (which I defined to be the arctangent of "U" and "V"). A noble goal, but not the best execution. In hindsight, I should have implemented the hue control to be based on CIELAB or CIELUV, which were designed to be perceptually uniform. This might be a worthwhile improvement for the color picker.

Now that I've said what I think should be done, here is what I think shouldn't be done:

Don't change the color primaries of the native color space. Rec.709/sRGB primaries are common and familiar to just about everyone and it in no way limits the gamut of Synfig. Other primaries can be supported as special-purpose constructors and getter/setters on the color class, or simply only implemented in a more advanced version of the color picker.
Don't change the native gamma. If you want to mix colors in way that is more perceptually uniform, implement a custom color-mixing mechanism for gradients or other layers that arbitrarily mix colors.

In summary, here are my recommendations to improve color support in Synfig:

Improve the color picker to allow for a more perceptually uniform color selection, perhaps by calculating the hue and saturation using CIELAB or CIELUV.
For layers which are arbitrarily (perhaps "artistically" is a better word?) mixing colors, the selection of a color mixing algorithm should be given. (Gradient layers would benefit hugely form this)
Add support for proper color correction to Synfig Studio instead of just basic gamma/white-point adjustments (which I assume haven't changed since I first wrote them). Specifically, wide-gamut displays should be supported. This is a complicated task because color management is handled differently on different operating systems.
Add wide-gamut support to more output formats. Supporting stuff like xvYCC would be trivial. Adding support for arbitrary color profiles (like Adobe RGB) in output standard image formats (JPEG, PNG, TIFF) would be a bit more difficult, but would still be worthwhile. OpenEXR was the only wide-gamut format that was supported back when I was coding all this stuff, but this may have changed.

That's what methinks, anyway. Feel free to implement or disregard at-will. :)

If you need any clarification, ask away.

Cheers!

-- Robert