bug#47040: 27.1; PNG binary transparency is ignored

bug#47040: 27.1; PNG binary transparency is ignored

[ynyaaa]

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


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.


[-- Attachment #2: transparent1.png --]
[-- Type: image/png, Size: 301 bytes --]

[-- Attachment #3: transparent2.png --]
[-- Type: image/png, Size: 302 bytes --]

[-- Attachment #4: Type: text/plain, Size: 3097 bytes --]



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))

bug#47040: 27.1; PNG binary transparency is ignored

[Lars Ingebrigtsen]

ynyaaa@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

bug#47040: 27.1; PNG binary transparency is ignored

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 10 Mar 2021 16:05:25 +0100
> Cc: 47040@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.

bug#47040: 27.1; PNG binary transparency is ignored

[Alan Third]

On Wed, Mar 10, 2021 at 05:14:09PM +0200, Eli Zaretskii wrote:
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Date: Wed, 10 Mar 2021 16:05:25 +0100
> > Cc: 47040@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

bug#47040: 27.1; PNG binary transparency is ignored

[Lars Ingebrigtsen]

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

Alan Third <alan@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:


[-- Attachment #2: Type: image/png, Size: 29678 bytes --]

[-- Attachment #3: Type: text/plain, Size: 104 bytes --]


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

bug#47040: 27.1; PNG binary transparency is ignored

[Stefan Kangas]

Alan Third <alan@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?

bug#47040: 27.1; PNG binary transparency is ignored

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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