missing window border on PNG images with transparency

[vinc17]

When I run the "display" command on a PNG file that has transparency (example of such a PNG file), the window border is displayed, then cleared after a fraction of second (it no longer appears). This is a Debian/unstable machine and my window manager is FVWM.

This problem has happened at least with IM 6.6.2.6 and later, but with a FVWM patch concerning XShape, the bug didn't occur with IM up to 6.6.9.7. However this patch has no effect with IM 6.7.4 (I don't know the status between these two versions). All the details are in my report of Debian bug 588537. According to the latest answer to this bug report, the bug would be in ImageMagick.

[magick]

We'll take a look but we have not touched the XWindow code in 15 years and we've never had a complaint about shaped windows. We're simply calling the X11 API to define a shaped window based on the transparency values.

[anthony]

The window border is missing as the image contains an alpha channel and as such may be a 'shaped' image. Shaped images does not need or want a window manager 'border' and as such does not request one.

"Display" in this case can do two things. Overlay the image on a checkerboard background (to denote transparent areas), or try the 'shape' the image. I think this depends on whether the image is an indexed or true color raster, as the former typically implied the image only uses boolean transparency, which "display" can handle on X windows servers ("display" predates the modern 'alpha transparency' modules of newer X servers).

[fmw42]

To complicate matters, on my Mac OSX Snow Leopard. I get either checkerboard window background or fully transparent window background depending upon image format and which display method.

convert logo: -transparent white 1tmp1.png
convert logo: -transparent white 1tmp1.gif

This gives checkerboard
display 1tmp1.png

But this gives transparent background (see though to desktop)
convert 1tmp1.png x:

And this also gives transparent background
display 1tmp1.gif

as does
convert 1tmp1.gif x:

show: is currently broken in the 6.7.6.10 beta, so I cannot test that.

Why are they not consistent and how can one tell the display system to always use a checkerboard?

[vinc17]

The window border is missing as the image contains an alpha channel and as such may be a 'shaped' image. Shaped images does not need or want a window manager 'border' and as such does not request one.

The window border is useful to be able to resize the window easily or to do other operations on the window (actually that's the way I configured my window manager). I don't see what you mean by "need" (I don't think any window really needs a border, a border being just a feature the end user wants or not). And as an end user, I want a window border for all images for the reason I've explained. If users want different behaviors, there should be a command-line option to control it, or let the window manager decide, as this was done up to IM 6.6.x.

"Display" in this case can do two things. Overlay the image on a checkerboard background (to denote transparent areas), or try the 'shape' the image. I think this depends on whether the image is an indexed or true color raster, as the former typically implied the image only uses boolean transparency, which "display" can handle on X windows servers ("display" predates the modern 'alpha transparency' modules of newer X servers).

Here I get the checkerboard background (and this is what I actually want).

[vinc17]

We'll take a look but we have not touched the XWindow code in 15 years and we've never had a complaint about shaped windows. We're simply calling the X11 API to define a shaped window based on the transparency values.

Well, the XWindow code (or something related to it) has been touched between IM 6.6.9.7 and IM 6.7.4, because the behavior has changed between these two versions.

[anthony]

The window border is missing as the image contains an alpha channel and as such may be a 'shaped' image. Shaped images does not need or want a window manager 'border' and as such does not request one.

The window border is useful to be able to resize the window easily or to do other operations on the window (actually that's the way I configured my window manager). I don't see what you mean by "need" (I don't think any window really needs a border, a border being just a feature the end user wants or not). And as an end user, I want a window border for all images for the reason I've explained. If users want different behaviors, there should be a command-line option to control it, or let the window manager decide, as this was done up to IM 6.6.x.

IM display is not the only one to do this. XMMS, GKrellM, and even Chrome (google web client) in some modes, mak ethe same 'no borders' request of the window manager.

[vinc17]

IM display is not the only one to do this. XMMS, GKrellM, and even Chrome (google web client) in some modes, mak ethe same 'no borders' request of the window manager.

I assume that the context is different: these other applications may do this request due to a user config choice, not because the file to open has some particularities. Even Chromium doesn't do this request to view the image given as an example.

[anthony]

IM display is not the only one to do this. XMMS, GKrellM, and even Chrome (google web client) in some modes, mak ethe same 'no borders' request of the window manager.

I assume that the context is different: these other applications may do this request due to a user config choice, not because the file to open has some particularities. Even Chromium doesn't do this request to view the image given as an example.

That is true, though it is more typically an application deveolpers choice. Most applications do allow you to turn it off.
Regardless you can override border handling using most (good) window managers.

More than likely display needs a overhaul. I would do it, but am re-doig the Shell API for IMv7. The command line handling of display will probably be part of this, but not for some time, and I did not plan to go into actual display processing.

IM is open source, you are welcome to have a look and send us patches.

[vinc17]

That is true, though it is more typically an application deveolpers choice. Most applications do allow you to turn it off.

Yes, that's why I've suggested an option for "display".

Regardless you can override border handling using most (good) window managers.

I could do this with a patched fvwm up to IM 6.6.x, but it seems that IM 6.7.4 bypasses the window manager settings! Here's my bug report in the Debian BTS and the discussion:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588537

More than likely display needs a overhaul. I would do it, but am re-doig the Shell API for IMv7. The command line handling of display will probably be part of this, but not for some time, and I did not plan to go into actual display processing.

OK.

IM is open source, you are welcome to have a look and send us patches.

It would be nice to know which change between 6.6.9.7 and 6.7.4 could trigger the problem. Otherwise I'll have to bissect using the source via Subversion.

[anthony]

Their were a log of changes between those versions, mostly to do with colorspace changes. It may be that the change has cause some switch in "display" but I am only guessing really.

I do know that typically PNG images were displayed with a checkerboard transparency as it involved semi-transparency, while GIF and PNG8 used a palette with boolean (purely on/off) transparency. X servers without 'modern' extensions could only handle boolean, for shaped windows.

One OLD solution was to use something like...
convert image -type TrueColorAlpha miff:- | display -

See IM Examples, Basics, Display, Transparency Handling -- where I noted this - though even that appears to have changed.
http://www.imagemagick.org/Usage/basics/#display

[fmw42]

See IM Examples, Basics, Display, Transparency Handling -- where I noted this - though even that appears to have changed.
http://www.imagemagick.org/Usage/basics/#display

-texture no longer seems to work fully with display and png images. The change to granite: only shows in one quadrant. In fact, it is no longer listed at http://www.imagemagick.org/script/display.php

In fact your solution currently gives an error.


display logo2t.gif -type truecoloralpha miff:- | display -
display: no decode delegate for this image format `/tmp/magick-3kkSo666' @ error/constitute.c/ReadImage/544.

seems like truecolormatte no longer works and needs to be truecoloralpha. I thought it would be deprecated and not deleted. But that does not work to put the checkerboard behind.

display logo2t.gif -type truecoloralpha miff:- | display -

The above is still transparent

[broucaries]

Any news of this bug ?

Bastien

[broucaries]

Ping ?

[broucaries]

One year latter ping