Hi Robert,
First, thank you for take your time on give us your vision and experience
on color management for Synfig.
Although I will need some time (and much reading!) to fully digest what you
say in your email, I would like to clarify a bit the mentioned "gamma
issue":
Basically what people complains about Synfig Studio is that the color
editor doesn't give the correct RGB representation that can be used in
other application (i.e. Gimp). So user picks up a color in Gimp and cannot
paste it to Synfig using the color editor and vice-versa. Only when
application gamma is set to 1.0 in all channels and when "visually linear"
is unchecked, then both coincide.
Also, if the user chooses to work with a gamma of 1.0 in the Synfig Studio,
the output render produced continue being with gamma 2.2 (because it is
currently hard coded to 2.2), so that becomes frustrating form the point of
view of the user.
We don't plan to change the internal color handling of Synfig but we want
to make the options of gamma correction consistent with the user selection
and improve the color representation for interoperability with other
applications.
With the useful information provided by you we would create a kind of
specifications for Synfig color management before start coding anything. I
would need to have a visual flow diagram of color information flow between
inputs(image files or color data), internals of Synfig computations
(blending operations and color interpolations in gradients) and outputs
(image files and devices).
Anyway I think that just "unhardcoding" the gamma conversion for output and
input and improving the color editor (to do the right color encoding
depending on what's the input of the user) as a first step, would improve a
lot the user experience.
Of course, all the changes should consider the different options for
internal color handling of specific layers (like gradients) and the Synfig
color profile that Timotheé suggested in the previous emails.
As aside note, during the recent Cairo render implementation I've made,
I've noticed that gradients in Cairo doesn't behave like gradients in
Synfig when they have transparencies. Cairo render uses its own gradients
interpolation and its own color blending that I use when possible. It is
related to the visually linear color selection option and the hard coded
2.2 gamma mentioned before. Internally, in Cairo the colors are alpha
premultiplied and in Synfig not. Possibly that, combined with the visually
linear color selection makes the difference. Unfortunately I cannot tweak
Cairo gradients results since it relies on external libraries.
Cheers!
2013/5/10 Robert Quattlebaum <[email protected]>
> Howdy everyone.
>
> On May 7, 2013, at 4:32 AM, Carlos López González <[email protected]>
> 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 <http://en.wikipedia.org/wiki/Rec._709> color
> primaries, (The same ones that sRGB <http://en.wikipedia.org/wiki/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 <http://en.wikipedia.org/wiki/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<http://en.wikipedia.org/wiki/Adobe_RGB_color_space>,
> or even BetaRGB <http://www.brucelindbloom.com/index.html?BetaRGB.html>),
> 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<http://en.wikipedia.org/wiki/CIELAB>
> colorspace
> - Perceptually Uniform by mixing in the
> CIELUV<http://en.wikipedia.org/wiki/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 <http://en.wikipedia.org/wiki/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
>
>
>
--
Carlos
http://synfig.org
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/synfig-devl
