bug#36315: Incorrect SVG color

bug#36315: Incorrect SVG color

[Lars Ingebrigtsen]

Matt Huszagh <huszaghmatt@gmail.com> writes:

>> I can't reproduce the problem with the current Emacs trunk on Debian,
>> either, so I think you've fixed it.  :-)
>
> I'm experiencing this issue as well. The colors rendered by Emacs and
> librsvg are close but not exactly the same and the difference is noticeable
> particularly when placed side by side. I don't know much about these
> things, but is it possible that librsvg and Emacs use different color depths?

What Emacs version are you still seeing the problem in?

bug#36315: Incorrect SVG color

[Matt Huszagh]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> What Emacs version are you still seeing the problem in?

Ok, I apologize. I actually can't reproduce the issue either, though I
am noticing a color difference in certain other cases. I'll dig into
this more and create a new issue when I have a minimal example that can
reproduce it.

Matt

bug#36315: 27.0.50; SVG transparency handling is inaccurate

[Pip Cet]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

Evaluate the following in emacs -Q:

(require 'svg)

(defun make-image (color)
  (let ((svg (svg-create 100 100)))
    (svg-rectangle svg 0 0 100 100 :fill color)
    (svg-image svg)))

(set-frame-parameter (window-frame) 'background-color "black")

(insert (propertize " " 'display (make-image "#f00000")))

The expected result is a rectangle (on black background) of color
#f00000. The actual result is a rectangle of color #ef0000. For black
backgrounds, white is no longer representable.

This is related to bug #36304, but much easier to fix.

Patch attached.

[-- Attachment #2: 0001-SVG-scale-color-values-properly.patch --]
[-- Type: text/x-patch, Size: 1707 bytes --]

From 7abe6404d3af04db2f5a503c1c873f80ab86f69e Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@gmail.com>
Date: Thu, 20 Jun 2019 20:13:12 +0000
Subject: [PATCH] SVG: scale color values properly

* src/image.c (svg_load_image): scale color channel values to proper
range.
---
 src/image.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/src/image.c b/src/image.c
index 866323ba6e..6b6235a617 100644
--- a/src/image.c
+++ b/src/image.c
@@ -9658,17 +9658,20 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
       {
 	for (int x = 0; x < width; ++x)
 	  {
-	    int red     = *pixels++;
-	    int green   = *pixels++;
-	    int blue    = *pixels++;
-	    int opacity = *pixels++;
-
-	    red   = ((red * opacity)
-		     + (background.red * ((1 << 8) - opacity)));
-	    green = ((green * opacity)
-		     + (background.green * ((1 << 8) - opacity)));
-	    blue  = ((blue * opacity)
-		     + (background.blue * ((1 << 8) - opacity)));
+	    unsigned int red     = *pixels++;
+	    unsigned int green   = *pixels++;
+	    unsigned int blue    = *pixels++;
+	    unsigned int opacity = *pixels++;
+
+	    /* opacity and the color channel values are in the range {0..255},
+	     * but expected output values are in the range {0..65535}, so scale
+	     * by (256/255)^2. */
+#define MIX(a, b, opacity)						\
+	    (((((a) * opacity) + ((b) * (255 - opacity))) * 65535 + 32512) / 65025)
+	    red   = MIX (red, background.red, opacity);
+	    green = MIX (green, background.red, opacity);
+	    blue  = MIX (blue, background.red, opacity);
+#undef MIX
 
 	    PUT_PIXEL (ximg, x, y, lookup_rgb_color (f, red, green, blue));
 	  }
-- 
2.20.1

bug#36315: Incorrect SVG color

[Qiantan Hong]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

Is there any update on this bug?
The current behavior is unacceptable when the SVG color
is supposed to be the same as some color in Emacs
(in my case, I’m using SVG to build some UI elements),
The following code

(require 'svg)

(defun make-image (color)
  (let ((svg (svg-create 100 100)))
    (svg-rectangle svg 0 0 100 100 :fill color)
    (svg-image svg)))

(set-frame-parameter (window-frame) 'background-color “#f00000")

(insert (propertize " " 'display (make-image "#f00000")))

produce very notable color difference.


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#36315: Incorrect SVG color

[Alan Third]

On Fri, Dec 18, 2020 at 12:49:23AM +0000, Qiantan Hong wrote:
> Is there any update on this bug?
> The current behavior is unacceptable when the SVG color
> is supposed to be the same as some color in Emacs
> (in my case, I’m using SVG to build some UI elements),
> The following code
> 
> (require 'svg)
> 
> (defun make-image (color)
>   (let ((svg (svg-create 100 100)))
>     (svg-rectangle svg 0 0 100 100 :fill color)
>     (svg-image svg)))
> 
> (set-frame-parameter (window-frame) 'background-color “#f00000")
> 
> (insert (propertize " " 'display (make-image "#f00000")))
> 
> produce very notable color difference.

I can no longer replicate this on the master branch on macOS. We've
out-sourced colour handling fully to librsvg now, so that may make the
difference?

Either that or macOS is doing something unusual with colours, which I
wouldn't rule out.
-- 
Alan Third

bug#36315: Incorrect SVG color

[Qiantan Hong]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

I started to SEGFAULT when building from master branch
on macOS some time ago and now I’m doing
$ brew install emacs-plus —fetch-HEAD —with-xwidgets
The problem is there for me.
M-x emacs-version:
GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G6032)) of 2020-12-18

> On Dec 18, 2020, at 10:00 AM, Alan Third <alan@idiocy.org> wrote:
> 
> On Fri, Dec 18, 2020 at 12:49:23AM +0000, Qiantan Hong wrote:
>> Is there any update on this bug?
>> The current behavior is unacceptable when the SVG color
>> is supposed to be the same as some color in Emacs
>> (in my case, I’m using SVG to build some UI elements),
>> The following code
>> 
>> (require 'svg)
>> 
>> (defun make-image (color)
>>  (let ((svg (svg-create 100 100)))
>>    (svg-rectangle svg 0 0 100 100 :fill color)
>>    (svg-image svg)))
>> 
>> (set-frame-parameter (window-frame) 'background-color “#f00000")
>> 
>> (insert (propertize " " 'display (make-image "#f00000")))
>> 
>> produce very notable color difference.
> 
> I can no longer replicate this on the master branch on macOS. We've
> out-sourced colour handling fully to librsvg now, so that may make the
> difference?
> 
> Either that or macOS is doing something unusual with colours, which I
> wouldn't rule out.
> --
> Alan Third


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#36315: Incorrect SVG color

[Qiantan Hong]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

I suspect it is some weird thing about macOS,
because now the SVG color is brighter instead of darker...

> On Dec 18, 2020, at 10:00 AM, Alan Third <alan@idiocy.org> wrote:
> 
> On Fri, Dec 18, 2020 at 12:49:23AM +0000, Qiantan Hong wrote:
>> Is there any update on this bug?
>> The current behavior is unacceptable when the SVG color
>> is supposed to be the same as some color in Emacs
>> (in my case, I’m using SVG to build some UI elements),
>> The following code
>> 
>> (require 'svg)
>> 
>> (defun make-image (color)
>>  (let ((svg (svg-create 100 100)))
>>    (svg-rectangle svg 0 0 100 100 :fill color)
>>    (svg-image svg)))
>> 
>> (set-frame-parameter (window-frame) 'background-color “#f00000")
>> 
>> (insert (propertize " " 'display (make-image "#f00000")))
>> 
>> produce very notable color difference.
> 
> I can no longer replicate this on the master branch on macOS. We've
> out-sourced colour handling fully to librsvg now, so that may make the
> difference?
> 
> Either that or macOS is doing something unusual with colours, which I
> wouldn't rule out.
> --
> Alan Third


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#36315: Incorrect SVG color

[Qiantan Hong]

[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]

I fixed my build and it behaves correctly on macOS
now.

M-x emacs-version
GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G6032)) of 2020-12-18

To make sure I understand it, did we start outsourcing color some point after 27.1?


> On Dec 18, 2020, at 10:00 AM, Alan Third <alan@idiocy.org> wrote:
> 
> On Fri, Dec 18, 2020 at 12:49:23AM +0000, Qiantan Hong wrote:
>> Is there any update on this bug?
>> The current behavior is unacceptable when the SVG color
>> is supposed to be the same as some color in Emacs
>> (in my case, I’m using SVG to build some UI elements),
>> The following code
>> 
>> (require 'svg)
>> 
>> (defun make-image (color)
>>  (let ((svg (svg-create 100 100)))
>>    (svg-rectangle svg 0 0 100 100 :fill color)
>>    (svg-image svg)))
>> 
>> (set-frame-parameter (window-frame) 'background-color “#f00000")
>> 
>> (insert (propertize " " 'display (make-image "#f00000")))
>> 
>> produce very notable color difference.
> 
> I can no longer replicate this on the master branch on macOS. We've
> out-sourced colour handling fully to librsvg now, so that may make the
> difference?
> 
> Either that or macOS is doing something unusual with colours, which I
> wouldn't rule out.
> --
> Alan Third


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#36315: Incorrect SVG color

[Alan Third]

On Fri, Dec 18, 2020 at 04:42:03PM +0000, Qiantan Hong wrote:
> I fixed my build and it behaves correctly on macOS
> now.
> 
> M-x emacs-version
> GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G6032)) of 2020-12-18

Excellent! Thanks for letting us know.

> To make sure I understand it, did we start outsourcing color some point after 27.1?

We pass the foreground and background colours into librsvg, which
creates the bitmap image that's displayed, in a commit that's just a
few months old. It will appear in Emacs 28.

I don't expect the change to be included in Emacs 27 since it's a
fairly large change introducing a number of new features and any new
Emacs 27 releases will be primarily bug fixes.
-- 
Alan Third

bug#36315: Incorrect SVG color

[Alan Third]

On Fri, Dec 18, 2020 at 06:04:45PM +0000, Alan Third wrote:
> On Fri, Dec 18, 2020 at 04:42:03PM +0000, Qiantan Hong wrote:
> > I fixed my build and it behaves correctly on macOS
> > now.
> > 
> > M-x emacs-version
> > GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G6032)) of 2020-12-18
> 
> Excellent! Thanks for letting us know.
> 
> > To make sure I understand it, did we start outsourcing color some point after 27.1?
> 
> We pass the foreground and background colours into librsvg, which
> creates the bitmap image that's displayed, in a commit that's just a
> few months old. It will appear in Emacs 28.
> 
> I don't expect the change to be included in Emacs 27 since it's a
> fairly large change introducing a number of new features and any new
> Emacs 27 releases will be primarily bug fixes.

In a fit of over-excitement I closed this without checking whether
it's still a problem outside of the NS port. Should I reopen it?
-- 
Alan Third

bug#36315: Incorrect SVG color

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> In a fit of over-excitement I closed this without checking whether
> it's still a problem outside of the NS port. Should I reopen it?

I can't reproduce the problem with the current Emacs trunk on Debian,
either, so I think you've fixed it.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no