The monitor gamma adjustment was never intended to be used as a way to change
the gamma of the native colorspace. The user "choosing to work with a gamma of
1.0" is a symptom of a huge problem. They aren't actually working at a gamma of
1.0, they are working on a completely misconfigured setup. If people are doing
this, then it means that the color picker needs to be fixed.
You could add an option for "color picker uses monitor colorspace", if what is
desired is colors from The Gimp being compatible with Synfig. When this option
would be selected, the color picker would then perform the inverse of the
monitor compensation to get the Synfig color value. This is the right way to do
it.
The "hard-coded" gamma of the output stages is because the native colorspace of
Synfig is physically linear. This is a good thing.
On May 10, 2013, at 2:59 AM, Carlos López González <genet...@gmail.com> wrote:
> 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 <da...@deepdarc.com>
> 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
>
>
>
>
>
> --
> 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
> Synfig-devl@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/synfig-devl
------------------------------------------------------------------------------
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
