The interaction between anti-aliasing, transparency, and gamma-correction
Hi All,
This is my first post to this list, so I will keep things brief. First of all, I love Inkscape, and this is the reason for the message.
My tests indicate that, when rendering, Inkscape implements anti-aliasing and transparency directly in a gamma-corrected color-space. Am I right? It is my opinion that these operations should instead be performed in a linear color-space. Although it is now probably too late to change the default behavior of transparency (given that the artists used gamma-corrected blends as reference while creating their content), it is not too late to modify the behavior of anti-aliasing. Also, perhaps a tag could be used on future files to identify that they were created under the assumption of linear-blends.
Jim Blinn has a very good article on the subject:
Jim Blinn, 2003 "A Ghost in a Snow Storm", Jim Blinn's Corner: Notation, Notation, Notation, Chapter 9, pages 133--146, Morgan Kaufmann
There, he explains the problems that arise from performing blends in a non-linear space, in better words than I ever could. At any rate, I'd be happy to give examples and to elaborate on the topic once I receive a message that reassures me I am posting on the correct alias.
Kind regards and thank you for such a great tool, Diego
On 1/31/08, Lambisgoia <lambisgoia@...400...> wrote:
Hi All,
This is my first post to this list, so I will keep things brief. First of all, I love Inkscape, and this is the reason for the message.
My tests indicate that, when rendering, Inkscape implements anti-aliasing and transparency directly in a gamma-corrected color-space. Am I right? It is my opinion that these operations should instead be performed in a linear color-space. Although it is now probably too late to change the default behavior of transparency (given that the artists used gamma-corrected blends as reference while creating their content), it is not too late to modify the behavior of anti-aliasing.
AFAIK, we cannot really change the behavior of transparency because it is defined by SVG standard.
As for antialiasing, we can change it, but it would be very difficult to code because currently, pixel buffers for all objects are combined for the display, and this code cannot know whether a pixel's less-than-one alpha comes from an antialiasing edge or from the object's native transparency. Or even from both.
Just for reference: a recent bug (eventually marked invalid) in our tracker dealing with an interaction between color-correction and antialiasing: https://bugs.launchpad.net/inkscape/+bug/179283
On Jan 31, 2008 4:47 PM, Lambisgoia <lambisgoia@...400...> wrote:
Hi All,
This is my first post to this list, so I will keep things brief. First of all, I love Inkscape, and this is the reason for the message.
My tests indicate that, when rendering, Inkscape implements anti-aliasing and transparency directly in a gamma-corrected color-space. Am I right? It is my opinion that these operations should instead be performed in a linear color-space. Although it is now probably too late to change the default behavior of transparency (given that the artists used gamma-corrected blends as reference while creating their content), it is not too late to modify the behavior of anti-aliasing. Also, perhaps a tag could be used on future files to identify that they were created under the assumption of linear-blends.
Jim Blinn has a very good article on the subject:
Jim Blinn, 2003 "A Ghost in a Snow Storm", Jim Blinn's Corner: Notation, Notation, Notation, Chapter 9, pages 133--146, Morgan KaufmannThere, he explains the problems that arise from performing blends in a non-linear space, in better words than I ever could. At any rate, I'd be happy to give examples and to elaborate on the topic once I receive a message that reassures me I am posting on the correct alias.
Kind regards and thank you for such a great tool, Diego
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi,
AFAIK, we cannot really change the behavior of transparency because it is defined by SVG standard.
I am not a specialist, but my reading of the SVG 1.1 standard is that all input colors are specified in sRGB. The sRGB standard itself, under section "Alpha Channel Masking and Computer Graphics Compatibility", suggests that "effects such as alpha masking be performed either prior to encoding or by decoding to a color resolution greater than 24 bits and then converting into linear intensity space."
Section 14.2 of SVG 1.1 defines the widely known pre-multiplied alpha formulas for alpha blending. That section does not explicitly require the involved colors to be in the non-linear space. Although it is a bit of a stretch, if we were to follow the sRGB standard recommendation, we would convert to linear intensities when the element colors are determined, and convert back to sRGB before the pixel values are written to the frame-buffer or to an image file.
In any case, it does not matter what the standard says. What matters is what people have come to expect from it. I am therefore not suggesting for anything to be changed abruptly. I am just pointing out the issue, and suggesting that it be addressed in the future. I don't know which software is the "de facto" standard for SVG rendering, but I wouldn't be surprised if it is Inkscape. It is therefore suited to lead the effort.
As for antialiasing, we can change it, but it would be very difficult to code because currently, pixel buffers for all objects are combined for the display, and this code cannot know whether a pixel's less-than-one alpha comes from an antialiasing edge or from the object's native transparency. Or even from both.
I know nothing about the internals of Inkscape, so I will take your word for it. It would seem to me, though, that the pre-filtering coverage alpha (geometric: due to proximity with an edge, or a thin stroke) must be obtained independently from the color alpha (explicit: comes from the color server, and could even be pre-multiplied). Given two colors to be blended and a coverage alpha for the one on top, you can derive a blending formula that combines them so that the anti-aliasing part is done in linear space, but the transparency part is done in the non-linear space. This solves the anti-aliasing issues, preserving the current (in my opinion broken) behavior for transparency. This is in fact the compromise I have adopted.
Please see attached files. The "non-linear" version was produced by Inkscape. The "linear" version was produced by the method I described above. Compare them with the "point" version, which uses point sampling, and I hope it is clear which method is more accurate.
Naturally, it would be much cleaner to convert colors to linear space at load time, perform all operations in that space, and convert back to sRGB right before saving each pixel. Perhaps SVG 1.2 could address this issue? I do not know what is the best forum to suggest this.
Kind regards, Diego
participants (3)
-
bulia byak -
Lambisgoia -
Tom Davidson