Howdy everyone.
On May 7, 2013, at 4:32 AM, Carlos López González <genet...@gmail.com> 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
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Synfig-devl mailing list
Synfig-devl@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synfig-devl
