Certain images with 1-bit-alpha channel lose their transparency

[anonymous]

With 4938/josm applied, images with none or full alpha transparency should work fine. Certain images (e.g. ./images/styles/standard/accommodation.png optimized with optipng -o7) are rendered opaque with a white background instead of transparent.

[anonymous]

They are not defect. They have been changed to no longer so omnipresent. If you have special problems with individual icons, name these problems directly and reopen the report.

[anonymous]

Ok, but i think they looks now terrible. For example the fuel sign have a white frayed border and if the background is black you can't see them very well.

[anonymous]

Some of the bad icons

[anonymous]

I'm 1/3 through the preset menu. Shall I continue to test every preset for the used icon and then look for icons that have no preset? Or do you see the problem and revert or fix the change that caused it?

[anonymous]

The change has been reverted to have a hotfix. Neverthelesse the reason is not yet fixed.

BTW: This is in no way a criticial bug. Even if it is major would be subject to discussion.

Error cause: When a PNG image has no alpha channel, JOSM takes the background as alpha channel and makes it transparent. The image optimization removed empty alpha channels from the icons thus triggering that bug in JOSM.

[carolus]

Replying to anonymous:

In the latest Version of JOSM all images with white background (telephon/toilets) are defect. (I think white is now transparent)

Both in JOSM 1043 and JOSM 1042 I see that nodes that are assigned amenity | toilets are not visible in the normal mode. Only in wireframe mode these nodes can be seen in the map window. I just entered a toilet once more where I knew I already entered one last week. Switching to wireframe mode I saw there already was a toilet node. So to save OSM from dublicate nodes, I think the priority should be increased.

[carolus]

Series of screen shots where we see that a toilet node is only visible in wire frame node.

[carolus]

Series of screen shots where we see that a toilet node is only visible in wire frame node.

[carolus]

Series of screen shots where we see that a toilet node is only visible in wire frame node.

[Hasienda]

another attempt to fix this by providing the same icons black on white without alpha channel found in ticket duplicate #1692

however, this is really annoying, to me too

Q.: I it really a problem to get hands on not-too-much optimized icons with alpha channel? I could make them from the bad ones with The GIMP on the fly ... (please ask hoff dot st at web dot de)

[bastiK]

Apparently this is fixed.

Some images are still without alpha channel, e.g. /transport/taxi.png, /misc/landmark/tower.png

However they are displayed correctly on the map.

Maybe the issue is still present for an OS other than Linux. Could someone please check on Windows?

[stoecker]

I think it depends on Java version. We didn't change anything regarding image display.

[bastiK]

42 of 523 images in
styles/standard have no Alpha channel:

./leisure/garden.png
./leisure/nature_reserve.png
./sport/bicycle.png
./sport/chess.png
./sport/centre.png
./sport/riding.png
./hunting_stand.png
./rendering/quarry2.png
./rendering/beach.png
./rendering/quarry.png
./nautical/lock_gate.png
./nautical/marina.png
./nautical/anchor.png
./sightseeing/archaeological.png
./vehicle/cattle_grid.png
./vehicle/motorbike.png
./vehicle/gate.png
./vehicle/car_sharing.png
./vehicle/toll_booth.png
./service/administration/court_of_law.png
./service/emergency_access_point.png
./health/eye_specialist.png
./historic/boundary_stone.png
./religion/muslim.png
./religion/hinduism.png
./religion/jainism.png
./transport/airport/terminal.png
./transport/airport/helipad.png
./transport/turntable.png
./transport/taxi.png
./transport/car.png
./money/bank/vr-bank.png
./misc/information/guidepost.png
./misc/landmark/power.png
./misc/landmark/power/hydro.png
./misc/landmark/survey_point.png
./misc/landmark/water_tower.png
./misc/landmark/tower.png
./misc/landmark/beacon.png
./education.png
./accommodation/camping.png
./accommodation/guest_house.png

Would it help to update them?

[Cobra]

Some of these images are looking rather ugly with the plain white background (imho), but working.

[stoecker]

I don't think this is fixed. We did not change a single bit of code for this. It can be it is a Java issue. If so, we need at least to find out and document when Java fixed it. Otherwise this issue still exists.

The included icons have always been adapted properly. Issue was always when optipng or pngcrush has been run to reduce icons size.

[xeen]

It isn’t fixed. If you optimize ./images/styles/standard/accommodation.png it will still get a transparent background. This may be fixed by using ImageIO.read instead of Toolkit.getDefaultToolkit().createImage in ImageProvider. While ImageIO works for images w/ or w/o alpha channel it does not work for images with only transparency (i.e. 1 bit alpha channel).

If you want to try it out yourself, the following three images should contain all cases:

• ./images/styles/standard/accommodation.png; image w/o alpha if optimized (use with node; tourism=hotel)
• ./images/styles/standard/sport/soccer.png; image w/ alpha (use with node; sport=soccer)
• ./images/presets/soccer.png; image with transparency (1 bit alpha) (see it in top layer presets menu)

[xeen]

hm… the 1 bit alpha bug seems to be present with createImage as well… so in other words: switching to ImageIO would fix some of the PNG alpha bugs…

[stoecker]

Maybe we also get rid of these spurious error messages in PNG code which appear sometimes?

[xeen]

I’m not sure which messages you are referring to? Anyway, I’ll attach the wip-patch shortly so you can try if it fixes those errors. It only changes how local images are loaded, but applying it to the other cases is trivial.

Given the large amount of 1-bit-alpha images, I’m not sure switching will be of any help. We still can’t run optipng on these images and I haven’t measured how large the impact would be if only the non-1-bit-alpha ones are optimized.

[xeen]

uses ImageIO for reading local files

[xeen]

List of 1-bit-alpha images (+command which finds them)

[stoecker]

See #2904.

[xeen]

I measured the time it takes to init the presets menu. The difference is negligible, so switching won’t regress startup time.

imageio   toolkit
1512 ms   1299 ms
1535 ms   1302 ms
1288 ms   1528 ms
1676 ms   1265 ms
1488 ms   1343 ms
1494 ms   1435 ms

1499 ms   1362 ms   AVG        
 114 ms     91 ms   STDDEV

Next up: space savings w/ non-1-bit-alpha PNGs optimized

[xeen]

7358312 josm-normal.jar
7338405 josm-opti-non1bitalpha.jar
7334603 josm-all-opti.jar

so 19907 bytes (~19 KiB) saved. Could save another 3802 bytes (~4 KiB) if all images could be read properly.

Script used:

#!/bin/zsh
for x in images/**/*.png; do
  identify -quiet -verbose "${x}" | grep "alpha: 1-bit" || optipng -o7 "${x}"
done

[xeen]

I suggest using ImageIO because it fixes the originally reported issue. The 1-bit-alpha bug exists in both implementations, so no change here. Speed regression is negligible. There is a remote chance this might also fix #2904 and similar.

While the space savings are minimal, I can now provide a working shell script that compresses the images automatically without causing a transparency bug (hopefully, at least). The savings are now at ~27 KiB, although I have no idea why the new method saves more than optimizing all images.

Are there any objections? If not, shall I add the script to SVN?

[xeen]

Script that optimizes all PNGs in images/ without causing an alpha transparency bug

[stoecker]

Are there any objections?

No.

If not, shall I add the script to SVN?

I think so.

[xeen]

In 4938/josm:

use ImageIO instead of Toolkit’s createImage. PNGs without alpha channel should not get a transparent background anymore. See #1576

[xeen]

In 4939/josm:

add shell script that compresses all PNGs

Requires ImageMagick and optipng to be installed and available in $PATH.
Works around bug which causes PNGs with 1-bit-alpha-channels to have an
opaque background (see #1576)

[xeen]

In 4940/josm:

Optimize images. Please report if images changed (esp. if the background changed from color to transparent or vice versa). See #1576

[skyper]

Hey xeen

Maybe you can have a look at these two images too, #7362.

Thanks

[xeen]

Is there any guideline on how to handle the images in images/styles/standard, which are located on OSM’s SVN. I would like to contact the other consumers before blindly committing the compressed variants (also I don’t want to be the one to update the debian/ dir)

[stoecker]

In the past josm was the only one with problems. We sometimes needed to revert optimizer runs. So I think there should be no problem to optimze the images.

[bastiK]

This is interesting. I always had the problem, that TexturePaint requires a BufferedImage, but Toolkit.createImage returns sun.awt.image.ToolkitImage.

There's a lot of code, just to handle this efficiently (the sanitize stuff). It seems, we can get rid of this now since all image data we get is a BufferedImage anyway.

[xeen]

Nice. Will you do the follow up then? I noticed that I forgot to change sanitized to true once; but if that whole code is going to be removed anyway…

[stoecker]

Patch to remove sanitize

[stoecker]

Seems not to affect outside code, so can be simply removed when not needed anymore.

[bastiK]

new ImageIcon(bytes).getImage() still returns ToolkitImage. To make it explicit, better use BufferedImage directly for the cache:

src/org/openstreetmap/josm/tools/ImageResource.java

@@ -23 +21 @@
     /**
      * Caches the image data for resized versions of the same image.
      */
-    private HashMap<Dimension, ImageWrapper> imgCache = new HashMap<Dimension, ImageWrapper>();
+    private HashMap<Dimension, BufferedImage> imgCache = new HashMap<Dimension, BufferedImage>();
     private SVGDiagram svg;
     public static final Dimension DEFAULT_DIMENSION = new Dimension(-1, -1);

[bastiK]

Replying to xeen:

Nice. Will you do the follow up then? I noticed that I forgot to change sanitized to true once; but if that whole code is going to be removed anyway…

Maybe wait a few days, to see if it works ok on all platforms. This only affects the MapCSS property fill-image which isn't used much at the moment (just in Mapnik style, AFAIK).

[stoecker]

The file images/preferences/toolbar.png now looks ugly (preferences tab).

[stoecker]

Sorry, I did accidentially checkin the nosan patch. Please revert or fix when necessary.

[stoecker]

In 4961/josm:

see #1576 - switch ImageResource complete to BufferedImage, fix last accidential checkin