Opened 5 years ago
Last modified 15 months ago
#1576 new defect
Certain images with 1-bit-alpha channel lose their transparency
| Reported by: | anonymous | Owned by: | team |
|---|---|---|---|
| Priority: | minor | Component: | Core |
| Version: | latest | Keywords: | bad icon; mappaint |
| Cc: |
Description (last modified by xeen)
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.
Attachments (8)
Change History (48)
comment:1 Changed 5 years ago by anonymous
- Resolution set to wontfix
- Status changed from new to closed
comment:2 Changed 5 years ago by anonymous
- Resolution wontfix deleted
- Status changed from closed to reopened
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.
comment:3 Changed 5 years ago by anonymous
- Owner changed from framm to anonymous
- Status changed from reopened to new
comment:4 Changed 5 years ago by anonymous
- Owner changed from anonymous to ulfl
comment:5 Changed 5 years ago by anonymous
- Priority changed from major to critical
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?
comment:6 Changed 5 years ago by anonymous
- Owner changed from ulfl to stoecker
- Priority changed from critical to minor
- Summary changed from Images with white backgrounds are defect to Images without alpha channel should not get a transparent background
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.
comment:7 in reply to: ↑ description Changed 5 years ago by carolus
- Priority changed from minor to major
- Version set to latest
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.
Changed 5 years ago by carolus
Series of screen shots where we see that a toilet node is only visible in wire frame node.
Changed 5 years ago by carolus
Series of screen shots where we see that a toilet node is only visible in wire frame node.
Changed 5 years ago by carolus
Series of screen shots where we see that a toilet node is only visible in wire frame node.
comment:8 Changed 4 years ago by Hasienda
- Keywords bad icon mappaint added
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)
comment:9 Changed 4 years ago by stoecker
- Owner changed from stoecker to framm
comment:10 Changed 3 years ago by bastiK
- Owner changed from framm to anonymous
- Status changed from new to needinfo
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?
comment:11 Changed 3 years ago by bastiK
- Owner changed from anonymous to team
- Status changed from needinfo to new
comment:12 Changed 3 years ago by stoecker
I think it depends on Java version. We didn't change anything regarding image display.
comment:13 Changed 3 years ago by 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?
comment:14 Changed 21 months ago by Cobra
- Resolution set to fixed
- Status changed from new to closed
Some of these images are looking rather ugly with the plain white background (imho), but working.
comment:15 Changed 21 months ago by stoecker
- Resolution fixed deleted
- Status changed from closed to reopened
comment:16 Changed 21 months ago by stoecker
- Status changed from reopened to new
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.
comment:17 Changed 15 months ago by 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)
comment:18 Changed 15 months ago by 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…
comment:19 Changed 15 months ago by stoecker
Maybe we also get rid of these spurious error messages in PNG code which appear sometimes?
comment:20 Changed 15 months ago by 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.
comment:21 Changed 15 months ago by stoecker
See #2904.
comment:22 Changed 15 months ago by 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
comment:23 Changed 15 months ago by 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
comment:24 Changed 15 months ago by 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?
Changed 15 months ago by xeen
Script that optimizes all PNGs in images/ without causing an alpha transparency bug
comment:25 Changed 15 months ago by stoecker
Are there any objections?
No.
If not, shall I add the script to SVN?
I think so.
comment:26 Changed 15 months ago by xeen
In 4938/josm:
comment:27 Changed 15 months ago by xeen
In 4939/josm:
comment:28 follow-up: ↓ 31 Changed 15 months ago by xeen
In 4940/josm:
comment:29 Changed 15 months ago by xeen
- Description modified (diff)
- Priority changed from major to minor
- Summary changed from Images without alpha channel should not get a transparent background to Certain images with 1-bit-alpha channel lose their transparency
comment:30 Changed 15 months ago by skyper
comment:31 in reply to: ↑ 28 Changed 15 months ago by 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)
comment:32 Changed 15 months ago by 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.
comment:33 Changed 15 months ago by 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.
comment:34 follow-up: ↓ 37 Changed 15 months ago by 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…
comment:35 Changed 15 months ago by stoecker
Seems not to affect outside code, so can be simply removed when not needed anymore.
comment:36 Changed 15 months ago by 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 /** 24 22 * Caches the image data for resized versions of the same image. 25 23 */ 26 private HashMap<Dimension, ImageWrapper> imgCache = new HashMap<Dimension, ImageWrapper>();24 private HashMap<Dimension, BufferedImage> imgCache = new HashMap<Dimension, BufferedImage>(); 27 25 private SVGDiagram svg; 28 26 public static final Dimension DEFAULT_DIMENSION = new Dimension(-1, -1);
comment:37 in reply to: ↑ 34 Changed 15 months ago by 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).
comment:38 Changed 15 months ago by stoecker
The file images/preferences/toolbar.png now looks ugly (preferences tab).
comment:39 Changed 15 months ago by stoecker
Sorry, I did accidentially checkin the nosan patch. Please revert or fix when necessary.
comment:40 Changed 15 months ago by stoecker
In 4961/josm:



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.