2013/5/10 Robert Quattlebaum <da...@deepdarc.com>
>
> 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.
>
What's behind of that misconception is just my ignorance. Yes, color
picker is the one that has to be fixed. I just used the gamma calibration
widget to correct the color picker compatibility. In fact I was using the
gamma calibration widget to perform that inverse of the monitor
compensation you mention below. That's absurd.
> 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 <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
> 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
>
>
--
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
