~eliasnaur/gio

11 5

Proof of double gamma correction error with anti-aliasing

Details
Message ID
<569f628a-6ef2-d375-2718-70682fd8255c@meessen.net>
DKIM signature
pass
Download raw message
Hello,

The article referenced by Elias [1] was very instructive and gave me the 
idea to generate gray ramps with Gio to compare the result with what we 
should expect.

I created a small Gio test program that creates two horizontal ramps of 
32 gray values from black to white which could be easily compared with 
the reference ramp copied from the article. The top ramp creates the 
gray by using anti-aliasing. It draws a stack of short horizontal lines 
thinner than a pixel height. The covered height percentage determines 
the gray value. 50% should be perfectly mid-gray. This test the 
anti-aliasing and gamma correction applied on it. The ramp below is 
simply rectangles filled with a linear scale of gray values from 0 to 255.

The source code is available here [2].

The test result summary visible here [3] and explained below.

Ramps labelled ref are identical and correspond to the reference ramp. 
Ramps a and b are produced with the latest unmodified version of Gio 
code. Ramp c and d are the same ramps but with gamma correction disabled 
with the method suggested by Elias in a previous mail.

It is visible from this test result that the gamma correction is correct 
with rectangle filling (b), and incorrect with antia-liasing (a). The 
anti-aliasing ramp (a) is too white and explains the default seen in 
text rendering.

When disabling gamma correction, we see that the anti-aliasing ramp (c) 
becomes correct and that the rectangle filling ramp (d) is missing the 
gamma correction. From this test result we can deduce that the gamma 
correction is simply applied twice on anti-aliasing grays.

I only tested on my Ubuntu computer with a cheap graphic card. Feedback 
from other users with different types of OS and hardware might be useful 
to verify what I saw.

If I didn’t make a mistake in my code, I’m afraid that my assumption 
that there is a problem with anti-aliasing in general seam thus correct.

Side notes:

1. During this test I also noticed artifacts that shouldn’t be there. 
Some of them are visible in the screen capture on the left side of the 
ramps created with anti-aliasing (a and c). Some darker or clearer 
horizontal stripes are visible. They may be due to rounding errors or my 
cheap graphic card.

2. Worse. There was a problem in rendering the gray rectangles when the 
window is resized. A gap becomes visible. This problem is not 
negligible. I would like to know if other users see the same problem or 
if this is due to my OS/hardware, or a bug in the code.

3. There are still small differences in "correct" gray level with the 
reference. I would be curious to know if this could be due to a 
difference in gamma correction. It’s hard to tell by just looking at the 
gray ramps which one is right.

4. I’m interested in working on Gio and looking deeper in the rabbit 
hole of text rendering. There is stem hardening, color fonts (emoji), 
and sub-pixel rendering that is indispensable for contract fine prints 
;). I just saw that pathfinder has sub-pixel rendering for text [4]. 
We’ll see how far I get and how long my employer let me work on Gio.

5. While searching for info on stem darkening I heard about Raph 
Livien’s rust library [5] that is significantly faster than pathfinder’s 
implementation. Is the Gio community aware of it ?


[1] 
https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/

[2] https://github.com/chmike/testGioGamma

[3] https://imgur.com/h979iXI

[4] https://twitter.com/pcwalton/status/971475785616797698

[5] 
https://raphlinus.github.io/rust/graphics/gpu/2020/06/13/fast-2d-rendering.html

-- 
Bien cordialement,
Ch.Meessen
Details
Message ID
<O2Cc7gGwQo3Nufp-iDNcFiPIsZav5u9XN7w9kJF0COk3vmRnx10ZAvFLa7e3_0SWFBcOlBs5zvU6LiRdF-gY8bv__PDG6WeF7EYQVsLKGwM=@protonmail.ch>
In-Reply-To
<569f628a-6ef2-d375-2718-70682fd8255c@meessen.net> (view parent)
DKIM signature
pass
Download raw message
If it's rendering it and then reprocessing it that means it will be twice as fast
when the doubled work is eliminated, that might account for the performance difference?


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, 26 April 2021 17:33, Christophe Meessen <christophe@meessen.net> wrote:

> Hello,
> 

> The article referenced by Elias [1] was very instructive and gave me the
> idea to generate gray ramps with Gio to compare the result with what we
> should expect.
> 

> I created a small Gio test program that creates two horizontal ramps of
> 32 gray values from black to white which could be easily compared with
> the reference ramp copied from the article. The top ramp creates the
> gray by using anti-aliasing. It draws a stack of short horizontal lines
> thinner than a pixel height. The covered height percentage determines
> the gray value. 50% should be perfectly mid-gray. This test the
> anti-aliasing and gamma correction applied on it. The ramp below is
> simply rectangles filled with a linear scale of gray values from 0 to 255.
> 

> The source code is available here [2].
> 

> The test result summary visible here [3] and explained below.
> 

> Ramps labelled ref are identical and correspond to the reference ramp.
> Ramps a and b are produced with the latest unmodified version of Gio
> code. Ramp c and d are the same ramps but with gamma correction disabled
> with the method suggested by Elias in a previous mail.
> 

> It is visible from this test result that the gamma correction is correct
> with rectangle filling (b), and incorrect with antia-liasing (a). The
> anti-aliasing ramp (a) is too white and explains the default seen in
> text rendering.
> 

> When disabling gamma correction, we see that the anti-aliasing ramp (c)
> becomes correct and that the rectangle filling ramp (d) is missing the
> gamma correction. From this test result we can deduce that the gamma
> correction is simply applied twice on anti-aliasing grays.
> 

> I only tested on my Ubuntu computer with a cheap graphic card. Feedback
> from other users with different types of OS and hardware might be useful
> to verify what I saw.
> 

> If I didn’t make a mistake in my code, I’m afraid that my assumption
> that there is a problem with anti-aliasing in general seam thus correct.
> 

> Side notes:
> 

> 1.  During this test I also noticed artifacts that shouldn’t be there.
>     Some of them are visible in the screen capture on the left side of the
>     ramps created with anti-aliasing (a and c). Some darker or clearer
>     horizontal stripes are visible. They may be due to rounding errors or my
>     cheap graphic card.
>     

> 2.  Worse. There was a problem in rendering the gray rectangles when the
>     window is resized. A gap becomes visible. This problem is not
>     negligible. I would like to know if other users see the same problem or
>     if this is due to my OS/hardware, or a bug in the code.
>     

> 3.  There are still small differences in "correct" gray level with the
>     reference. I would be curious to know if this could be due to a
>     difference in gamma correction. It’s hard to tell by just looking at the
>     gray ramps which one is right.
>     

> 4.  I’m interested in working on Gio and looking deeper in the rabbit
>     hole of text rendering. There is stem hardening, color fonts (emoji),
>     and sub-pixel rendering that is indispensable for contract fine prints
>     ;). I just saw that pathfinder has sub-pixel rendering for text [4].
>     We’ll see how far I get and how long my employer let me work on Gio.
>     

> 5.  While searching for info on stem darkening I heard about Raph
>     Livien’s rust library [5] that is significantly faster than pathfinder’s
>     implementation. Is the Gio community aware of it ?
>     

>     [1]
>     https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/
>     

>     [2] https://github.com/chmike/testGioGamma
>     

>     [3] https://imgur.com/h979iXI
>     

>     [4] https://twitter.com/pcwalton/status/971475785616797698
>     

>     [5]
>     https://raphlinus.github.io/rust/graphics/gpu/2020/06/13/fast-2d-rendering.html
>     

>     --
>     Bien cordialement,
>     Ch.Meessen
>
Details
Message ID
<CAD+eXGQ8q1PtcucToCMysr4-KzU67RKYezh9jsC_rXHhZeOa8A@mail.gmail.com>
In-Reply-To
<569f628a-6ef2-d375-2718-70682fd8255c@meessen.net> (view parent)
DKIM signature
pass
Download raw message
On linux amdgpu:
1. I also see horizontal lines, they disappear if you run with
GIORENDERER=forcecompute
2. Gaps are there, yes. I think they appear on a mismatched aspect ratio.

On Mon, Apr 26, 2021 at 6:33 PM Christophe Meessen
<christophe@meessen.net> wrote:
>
> Hello,
>
> The article referenced by Elias [1] was very instructive and gave me the
> idea to generate gray ramps with Gio to compare the result with what we
> should expect.
>
> I created a small Gio test program that creates two horizontal ramps of
> 32 gray values from black to white which could be easily compared with
> the reference ramp copied from the article. The top ramp creates the
> gray by using anti-aliasing. It draws a stack of short horizontal lines
> thinner than a pixel height. The covered height percentage determines
> the gray value. 50% should be perfectly mid-gray. This test the
> anti-aliasing and gamma correction applied on it. The ramp below is
> simply rectangles filled with a linear scale of gray values from 0 to 255.
>
> The source code is available here [2].
>
> The test result summary visible here [3] and explained below.
>
> Ramps labelled ref are identical and correspond to the reference ramp.
> Ramps a and b are produced with the latest unmodified version of Gio
> code. Ramp c and d are the same ramps but with gamma correction disabled
> with the method suggested by Elias in a previous mail.
>
> It is visible from this test result that the gamma correction is correct
> with rectangle filling (b), and incorrect with antia-liasing (a). The
> anti-aliasing ramp (a) is too white and explains the default seen in
> text rendering.
>
> When disabling gamma correction, we see that the anti-aliasing ramp (c)
> becomes correct and that the rectangle filling ramp (d) is missing the
> gamma correction. From this test result we can deduce that the gamma
> correction is simply applied twice on anti-aliasing grays.
>
> I only tested on my Ubuntu computer with a cheap graphic card. Feedback
> from other users with different types of OS and hardware might be useful
> to verify what I saw.
>
> If I didn’t make a mistake in my code, I’m afraid that my assumption
> that there is a problem with anti-aliasing in general seam thus correct.
>
> Side notes:
>
> 1. During this test I also noticed artifacts that shouldn’t be there.
> Some of them are visible in the screen capture on the left side of the
> ramps created with anti-aliasing (a and c). Some darker or clearer
> horizontal stripes are visible. They may be due to rounding errors or my
> cheap graphic card.
>
> 2. Worse. There was a problem in rendering the gray rectangles when the
> window is resized. A gap becomes visible. This problem is not
> negligible. I would like to know if other users see the same problem or
> if this is due to my OS/hardware, or a bug in the code.
>
> 3. There are still small differences in "correct" gray level with the
> reference. I would be curious to know if this could be due to a
> difference in gamma correction. It’s hard to tell by just looking at the
> gray ramps which one is right.
>
> 4. I’m interested in working on Gio and looking deeper in the rabbit
> hole of text rendering. There is stem hardening, color fonts (emoji),
> and sub-pixel rendering that is indispensable for contract fine prints
> ;). I just saw that pathfinder has sub-pixel rendering for text [4].
> We’ll see how far I get and how long my employer let me work on Gio.
>
> 5. While searching for info on stem darkening I heard about Raph
> Livien’s rust library [5] that is significantly faster than pathfinder’s
> implementation. Is the Gio community aware of it ?
>
>
> [1]
> https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/
>
> [2] https://github.com/chmike/testGioGamma
>
> [3] https://imgur.com/h979iXI
>
> [4] https://twitter.com/pcwalton/status/971475785616797698
>
> [5]
> https://raphlinus.github.io/rust/graphics/gpu/2020/06/13/fast-2d-rendering.html
>
> --
> Bien cordialement,
> Ch.Meessen
>
Details
Message ID
<054583d5-bb9b-c26b-acb4-d4faa8765f39@meessen.net>
In-Reply-To
<CAD+eXGQ8q1PtcucToCMysr4-KzU67RKYezh9jsC_rXHhZeOa8A@mail.gmail.com> (view parent)
DKIM signature
pass
Download raw message
Le 27/04/2021 à 09:02, Konstantin Kulikov a écrit :
> On linux amdgpu:
> 1. I also see horizontal lines, they disappear if you run with
> GIORENDERER=forcecompute

This option froze then crashed my computer. It may be too much for my 
little graphic card.



The testGioGamma program has been updated into release v0.1.0. It now 
displays the reference gray ramp next to both ramps in the window. The 
code is a bit more idiomatic Gio I think, but still not using layouts.

To install the program execute "go install 
github.com/chmike/testGioGamma@latest"

You can run it with "testGioGamma".

If you already installed and tested the program you may have to do a "go 
clean -modcache" because I changed the module name. I apologize about that.

I tested it on macOs (non retina) and on Windows 10 and they all show 
the same display. Anti-aliasing gray bar is too white. The behavior of 
Gio is thus consistent across OSes.


-- 
Bien cordialement,
Ch.Meessen
Details
Message ID
<CAYL75EAXZ8F.3PC809UWUCH2Q@themachine>
In-Reply-To
<569f628a-6ef2-d375-2718-70682fd8255c@meessen.net> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
On Mon Apr 26, 2021 at 17:33, Christophe Meessen wrote:
> Hello,
>
> The article referenced by Elias [1] was very instructive and gave me the 
> idea to generate gray ramps with Gio to compare the result with what we 
> should expect.
>
> I created a small Gio test program that creates two horizontal ramps of 
> 32 gray values from black to white which could be easily compared with 
> the reference ramp copied from the article. The top ramp creates the 
> gray by using anti-aliasing. It draws a stack of short horizontal lines 
> thinner than a pixel height. The covered height percentage determines 
> the gray value. 50% should be perfectly mid-gray. This test the 
> anti-aliasing and gamma correction applied on it. The ramp below is 
> simply rectangles filled with a linear scale of gray values from 0 to 255.
>
> The source code is available here [2].
>
> The test result summary visible here [3] and explained below.
>
> Ramps labelled ref are identical and correspond to the reference ramp. 
> Ramps a and b are produced with the latest unmodified version of Gio 
> code. Ramp c and d are the same ramps but with gamma correction disabled 
> with the method suggested by Elias in a previous mail.
>
> It is visible from this test result that the gamma correction is correct 
> with rectangle filling (b), and incorrect with antia-liasing (a). The 
> anti-aliasing ramp (a) is too white and explains the default seen in 
> text rendering.
>
> When disabling gamma correction, we see that the anti-aliasing ramp (c) 
> becomes correct and that the rectangle filling ramp (d) is missing the 
> gamma correction. From this test result we can deduce that the gamma 
> correction is simply applied twice on anti-aliasing grays.
>
> I only tested on my Ubuntu computer with a cheap graphic card. Feedback 
> from other users with different types of OS and hardware might be useful 
> to verify what I saw.
>
> If I didn’t make a mistake in my code, I’m afraid that my assumption 
> that there is a problem with anti-aliasing in general seam thus correct.
>

Interesting demonstration program, thank you for creating it.

It took me a while to figure out, but I believe Gio's rendering of the
anti-aliased gradient is correct.

First, comparing the anti-aliased gradient with the others is
misleading, because they represent two different gradients: the
anti-aliased gradient show a linear gradient in terms of *emitted* light
intensity, the other gradients (including the reference) show a linear
gradient in terms of *perceived* light intensity.

In terms of "What Every Coder Should Know...", the AA gradient corresponds to
figure 1, while the others correspond to figure 2.

Then, to illustrate why the AA gradient is correct, consider the middle
rectangle in the AA gradient. It displays a white background with a
black rectangle on top. The rectangle covers half of the pixels which
corresponds to a blend operation with alpha=50%. Each pixel in the
rectangle should therefore end up a blend of 50% white and 50% black, or
in linear RGB space, R=G=B=0.5. However, the framebuffer is in the sRGB
colorspace, and 0.5 in sRGB is 0.5^(1∕2.2)≈0.72974. Compare figure 12
in "What Every Coder..." and the computation below it.

0.72974 mapped to the 0-255 range is 186, which is very close to the 188
value of the middle rectangle in the Gio render. Note that sRGB does not
use a gamma-value of exactly 2.2, which explains the difference.

> Side notes:
>
> 1. During this test I also noticed artifacts that shouldn’t be there. 
> Some of them are visible in the screen capture on the left side of the 
> ramps created with anti-aliasing (a and c). Some darker or clearer 
> horizontal stripes are visible. They may be due to rounding errors or my 
> cheap graphic card.
>
> 2. Worse. There was a problem in rendering the gray rectangles when the 
> window is resized. A gap becomes visible. This problem is not 
> negligible. I would like to know if other users see the same problem or 
> if this is due to my OS/hardware, or a bug in the code.
>

I haven't dug into the stripe artifacts, but they look like conflation
artifacts, caused by a 1 pixel overlap between rectangles. See[0].

> 4. I’m interested in working on Gio and looking deeper in the rabbit 
> hole of text rendering. There is stem hardening, color fonts (emoji), 
> and sub-pixel rendering that is indispensable for contract fine prints 
> ;). I just saw that pathfinder has sub-pixel rendering for text [4]. 
> We’ll see how far I get and how long my employer let me work on Gio.
>

Indeed, sub-pixel rendering is another feature Gio doesn't have. Note
that as far as I understand, Apple systems are moving away from
sub-pixel anti-aliasing.

> 5. While searching for info on stem darkening I heard about Raph 
> Livien’s rust library [5] that is significantly faster than pathfinder’s 
> implementation. Is the Gio community aware of it ?
>

Yes! I'm currently working on a Gio implementation for Raph's
piet-gpu[1] rasterizer. You can enable it on Linux and Android by
setting the `GIORENDERER` environment variable to `forcecompute`.
However, there are still GPU hang bugs in the implementation so it has
not been made the default yet.

Elias

[0] https://github.com/linebender/piet-gpu/issues/49
[1] https://github.com/linebender/piet-gpu
Details
Message ID
<dec56027-fb96-f35f-aac0-3a82f6dd87b6@meessen.net>
In-Reply-To
<CAYL75EAXZ8F.3PC809UWUCH2Q@themachine> (view parent)
DKIM signature
pass
Download raw message
Hello

I made another experiment. I created an SVG image with the two gray ramp 
[1][2]. Top ramp is the filled rectangles with linearly increasing gray 
value, and bottom ramp is the gray ramp produced by anti-aliasing.

The nice property of SVG is that we can test rendering with different 
vector 2D graphic library or systems and compare. The disadvantage is 
that it is sensitive to screen resolution and zooming. For the test to 
work properly the image must be viewed on a 72DPI screen and 100% scale.

Here is a list of systems I tested showing all the same result: 
identical linearly increasing gray ramps.

- Ubuntu (linux): firefox (skia), InkScape (cairo).

- macOS (mac Book air 2 non retina): firefox + safari

- Windows (old 72 DPI dell laptop): edge

Non standard results

- firefox on Windows has groups of AA rectangles with same gray value. 
This is because they don’t produce the full scale of gray for AA.

- iPhone 6sPlus safari: same gray value on both lines, but AA ramp 
displays some moiré effects probably due to retina display

- iPad safari: same as iPhone but with more visible moiré effect 
(probably due to screen size)

You are invited to look at the image and test by your self.

For me the conclusion is that the AA gray ramp must thus be linear gray 
and not what is actually produced by Gio, unless they are all wrong.

PS: I also tested with servo, the mozilla browser that is using 
pathfinder, but it my case it didn’t display any SVG images. My graphic 
card may be too weak.


[1] https://svgshare.com/i/Wkq.svg

[2] https://svgshare.com/s/Wkq

-- 
Bien cordialement,
Ch.Meessen
Details
Message ID
<CB0DOCPI0960.2R0QRKFSUN9LO@testmac>
In-Reply-To
<dec56027-fb96-f35f-aac0-3a82f6dd87b6@meessen.net> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
On Thu Apr 29, 2021 at 18:32 CEST, Christophe Meessen wrote:
> Hello
>
> I made another experiment. I created an SVG image with the two gray ramp 
> [1][2]. Top ramp is the filled rectangles with linearly increasing gray 
> value, and bottom ramp is the gray ramp produced by anti-aliasing.
>
> The nice property of SVG is that we can test rendering with different 
> vector 2D graphic library or systems and compare. The disadvantage is 
> that it is sensitive to screen resolution and zooming. For the test to 
> work properly the image must be viewed on a 72DPI screen and 100% scale.
>
> Here is a list of systems I tested showing all the same result: 
> identical linearly increasing gray ramps.
>
> - Ubuntu (linux): firefox (skia), InkScape (cairo).
>
> - macOS (mac Book air 2 non retina): firefox + safari
>
> - Windows (old 72 DPI dell laptop): edge
>
> Non standard results
>
> - firefox on Windows has groups of AA rectangles with same gray value. 
> This is because they don’t produce the full scale of gray for AA.
>
> - iPhone 6sPlus safari: same gray value on both lines, but AA ramp 
> displays some moiré effects probably due to retina display
>
> - iPad safari: same as iPhone but with more visible moiré effect 
> (probably due to screen size)
>
> You are invited to look at the image and test by your self.
>
> For me the conclusion is that the AA gray ramp must thus be linear gray 
> and not what is actually produced by Gio, unless they are all wrong.
>

They're not wrong according to the SVG specification, but they're all
blending in sRGB colorpsace which is faster, more widely supported, but
also incorrect (as explained in "What Every Coder...").

There is an SVG attribute to enable linear blending,
color-interpolation[0]. However, none of the browsers support it, and
neither does Inkscape. See also [1].

Note that color-interpolation-filters is supported in browsers and
defaults to linearRGB, but it only applies to filters, not blending.

Elias

[0] https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/color-interpolation
[1] http://tavmjong.free.fr/blog/?p=765
Alessandro Arzilli
Details
Message ID
<20210429182142.rixo2mdaenzt3qrv@kra>
In-Reply-To
<CB0DOCPI0960.2R0QRKFSUN9LO@testmac> (view parent)
DKIM signature
pass
Download raw message
Is it possible to selectively disable gamma correction on parts of the
scene? Given your second link it seems to me that the problem goes beyond
just text rendering, attempting to use gio to render PostScript, SVG or PDF
would all require workarounds for this, if I understand correctly. The
stem-widening for fonts wouldn't cover everything, just the most common
instance.

On Thu, Apr 29, 2021 at 07:19:31PM +0200, Elias Naur wrote:
> They're not wrong according to the SVG specification, but they're all
> blending in sRGB colorpsace which is faster, more widely supported, but
> also incorrect (as explained in "What Every Coder...").
> 
> There is an SVG attribute to enable linear blending,
> color-interpolation[0]. However, none of the browsers support it, and
> neither does Inkscape. See also [1].
> 
> Note that color-interpolation-filters is supported in browsers and
> defaults to linearRGB, but it only applies to filters, not blending.
> 
> Elias
> 
> [0] https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/color-interpolation
> [1] http://tavmjong.free.fr/blog/?p=765
Details
Message ID
<-tP_jPn6cRvuAIVzylO7bO97yBsXAm9ym9GTo_ULoj3cnx6SkMNwdf2lZDjrqYxXVxXhygPY2_6GzZeqKerrmnW9Rw2HlpxdbmiQ67K9p6s=@protonmail.ch>
In-Reply-To
<20210429182142.rixo2mdaenzt3qrv@kra> (view parent)
DKIM signature
pass
Download raw message
I just had a quick look at the second link from Elias' message and I was shocked to
be reading something about biological sensing that doesn't start by saying,
"Biological sensors can only detect something that is changing and the change rates
are generally logarithmic". Applies not only to sensing but also growth and almost 

everything you can measure is not linear. Hence gamma *curves* which are exponential.

0x111 to 0x222 RGB is not is not double the brightness unless your gamma is adjusted
correctly. As nice as it is, my Dell 24" IPS 4k display has terrible adjustments and
I can never get its color gamut to even near *any* other display. Well, thus the ease
with which this sort of problem emerges especially when using quick and dirty math
to improve performance. Which also suggests that it's very hard to judge whether the
algorithm is correct if the display isn't.


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, April 29, 2021 6:21 PM, Alessandro Arzilli <alessandro.arzilli@gmail.com> wrote:

> Is it possible to selectively disable gamma correction on parts of the
> scene? Given your second link it seems to me that the problem goes beyond
> just text rendering, attempting to use gio to render PostScript, SVG or PDF
> would all require workarounds for this, if I understand correctly. The
> stem-widening for fonts wouldn't cover everything, just the most common
> instance.
> 

> On Thu, Apr 29, 2021 at 07:19:31PM +0200, Elias Naur wrote:
> 

> > They're not wrong according to the SVG specification, but they're all
> > blending in sRGB colorpsace which is faster, more widely supported, but
> > also incorrect (as explained in "What Every Coder...").
> > There is an SVG attribute to enable linear blending,
> > color-interpolation[0]. However, none of the browsers support it, and
> > neither does Inkscape. See also [1].
> > Note that color-interpolation-filters is supported in browsers and
> > defaults to linearRGB, but it only applies to filters, not blending.
> > Elias
> > [0] https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/color-interpolation
> > [1] http://tavmjong.free.fr/blog/?p=765
Details
Message ID
<CB0ZJKSZF3J9.3MJ3CKRNHBGZE@themachine>
In-Reply-To
<20210429182142.rixo2mdaenzt3qrv@kra> (view parent)
DKIM signature
pass
Download raw message
On Thu Apr 29, 2021 at 20:21, Alessandro Arzilli wrote:
> Is it possible to selectively disable gamma correction on parts of the
> scene? Given your second link it seems to me that the problem goes beyond
> just text rendering, attempting to use gio to render PostScript, SVG or PDF
> would all require workarounds for this, if I understand correctly. The
> stem-widening for fonts wouldn't cover everything, just the most common
> instance.
>

Maybe? From my discussions with Raph, I got the impression that stem
widening is the best workaround, but perhaps there is a better way
given the flexibility of the compute pipeline.

Elias
Details
Message ID
<f3c97b17-b4c4-9ccb-7968-cd9016e75385@meessen.net>
In-Reply-To
<CB0ZJKSZF3J9.3MJ3CKRNHBGZE@themachine> (view parent)
DKIM signature
pass
Download raw message
Hello,

thank you very much Elias for taking the time to patiently respond to my 
experiment reports. I now understood. Gio is doing it right. I 
misinterpreted my"proofs".

Le 30/04/2021 à 12:27, Elias Naur a écrit :
> On Thu Apr 29, 2021 at 20:21, Alessandro Arzilli wrote:
>> Is it possible to selectively disable gamma correction on parts of the
>> scene? Given your second link it seems to me that the problem goes beyond
>> just text rendering, attempting to use gio to render PostScript, SVG or PDF
>> would all require workarounds for this, if I understand correctly. The
>> stem-widening for fonts wouldn't cover everything, just the most common
>> instance.
>>
> Maybe? From my discussions with Raph, I got the impression that stem
> widening is the best workaround, but perhaps there is a better way
> given the flexibility of the compute pipeline.
>
> Elias

I had the impression that Alessandro wanted to ask if Gio will plan to 
also have a rendering option to make it possible to render pdf and SVG 
in way consistent to what people are used to and might expect.

What is PathFinder doing about this ? Are they targeting to reproduce 
the common bogus web rendering familiar to users, are they planning to 
do it right, or are they planning to support both like SVG was specified 
to do ?

-- 

Bien cordialement,
Ch.Meessen
Details
Message ID
<CB1QEBUOLS5C.1EORZXW373VJS@testmac>
In-Reply-To
<f3c97b17-b4c4-9ccb-7968-cd9016e75385@meessen.net> (view parent)
DKIM signature
pass
Download raw message
On Fri Apr 30, 2021 at 14:58 CEST, Christophe Meessen wrote:
> Hello,
>
> thank you very much Elias for taking the time to patiently respond to my 
> experiment reports. I now understood. Gio is doing it right. I 
> misinterpreted my"proofs".
>
> Le 30/04/2021 à 12:27, Elias Naur a écrit :
> > On Thu Apr 29, 2021 at 20:21, Alessandro Arzilli wrote:
> >> Is it possible to selectively disable gamma correction on parts of the
> >> scene? Given your second link it seems to me that the problem goes beyond
> >> just text rendering, attempting to use gio to render PostScript, SVG or PDF
> >> would all require workarounds for this, if I understand correctly. The
> >> stem-widening for fonts wouldn't cover everything, just the most common
> >> instance.
> >>
> > Maybe? From my discussions with Raph, I got the impression that stem
> > widening is the best workaround, but perhaps there is a better way
> > given the flexibility of the compute pipeline.
> >
> > Elias
>
> I had the impression that Alessandro wanted to ask if Gio will plan to 
> also have a rendering option to make it possible to render pdf and SVG 
> in way consistent to what people are used to and might expect.
>
> What is PathFinder doing about this ? Are they targeting to reproduce 
> the common bogus web rendering familiar to users, are they planning to 
> do it right, or are they planning to support both like SVG was specified 
> to do ?
>

Good question, I don't know the answer. Pathfinder is targeting Firefox,
so they surely have some solution for the sRGB problem. Perhaps Pathfinder
simply offers a global option to work in sRGB colorspace.

Elias
Reply to thread Export thread (mbox)