* bug#36315: 27.0.50; SVG transparency handling is inaccurate
@ 2019-06-20 20:26 Pip Cet
2020-12-18 0:49 ` bug#36315: Incorrect SVG color Qiantan Hong
0 siblings, 1 reply; 10+ messages in thread
From: Pip Cet @ 2019-06-20 20:26 UTC (permalink / raw)
To: 36315
[-- 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
^ permalink raw reply related [flat|nested] 10+ messages in thread
* bug#36315: Incorrect SVG color
2019-06-20 20:26 bug#36315: 27.0.50; SVG transparency handling is inaccurate Pip Cet
@ 2020-12-18 0:49 ` Qiantan Hong
2020-12-18 15:00 ` Alan Third
0 siblings, 1 reply; 10+ messages in thread
From: Qiantan Hong @ 2020-12-18 0:49 UTC (permalink / raw)
To: 36315@debbugs.gnu.org
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#36315: Incorrect SVG color
2020-12-18 0:49 ` bug#36315: Incorrect SVG color Qiantan Hong
@ 2020-12-18 15:00 ` Alan Third
2020-12-18 15:47 ` Qiantan Hong
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Alan Third @ 2020-12-18 15:00 UTC (permalink / raw)
To: Qiantan Hong; +Cc: 36315@debbugs.gnu.org
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#36315: Incorrect SVG color
2020-12-18 15:00 ` Alan Third
@ 2020-12-18 15:47 ` Qiantan Hong
2020-12-18 15:51 ` Qiantan Hong
2020-12-18 16:42 ` Qiantan Hong
2 siblings, 0 replies; 10+ messages in thread
From: Qiantan Hong @ 2020-12-18 15:47 UTC (permalink / raw)
To: Alan Third; +Cc: 36315@debbugs.gnu.org
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#36315: Incorrect SVG color
2020-12-18 15:00 ` Alan Third
2020-12-18 15:47 ` Qiantan Hong
@ 2020-12-18 15:51 ` Qiantan Hong
2020-12-18 16:42 ` Qiantan Hong
2 siblings, 0 replies; 10+ messages in thread
From: Qiantan Hong @ 2020-12-18 15:51 UTC (permalink / raw)
To: Alan Third; +Cc: 36315@debbugs.gnu.org
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#36315: Incorrect SVG color
2020-12-18 15:00 ` Alan Third
2020-12-18 15:47 ` Qiantan Hong
2020-12-18 15:51 ` Qiantan Hong
@ 2020-12-18 16:42 ` Qiantan Hong
2020-12-18 18:04 ` Alan Third
2 siblings, 1 reply; 10+ messages in thread
From: Qiantan Hong @ 2020-12-18 16:42 UTC (permalink / raw)
To: Alan Third; +Cc: 36315@debbugs.gnu.org
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#36315: Incorrect SVG color
2020-12-18 16:42 ` Qiantan Hong
@ 2020-12-18 18:04 ` Alan Third
2020-12-18 18:16 ` Alan Third
0 siblings, 1 reply; 10+ messages in thread
From: Alan Third @ 2020-12-18 18:04 UTC (permalink / raw)
To: Qiantan Hong; +Cc: 36315@debbugs.gnu.org
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#36315: Incorrect SVG color
2020-12-18 18:04 ` Alan Third
@ 2020-12-18 18:16 ` Alan Third
2020-12-19 0:24 ` Lars Ingebrigtsen
0 siblings, 1 reply; 10+ messages in thread
From: Alan Third @ 2020-12-18 18:16 UTC (permalink / raw)
To: 36315
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-10-11 14:24 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CA+X8ke6WQrWqVUuE2a9=AqVT-XYov81dXFgPzj4iOXeNtHAK6g@mail.gmail.com>
2021-10-11 7:52 ` bug#36315: Incorrect SVG color Lars Ingebrigtsen
2021-10-11 14:24 ` Matt Huszagh
2019-06-20 20:26 bug#36315: 27.0.50; SVG transparency handling is inaccurate Pip Cet
2020-12-18 0:49 ` bug#36315: Incorrect SVG color Qiantan Hong
2020-12-18 15:00 ` Alan Third
2020-12-18 15:47 ` Qiantan Hong
2020-12-18 15:51 ` Qiantan Hong
2020-12-18 16:42 ` Qiantan Hong
2020-12-18 18:04 ` Alan Third
2020-12-18 18:16 ` Alan Third
2020-12-19 0:24 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).