GNU bug report logs - #37153
26.1; some png images scrambled on Windows

Previous Next

To reply to this bug, email your comments to 37153 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1; some png images scrambled
Date: Thu, 22 Aug 2019 23:49:00 -0500

[Message part 1 (text/plain, inline)]

put attached file into ~/picture.png
start emacs -Q
evaluate
(insert-image (create-image "~/picture.png"))
The image is scrambled.  With imagemagick the image displays correctly
(insert-image (create-image "~/picture.png" 'imagemagick))
Of course, not all png images are scrambled.  So it seems to be a bug
that is triggered only by certain png images.


In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2018-05-29 built on regnitz
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description:	Ubuntu 16.04.6 LTS

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 THREADS LCMS2

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: 
  locale-coding-system: utf-8-unix

Major mode: Fundamental

[picture.png (image/png, inline)]

Message #8 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 37153 <at> debbugs.gnu.org
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Fri, 23 Aug 2019 11:47:24 +0300

> Date: Thu, 22 Aug 2019 23:49:00 -0500
> From: "Roland Winkler" <winkler <at> gnu.org>
> 
> put attached file into ~/picture.png
> start emacs -Q
> evaluate
> (insert-image (create-image "~/picture.png"))
> The image is scrambled.  With imagemagick the image displays correctly
> (insert-image (create-image "~/picture.png" 'imagemagick))
> Of course, not all png images are scrambled.  So it seems to be a bug
> that is triggered only by certain png images.

Are you sure this is not a libpng bug?

Message #11 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37153 <at> debbugs.gnu.org
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Fri, 23 Aug 2019 06:39:10 -0500

On Fri Aug 23 2019 Eli Zaretskii wrote:
> Are you sure this is not a libpng bug?

No, I do not know the culprit.  How can I find out?

(On my GNU/linux computer, eog displays the image correctly.  Which
other software uses libpng similar to emacs?)

Message #14 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 37153 <at> debbugs.gnu.org
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Fri, 23 Aug 2019 15:22:03 +0300

> Date: Fri, 23 Aug 2019 06:39:10 -0500
> From: "Roland Winkler" <winkler <at> gnu.org>
> Cc: 37153 <at> debbugs.gnu.org
> 
> On Fri Aug 23 2019 Eli Zaretskii wrote:
> > Are you sure this is not a libpng bug?
> 
> No, I do not know the culprit.  How can I find out?

By asking on the libpng-related forum (assuming there is such a
thing)?

> (On my GNU/linux computer, eog displays the image correctly.  Which
> other software uses libpng similar to emacs?)

I don't know.  Anyone?

Message #17 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37153 <at> debbugs.gnu.org
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Fri, 23 Aug 2019 10:07:52 -0500

On Fri Aug 23 2019 Eli Zaretskii wrote:
> > No, I do not know the culprit.  How can I find out?
> 
> By asking on the libpng-related forum (assuming there is such a
> thing)?
> 
> > (On my GNU/linux computer, eog displays the image correctly.  Which
> > other software uses libpng similar to emacs?)
> 
> I don't know.  Anyone?

See

https://sourceforge.net/p/png-mng/mailman/message/36746994/

Message #20 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 37153 <at> debbugs.gnu.org
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Fri, 23 Aug 2019 18:34:09 +0300

> Date: Fri, 23 Aug 2019 10:07:52 -0500
> From: "Roland Winkler" <winkler <at> gnu.org>
> Cc: 37153 <at> debbugs.gnu.org
> 
> https://sourceforge.net/p/png-mng/mailman/message/36746994/

Thanks, let's see what this brings up.

Message #23 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Roland Winkler <winkler <at> gnu.org>
Cc: 37153 <at> debbugs.gnu.org
Subject: 26.1; some png images scrambled
Date: Fri, 23 Aug 2019 12:37:12 -0700

[Message part 1 (text/plain, inline)]

I didn't reproduce the problem with Emacs master on Ubuntu 18.04.3 LTS. The 
Emacs display agrees with the Gimp's display of that tiny image. Also, the rpng 
test program of the librpng 1.6.37 (the current version) also displays the image 
the same way. I had to patch librpng with the attached to get the test program 
to compile.

Do you see the same problem when using Emacs master? If not, then perhaps we can 
just marked the bug as fixed in the next release.

[libpng.patch (text/x-patch, attachment)]

Message #26 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 37153 <at> debbugs.gnu.org, winkler <at> gnu.org
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Fri, 23 Aug 2019 23:11:46 +0300

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 23 Aug 2019 12:37:12 -0700
> Cc: 37153 <at> debbugs.gnu.org
> 
> I didn't reproduce the problem with Emacs master on Ubuntu 18.04.3 LTS. The 
> Emacs display agrees with the Gimp's display of that tiny image. Also, the rpng 
> test program of the librpng 1.6.37 (the current version) also displays the image 
> the same way. I had to patch librpng with the attached to get the test program 
> to compile.

Please show the screenshot of the image as you saw it.  Otherwise,
it's hard to understand what do you mean by "not reproducing" the
problem.

Thanks.

Message #29 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37153 <at> debbugs.gnu.org, winkler <at> gnu.org
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Fri, 23 Aug 2019 13:33:11 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii wrote:
> Please show the screenshot of the image as you saw it.

My screenshot software outputs .png so if there's a problem with the original 
.png image there will quite possibly be a problem with the screenshot too. But 
anyway, attached is a screenshot of how Gimp displays the test image, magnified 
16x. The checkerboard is how Gimp displays absent parts of the image, and the 
gray frame around the edge is also part of Gimp and not part of the image.

[Screenshot from 2019-08-23 13-29-06.png (image/png, attachment)]

Message #32 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 37153 <at> debbugs.gnu.org
Subject: Re: 26.1; some png images scrambled
Date: Fri, 23 Aug 2019 22:17:58 -0500

On Fri Aug 23 2019 Paul Eggert wrote:
> Do you see the same problem when using Emacs master? If not, then
> perhaps we can just marked the bug as fixed in the next release.

The problem with my test png image is that it has transparent parts
that need to be displayed with a light color so that one can
recognize the nontransparent dark parts.  But the image uses fully
transparent black as background.  The behavior in such a case is not
strictly defined by the png standard, see

https://sourceforge.net/p/png-mng/mailman/message/36747189/

Emacs displays such fully transparent background with its original
color specified by the image.  But I believe it would make more
sense if emacs used instead a background color that the user can
choose (the background color of the frame), similar to, for example,
eog.

Should I submit a separate feature request for this?

Message #35 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Roland Winkler <winkler <at> gnu.org>
Cc: 37153 <at> debbugs.gnu.org
Subject: Re: 26.1; some png images scrambled
Date: Fri, 23 Aug 2019 20:39:17 -0700

Roland Winkler wrote:
> I believe it would make more
> sense if emacs used instead a background color that the user can
> choose (the background color of the frame), similar to, for example,
> eog.
> 
> Should I submit a separate feature request for this?

Can you do this with faces? They let you specify background colors. (I don't use 
this stuff so you'll have to be the expert.)

If there's no way to do it in Emacs now, I suggest retitling this bug report and 
changing it to a feature request, which you can do as described here:

https://debbugs.gnu.org/server-control.html

Message #38 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 37153 <at> debbugs.gnu.org
Subject: Re: 26.1; some png images scrambled
Date: Fri, 23 Aug 2019 23:19:16 -0500

On Fri Aug 23 2019 Paul Eggert wrote:
> Can you do this with faces? They let you specify background
> colors. (I don't use this stuff so you'll have to be the expert.)

I am not an expert either.  When I created a buffer with my png
image plus ordinary text, I could change the background color of the
text via add-face-text-property.  But this did not affect the
background color of the image.  So I believe the answer is no.

> If there's no way to do it in Emacs now, I suggest retitling this
> bug report and changing it to a feature request, which you can do
> as described here:
> 
> https://debbugs.gnu.org/server-control.html

Thanks, I'll wait a day or two.  If nobody tells me that I have
overlooked something significant, I'll turn this bug report into a
feature request.

Message #41 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 37153 <at> debbugs.gnu.org, winkler <at> gnu.org
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Sat, 24 Aug 2019 08:51:13 +0300

> Cc: winkler <at> gnu.org, 37153 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 23 Aug 2019 13:33:11 -0700
> 
> Eli Zaretskii wrote:
> > Please show the screenshot of the image as you saw it.
> 
> My screenshot software outputs .png so if there's a problem with the original 
> .png image there will quite possibly be a problem with the screenshot too. But 
> anyway, attached is a screenshot of how Gimp displays the test image, magnified 
> 16x. The checkerboard is how Gimp displays absent parts of the image, and the 
> gray frame around the edge is also part of Gimp and not part of the image.

This is not how this should be displayed, AFAIU.  Try opening the same
image in Firefox, and you will see a much more reasonable display.  I
presume that's what the OP wanted.

Message #44 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 37153 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Sat, 24 Aug 2019 09:22:34 +0300

> Date: Fri, 23 Aug 2019 22:17:58 -0500
> From: "Roland Winkler" <winkler <at> gnu.org>
> Cc: 37153 <at> debbugs.gnu.org
> 
> The problem with my test png image is that it has transparent parts
> that need to be displayed with a light color so that one can
> recognize the nontransparent dark parts.  But the image uses fully
> transparent black as background.  The behavior in such a case is not
> strictly defined by the png standard, see
> 
> https://sourceforge.net/p/png-mng/mailman/message/36747189/
> 
> Emacs displays such fully transparent background with its original
> color specified by the image.  But I believe it would make more
> sense if emacs used instead a background color that the user can
> choose (the background color of the frame), similar to, for example,
> eog.

Please take a look at image.c in the PNG area: it includes quite a few
references to "transparent" and what we should be/are doing with that.

> Should I submit a separate feature request for this?

I don't think I understand the feature you want to request.  Please
don't forget that the same PNG image can be displayed on places that
have different background colors.  I also don't think I see the use
cases for such images in Emacs.

Message #47 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 37153 <at> debbugs.gnu.org, winkler <at> gnu.org
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Sat, 24 Aug 2019 09:26:13 +0300

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 23 Aug 2019 20:39:17 -0700
> Cc: 37153 <at> debbugs.gnu.org
> 
> Roland Winkler wrote:
> > I believe it would make more
> > sense if emacs used instead a background color that the user can
> > choose (the background color of the frame), similar to, for example,
> > eog.
> > 
> > Should I submit a separate feature request for this?
> 
> Can you do this with faces?

No, not AFAIK.

Message #50 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: mituharu <at> math.s.chiba-u.ac.jp
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 37153 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Sat, 24 Aug 2019 18:01:46 +0900

> On Fri Aug 23 2019 Paul Eggert wrote:
>> Do you see the same problem when using Emacs master? If not, then
>> perhaps we can just marked the bug as fixed in the next release.
>
> The problem with my test png image is that it has transparent parts
> that need to be displayed with a light color so that one can
> recognize the nontransparent dark parts.  But the image uses fully
> transparent black as background.  The behavior in such a case is not
> strictly defined by the png standard, see
>
> https://sourceforge.net/p/png-mng/mailman/message/36747189/
>
> Emacs displays such fully transparent background with its original
> color specified by the image.  But I believe it would make more
> sense if emacs used instead a background color that the user can
> choose (the background color of the frame), similar to, for example,
> eog.

I suspect there is a longstanding typo (or thinko) in PNG
transparency handling code.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

diff --git a/src/image.c b/src/image.c
index 81d8cb4e2b2..819e058f7e1 100644
--- a/src/image.c
+++ b/src/image.c
@@ -6680,7 +6680,7 @@ png_load_body (struct frame *f, struct image *img,
struct png_load_context *c)
   /* Create an image and pixmap serving as mask if the PNG image
      contains an alpha channel.  */
   if (channels == 4
-      && !transparent_p
+      && transparent_p
       && !image_create_x_image_and_pixmap (f, img, width, height, 1,
 					   &mask_img, 1))
     {

Message #53 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: mituharu <at> math.s.chiba-u.ac.jp
Cc: 37153 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, winkler <at> gnu.org
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Sat, 24 Aug 2019 13:17:31 +0300

> Date: Sat, 24 Aug 2019 18:01:46 +0900
> From: mituharu <at> math.s.chiba-u.ac.jp
> Cc: 37153 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
> 
> I suspect there is a longstanding typo (or thinko) in PNG
> transparency handling code.
> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu <at> math.s.chiba-u.ac.jp
> 
> diff --git a/src/image.c b/src/image.c
> index 81d8cb4e2b2..819e058f7e1 100644
> --- a/src/image.c
> +++ b/src/image.c
> @@ -6680,7 +6680,7 @@ png_load_body (struct frame *f, struct image *img,
> struct png_load_context *c)
>    /* Create an image and pixmap serving as mask if the PNG image
>       contains an alpha channel.  */
>    if (channels == 4
> -      && !transparent_p
> +      && transparent_p
>        && !image_create_x_image_and_pixmap (f, img, width, height, 1,
>  					   &mask_img, 1))
>      {
> 

That didn't change anything in how I see the image in question, FWIW.

Message #56 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37153 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, winkler <at> gnu.org
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Sun, 25 Aug 2019 13:19:24 +0900

[Message part 1 (text/plain, inline)]

On Sat, 24 Aug 2019 19:17:31 +0900,
Eli Zaretskii wrote:
> 
> > Date: Sat, 24 Aug 2019 18:01:46 +0900
> > From: mituharu <at> math.s.chiba-u.ac.jp
> > Cc: 37153 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
> > 
> > I suspect there is a longstanding typo (or thinko) in PNG
> > transparency handling code.
> > 
> > 				     YAMAMOTO Mitsuharu
> > 				mituharu <at> math.s.chiba-u.ac.jp
> > 
> > diff --git a/src/image.c b/src/image.c
> > index 81d8cb4e2b2..819e058f7e1 100644
> > --- a/src/image.c
> > +++ b/src/image.c
> > @@ -6680,7 +6680,7 @@ png_load_body (struct frame *f, struct image *img,
> > struct png_load_context *c)
> >    /* Create an image and pixmap serving as mask if the PNG image
> >       contains an alpha channel.  */
> >    if (channels == 4
> > -      && !transparent_p
> > +      && transparent_p
> >        && !image_create_x_image_and_pixmap (f, img, width, height, 1,
> >  					   &mask_img, 1))
> >      {
> > 
> 
> That didn't change anything in how I see the image in question, FWIW.

Attached is a screenshot on X11.  Probably W32 needs some more work.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

[tRNS.png (image/png, inline)]

Message #59 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: mituharu <at> math.s.chiba-u.ac.jp
Cc: 37153 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Sat, 24 Aug 2019 23:52:32 -0500

On Sat Aug 24 2019 mituharu <at> math.s.chiba-u.ac.jp wrote:
> I suspect there is a longstanding typo (or thinko) in PNG
> transparency handling code.

It may be helpful to check the "official" test-suite for PNG

http://www.schaik.com/pngsuite2011/pngsuite.html

which contains also png files with transparency

http://www.schaik.com/pngsuite2011/pngsuite_trn_png.html

Somehow emacs ignores the transparency for image type png, see for
example the file tm3n3p02.png with multiple levels of transparency.

Transparency is honored for these images when emacs uses imagemagick.

Message #62 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 37153 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Sun, 25 Aug 2019 15:58:27 +0900

On Sun, 25 Aug 2019 13:52:32 +0900,
Roland Winkler wrote:
> 
> On Sat Aug 24 2019 mituharu <at> math.s.chiba-u.ac.jp wrote:
> > I suspect there is a longstanding typo (or thinko) in PNG
> > transparency handling code.
> 
> It may be helpful to check the "official" test-suite for PNG
> 
> http://www.schaik.com/pngsuite2011/pngsuite.html
> 
> which contains also png files with transparency
> 
> http://www.schaik.com/pngsuite2011/pngsuite_trn_png.html
> 
> Somehow emacs ignores the transparency for image type png, see for
> example the file tm3n3p02.png with multiple levels of transparency.
> 
> Transparency is honored for these images when emacs uses imagemagick.

It seems to be necessary to look into the tRNS chunk data for paletted
images.  Again, W32 would need some more work.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

diff --git a/src/image.c b/src/image.c
index 81d8cb4e2b2..7f1561d7a68 100644
--- a/src/image.c
+++ b/src/image.c
@@ -6589,10 +6589,28 @@ png_load_body (struct frame *f, struct image *img, struct png_load_context *c)
 
   /* If image contains simply transparency data, we prefer to
      construct a clipping mask.  */
+  transparent_p = false;
   if (png_get_valid (png_ptr, info_ptr, PNG_INFO_tRNS))
-    transparent_p = 1;
-  else
-    transparent_p = 0;
+    {
+      if (color_type != PNG_COLOR_TYPE_PALETTE)
+	transparent_p = true;
+      else
+	{
+	  /* Paletted images can specify transparency levels. */
+	  png_bytep trans;
+	  int i, num_trans;
+
+	  if (png_get_tRNS (png_ptr, info_ptr, &trans, &num_trans, NULL)
+	      == PNG_INFO_tRNS)
+	    {
+	      for (i = 0; i < num_trans; i++)
+		if (!(trans[i] == 0 || trans[i] == 255))
+		  break;
+	      if (i == num_trans)
+		transparent_p = true;
+	    }
+	}
+    }
 
   /* This function is easier to write if we only have to handle
      one data format: RGB or RGBA with 8 bits per channel.  Let's
@@ -6680,7 +6698,7 @@ png_load_body (struct frame *f, struct image *img, struct png_load_context *c)
   /* Create an image and pixmap serving as mask if the PNG image
      contains an alpha channel.  */
   if (channels == 4
-      && !transparent_p
+      && transparent_p
       && !image_create_x_image_and_pixmap (f, img, width, height, 1,
 					   &mask_img, 1))
     {

Message #65 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 37153 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, winkler <at> gnu.org
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Sun, 25 Aug 2019 10:24:50 +0300

> Date: Sun, 25 Aug 2019 13:19:24 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: winkler <at> gnu.org,
> 	37153 <at> debbugs.gnu.org,
> 	eggert <at> cs.ucla.edu
> 
> > > --- a/src/image.c
> > > +++ b/src/image.c
> > > @@ -6680,7 +6680,7 @@ png_load_body (struct frame *f, struct image *img,
> > > struct png_load_context *c)
> > >    /* Create an image and pixmap serving as mask if the PNG image
> > >       contains an alpha channel.  */
> > >    if (channels == 4
> > > -      && !transparent_p
> > > +      && transparent_p
> > >        && !image_create_x_image_and_pixmap (f, img, width, height, 1,
> > >  					   &mask_img, 1))
> > >      {
> > > 
> > 
> > That didn't change anything in how I see the image in question, FWIW.
> 
> Attached is a screenshot on X11.  Probably W32 needs some more work.

I always see the 3rd image, no matter what face is specified, FWIW.

Message #68 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 37153 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Sun, 25 Aug 2019 07:19:09 -0500

On Sun Aug 25 2019 YAMAMOTO Mitsuharu wrote:
> It seems to be necessary to look into the tRNS chunk data for paletted
> images.  Again, W32 would need some more work.

Thank you, I can confirm that your patch works for me (under GNU
Linux), including the transparent images from the png test suite.

Message #71 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
 Roland Winkler <winkler <at> gnu.org>
Cc: 37153 <at> debbugs.gnu.org
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Sun, 25 Aug 2019 11:38:07 -0700

[Message part 1 (text/plain, inline)]

YAMAMOTO Mitsuharu wrote:

> It seems to be necessary to look into the tRNS chunk data for paletted
> images.  Again, W32 would need some more work.

Thanks, I confirmed that this fixes the misdisplay for me as well. I attempted 
to port it to w32 (as well as to unusual libpng builds that do not define 
PNG_tRNS_SUPPORTED) and installed the attached into master.

With this patch on Ubuntu 18.04.3 I always see the first image shown in your 
tRNS.pg screenshot <https://bugs.gnu.org/37153#56>. So it may be that more work 
needs to be done to support other faces. Still, this patch is an improvement so 
it's worth going in.

[0001-Fix-misdisplay-of-PNG-paletted-images.patch (text/x-patch, attachment)]

Message #74 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 37153 <at> debbugs.gnu.org, winkler <at> gnu.org, mituharu <at> math.s.chiba-u.ac.jp
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Sun, 25 Aug 2019 21:56:26 +0300

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 25 Aug 2019 11:38:07 -0700
> Cc: 37153 <at> debbugs.gnu.org
> 
> > It seems to be necessary to look into the tRNS chunk data for paletted
> > images.  Again, W32 would need some more work.
> 
> Thanks, I confirmed that this fixes the misdisplay for me as well. I attempted 
> to port it to w32 (as well as to unusual libpng builds that do not define 
> PNG_tRNS_SUPPORTED) and installed the attached into master.

Thanks, this builds on MS-Windows, but the display of that PNG image
is still incorrect.

My guess is that some changes are needed in
image_create_x_image_and_pixmap_1, where there's a separate
implementation for HAVE_NTGUI.  But I have no idea what changes are
needed there.

Message #77 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 37153 <at> debbugs.gnu.org, Roland Winkler <winkler <at> gnu.org>
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Mon, 26 Aug 2019 08:02:23 +0900

On Mon, 26 Aug 2019 03:38:07 +0900,
Paul Eggert wrote:
> 
> YAMAMOTO Mitsuharu wrote:
> 
> > It seems to be necessary to look into the tRNS chunk data for paletted
> > images.  Again, W32 would need some more work.
> 
> Thanks, I confirmed that this fixes the misdisplay for me as well. I
> attempted to port it to w32 (as well as to unusual libpng builds that
> do not define PNG_tRNS_SUPPORTED) and installed the attached into
> master.
> 
> With this patch on Ubuntu 18.04.3 I always see the first image shown
> in your tRNS.pg screenshot <https://bugs.gnu.org/37153#56>. So it may
> be that more work needs to be done to support other faces. Still, this
> patch is an improvement so it's worth going in.

At least, your patch misses the case of non-paletted transparent PNGs
(tb???c?? in http://www.schaik.com/pngsuite2011/pngsuite_trn_png.html).

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

diff --git a/src/image.c b/src/image.c
index 18495612e98..8c4ab096938 100644
--- a/src/image.c
+++ b/src/image.c
@@ -6598,15 +6598,19 @@ png_load_body (struct frame *f, struct image *img, struct png_load_context *c)
 # ifdef PNG_tRNS_SUPPORTED
   png_bytep trans_alpha;
   int num_trans;
-  if (png_get_tRNS (png_ptr, info_ptr, &trans_alpha, &num_trans, NULL)
-      && trans_alpha)
+  if (png_get_tRNS (png_ptr, info_ptr, &trans_alpha, &num_trans, NULL))
     {
-      int i;
-      for (i = 0; i < num_trans; i++)
-	if (0 < trans_alpha[i] && trans_alpha[i] < 255)
-	  break;
-      if (! (i < num_trans))
+      if (!trans_alpha)
 	transparent_p = true;
+      else
+	{
+	  int i;
+	  for (i = 0; i < num_trans; i++)
+	    if (0 < trans_alpha[i] && trans_alpha[i] < 255)
+	      break;
+	  if (! (i < num_trans))
+	    transparent_p = true;
+	}
     }
 # endif
 

Message #80 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 37153 <at> debbugs.gnu.org, Roland Winkler <winkler <at> gnu.org>
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Mon, 26 Aug 2019 08:06:05 +0900

On Mon, 26 Aug 2019 08:02:23 +0900,
YAMAMOTO Mitsuharu wrote:
> 
> On Mon, 26 Aug 2019 03:38:07 +0900,
> Paul Eggert wrote:
> > 
> > YAMAMOTO Mitsuharu wrote:
> > 
> > > It seems to be necessary to look into the tRNS chunk data for paletted
> > > images.  Again, W32 would need some more work.
> > 
> > Thanks, I confirmed that this fixes the misdisplay for me as well. I
> > attempted to port it to w32 (as well as to unusual libpng builds that
> > do not define PNG_tRNS_SUPPORTED) and installed the attached into
> > master.
> > 
> > With this patch on Ubuntu 18.04.3 I always see the first image shown
> > in your tRNS.pg screenshot <https://bugs.gnu.org/37153#56>. So it may
> > be that more work needs to be done to support other faces. Still, this
> > patch is an improvement so it's worth going in.
> 
> At least, your patch misses the case of non-paletted transparent PNGs
> (tb???c?? in http://www.schaik.com/pngsuite2011/pngsuite_trn_png.html).
 
And you would need to turn off font-lock-mode (or start Emacs with -D)
to replicate my tRNS.png screenshot.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Message #83 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 37153 <at> debbugs.gnu.org, Roland Winkler <winkler <at> gnu.org>
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Sun, 25 Aug 2019 16:39:11 -0700

[Message part 1 (text/plain, inline)]

YAMAMOTO Mitsuharu wrote:

> At least, your patch misses the case of non-paletted transparent PNGs
> (tb???c?? in http://www.schaik.com/pngsuite2011/pngsuite_trn_png.html).

Thanks for catching my mistake. I installed the attached patch, which is closer 
to the code you originally suggested. With it, displaying one of the images you 
suggested looks like the attached image; hope it's what you're looking for. (I 
disabled font-lock-mode as you also suggested.)

[0001-Fix-bug-with-non-paletted-transparent-PNGs.patch (text/x-patch, attachment)]

[display-tbrn2c08.png (image/png, attachment)]

Message #86 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 37153 <at> debbugs.gnu.org, Roland Winkler <winkler <at> gnu.org>,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Tue, 24 Sep 2019 18:23:58 +0200

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> Thanks for catching my mistake. I installed the attached patch, which
> is closer to the code you originally suggested. With it, displaying
> one of the images you suggested looks like the attached image; hope
> it's what you're looking for. (I disabled font-lock-mode as you also
> suggested.)

The PNGs in question display well for me as well, so was the conclusion
here that this is now fixed?

Except possibly on Windows?

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

Message #89 received at 37153 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 37153 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, winkler <at> gnu.org
Subject: Re: bug#37153: 26.1; some png images scrambled
Date: Tue, 24 Sep 2019 20:14:17 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Tue, 24 Sep 2019 18:23:58 +0200
> Cc: 37153 <at> debbugs.gnu.org, Roland Winkler <winkler <at> gnu.org>
> 
> The PNGs in question display well for me as well, so was the conclusion
> here that this is now fixed?
> 
> Except possibly on Windows?

Yes, they don't display correctly on Windows.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.