GNU bug report logs - #47040
27.1; PNG binary transparency is ignored

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47040 in the body.
You can then email your comments to 47040 AT debbugs.gnu.org in the normal way.

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

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

From: ynyaaa <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; PNG binary transparency is ignored
Date: Wed, 10 Mar 2021 19:45:58 +0900

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

If a PNG file has a aplpha plain composeed of only 0 or 255,
its transparency is ignored.

The attached file transparent1.png is a red sqaure framed with a green
line, where red pixels have 0 for alpha value and green pixels have 255
for alpha value.
transparent2.png is a similar image, but the alpha values for green
pixels are 254.

Red pixels in the both images have 0 for alpha value, so they should be
transparent and invisible, but transparent1.png is displayed as a red
square with a green frame in a emacs buffer.

transparent2.png is displayed as a white square with a green frame as
expected.

When they are displayed in a chrome browser, inner squares of the both
images are displayed as transparent.

[transparent1.png (image/png, attachment)]

[transparent2.png (image/png, attachment)]

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

In GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
 of 2020-08-22 built on CIRROCUMULUS
Repository revision: 86d8d76aa36037184db0b2897c434cdaab1a9ae8
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.18363
System Description: Microsoft Windows 10 Pro (v10.0.1909.18363.1379)

Recent messages:

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(mule-util eieio-opt cl-extra speedbar sb-image ezimage dframe apropos
image-mode exif dired-aux gnutls network-stream nsm mailalias smtpmail
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs json map
misearch multi-isearch pp shadow sort mail-extr emacsbug message rmc
puny dired dired-loaddefs format-spec rfc822 mml mml-sec password-cache
epa derived epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date subr-x seq byte-opt gv bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils help-fns radix-tree cl-print debug
backtrace help-mode easymenu find-func cl-loaddefs cl-lib term/bobcat
japan-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 81166 41710)
 (symbols 48 9599 0)
 (strings 32 27679 2980)
 (string-bytes 1 803013)
 (vectors 16 15294)
 (vector-slots 8 285442 20934)
 (floats 8 48 289)
 (intervals 56 1355 1190)
 (buffers 1000 28))

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: ynyaaa <at> gmail.com
Cc: 47040 <at> debbugs.gnu.org
Subject: Re: bug#47040: 27.1; PNG binary transparency is ignored
Date: Wed, 10 Mar 2021 16:05:25 +0100

ynyaaa <at> gmail.com writes:

> Red pixels in the both images have 0 for alpha value, so they should be
> transparent and invisible, but transparent1.png is displayed as a red
> square with a green frame in a emacs buffer.
>
> transparent2.png is displayed as a white square with a green frame as
> expected.
>
> When they are displayed in a chrome browser, inner squares of the both
> images are displayed as transparent.

I'm unable to reproduce this in Emacs 27.1 in Debian/bullseye, so this
may be a Windows-specific problem.  It may also be fixed in Emacs 28,
since the transparency code has gotten a lot of work.  Would it be
possible for you to check in Emacs 28 whether this problem is still
present there?

If not, can somebody else with Windows and Emacs 28 check whether the
problem is still present?

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: ynyaaa <at> gmail.com, 47040 <at> debbugs.gnu.org
Subject: Re: bug#47040: 27.1; PNG binary transparency is ignored
Date: Wed, 10 Mar 2021 17:14:09 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed, 10 Mar 2021 16:05:25 +0100
> Cc: 47040 <at> debbugs.gnu.org
> 
> > Red pixels in the both images have 0 for alpha value, so they should be
> > transparent and invisible, but transparent1.png is displayed as a red
> > square with a green frame in a emacs buffer.
> >
> > transparent2.png is displayed as a white square with a green frame as
> > expected.
> >
> > When they are displayed in a chrome browser, inner squares of the both
> > images are displayed as transparent.
> 
> I'm unable to reproduce this in Emacs 27.1 in Debian/bullseye, so this
> may be a Windows-specific problem.  It may also be fixed in Emacs 28,
> since the transparency code has gotten a lot of work.  Would it be
> possible for you to check in Emacs 28 whether this problem is still
> present there?
> 
> If not, can somebody else with Windows and Emacs 28 check whether the
> problem is still present?

The problem is still present when using the default libpng, but not if
I use the w32 native image API.

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

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, ynyaaa <at> gmail.com, 47040 <at> debbugs.gnu.org
Subject: Re: bug#47040: 27.1; PNG binary transparency is ignored
Date: Wed, 10 Mar 2021 22:14:25 +0000

On Wed, Mar 10, 2021 at 05:14:09PM +0200, Eli Zaretskii wrote:
> > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > Date: Wed, 10 Mar 2021 16:05:25 +0100
> > Cc: 47040 <at> debbugs.gnu.org
> > 
> > > Red pixels in the both images have 0 for alpha value, so they should be
> > > transparent and invisible, but transparent1.png is displayed as a red
> > > square with a green frame in a emacs buffer.
> > >
> > > transparent2.png is displayed as a white square with a green frame as
> > > expected.
> > >
> > > When they are displayed in a chrome browser, inner squares of the both
> > > images are displayed as transparent.
> > 
> > I'm unable to reproduce this in Emacs 27.1 in Debian/bullseye, so this
> > may be a Windows-specific problem.  It may also be fixed in Emacs 28,
> > since the transparency code has gotten a lot of work.  Would it be
> > possible for you to check in Emacs 28 whether this problem is still
> > present there?
> > 
> > If not, can somebody else with Windows and Emacs 28 check whether the
> > problem is still present?
> 
> The problem is still present when using the default libpng, but not if
> I use the w32 native image API.

I see the same on NS, so it must be something wrong with the libpng
support code. Although I don't know why Lars doesn't see it on Debian.

I wonder if it's related to image.c:6909

    # ifdef PNG_tRNS_SUPPORTED

It looks like that is not defined here... I don't really understand
what the png code is doing with transparency.
-- 
Alan Third

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Third <alan <at> idiocy.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, ynyaaa <at> gmail.com, 47040 <at> debbugs.gnu.org
Subject: Re: bug#47040: 27.1; PNG binary transparency is ignored
Date: Thu, 11 Mar 2021 17:53:33 +0100

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

Alan Third <alan <at> idiocy.org> writes:

> I see the same on NS, so it must be something wrong with the libpng
> support code. Although I don't know why Lars doesn't see it on Debian.

I get the following:

[Message part 2 (image/png, inline)]

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

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

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Alan Third <alan <at> idiocy.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 47040 <at> debbugs.gnu.org, ynyaaa <at> gmail.com
Subject: Re: bug#47040: 27.1; PNG binary transparency is ignored
Date: Sun, 31 Oct 2021 07:49:16 -0700

Alan Third <alan <at> idiocy.org> writes:

> I see the same on NS, so it must be something wrong with the libpng
> support code. Although I don't know why Lars doesn't see it on Debian.
>
> I wonder if it's related to image.c:6909
>
>     # ifdef PNG_tRNS_SUPPORTED
>
> It looks like that is not defined here... I don't really understand
> what the png code is doing with transparency.

That was added in commit 8826beaf0066.  I think this if this is
undefined in your case, I think it could be a problem with your libpng
build, as Paul alludes to here:

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37153#71

As far as I can tell from here,

    https://github.com/mitsuba-renderer/libpng/search?q=PNG_tRNS_SUPPORTED

and here,

    https://github.com/mitsuba-renderer/libpng/blob/master/scripts/pnglibconf.h.prebuilt

libpng is built with PNG_tRNS_SUPPORTED by default.  So why is your
libpng not built with that?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: ynyaaa <at> gmail.com, Alan Third <alan <at> idiocy.org>,
 Eli Zaretskii <eliz <at> gnu.org>, 47040 <at> debbugs.gnu.org
Subject: Re: bug#47040: 27.1; PNG binary transparency is ignored
Date: Mon, 20 Jun 2022 11:46:09 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> That was added in commit 8826beaf0066.  I think this if this is
> undefined in your case, I think it could be a problem with your libpng
> build, as Paul alludes to here:
>
>     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37153#71
>
> As far as I can tell from here,
>
>     https://github.com/mitsuba-renderer/libpng/search?q=PNG_tRNS_SUPPORTED
>
> and here,
>
>     https://github.com/mitsuba-renderer/libpng/blob/master/scripts/pnglibconf.h.prebuilt

If I understand correctly, this means that the bug was in libpng (and
has been fixed there), so there's nothing much to do on the Emacs side
here, and I'm therefore closing this bug report.

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

Previous Next

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