Optimising images would save 250KB

[Stereo]

Running ​https://imageoptim.com on https://josm.openstreetmap.de/svn/trunk saves 14.7% on average on every image, and up to 94.7%. Altogether, this saves 250.2KB

Optimising the images in the plugins would probably achieve similar gains.

[Don-vip]

In 7491/josm:

fix #10479 - optimize PNG/JPG images

[Don-vip]

In 7492/josm:

see #10479 - revert changes on data_nodist/*.jpg (we need EXIF information here)

[naoliv]

Something is broken with the PNG files:

[Stereo]

Maybe these png files relied on their alpha channel. The other button images manage to stay transparent after optimisation, I wonder what the difference is?

[Don-vip]

I have checked source:trunk/images/misc/sticky.png. This is a tricky case. The file is transparent and valid according to PNG standard.

The optimization has changed the format from paletted+tRNS to truecolor+tRNS.

But here comes ​javabug:6788458: tRNS chunk is ignored by Java if the image is not indexed (paletted).

Either I revert the impacted files or implement a workaround to this problem.

[naoliv]

Just use the plain optipng program (and not imageoptim) for all files and they should be good, from what I see here.

[Don-vip]

We already did that the idea of this ticket is to optimize even further :)

[Don-vip]

In 7495/josm:

fix #10479 - proper handling of transparent files

[Don-vip]

Here is a non-exhaustive list of impacted files, it seems to work fine now:

DEBUG: Transparency has been forced for image dialogs/autoscale/problem.png
DEBUG: Transparency has been forced for image presets/memorial.png
DEBUG: Transparency has been forced for image presets/way_secondary.png
DEBUG: Transparency has been forced for image dialogs/validator.png
DEBUG: Transparency has been forced for image presets/ford.png
DEBUG: Transparency has been forced for image presets/waypoints.png
DEBUG: Transparency has been forced for image presets/Stop.png
DEBUG: Transparency has been forced for image presets/bollard.png
DEBUG: Transparency has been forced for image presets/lift_gate.png
DEBUG: Transparency has been forced for image presets/swing_gate.png
DEBUG: Transparency has been forced for image presets/stile.png
DEBUG: Transparency has been forced for image presets/waterfall.png
DEBUG: Transparency has been forced for image presets/chair_lift.png
DEBUG: Transparency has been forced for image presets/interpolation.png
DEBUG: Transparency has been forced for image presets/taxiway.png
DEBUG: Transparency has been forced for image presets/biergarten.png
DEBUG: Transparency has been forced for image presets/townhall.png
DEBUG: Transparency has been forced for image presets/fire_hydrant.png
DEBUG: Transparency has been forced for image presets/baker.png
DEBUG: Transparency has been forced for image presets/laundry.png
DEBUG: Transparency has been forced for image presets/stationery.png
DEBUG: Transparency has been forced for image presets/book.png
DEBUG: Transparency has been forced for image presets/travel.png
DEBUG: Transparency has been forced for image presets/addresses.png
DEBUG: Transparency has been forced for image logo_32x32x8.png
DEBUG: Transparency has been forced for image cursor/modifier/zoom.png
DEBUG: Transparency has been forced for image misc/sticky.png
DEBUG: Transparency has been forced for image misc/close.png
DEBUG: Transparency has been forced for image dialogs/layerlist/eye-translucent.png
DEBUG: Transparency has been forced for image dialogs/layerlist/eye-pressed.png
DEBUG: Transparency has been forced for image dialogs/duplicatelayer.png

[Don-vip]

In 7499/josm:

fix #10479 - handle transparency for paletted images

[stoecker]

Regarding the transparency issue - there is surely another older ticket for this as this was a long standing bug.

[Don-vip]

Indeed I forgot it: #1576. It is fixed with r7499.

[Don-vip]

In 7519/josm:

see #10479, see #10491 - optimize notes images

[stoecker]

In 7595/josm:

see #10479 - fix transparency also for 'data:' loading mode

[stoecker]

Now we have svg images which are wasting a lot of space. The tool svgcleaner-cli can compress them a lot. Should we use it? The Styles/Rules/Presets/Plugin icon handling/parser already uses it.

[Don-vip]

Is it a tool provided in Debian/Ubuntu repositories? I can't find it.

[naoliv]

Debian and Ubuntu have python-scour:

 Scour is a Python module that aggressively cleans SVG files, removing a lot of
 unnecessary information that certain tools or authors embed into their
 documents.  The goal of scour is to provide an identically rendered image
 (i.e. a scoured document should have no discernable visible differences from
 the original file) while minimizing the file size.

 WARNING: Scour is intended to be run on files that have been edited in Vector
 Graphics editors such as Inkscape or Adobe Illustrator.  Scour attempts to
 optimize the file, and as result, it will change the file's structure and
 (possibly) its semantics.  If you have hand-edited your SVG files, you will
 probably not be happy with the output of Scour.

[bastiK]

Copy original image over to images_nodist then use whatever is smaller: optimized svg+zip compression from the jar or optimized png.

[stoecker]

Is it a tool provided in Debian/Ubuntu repositories? I can't find it.

No. I installed the prebuild .deb by hand from the Launchpad repository as I didn't want to add another source.

Copy original image over to images_nodist then use whatever is smaller: optimized svg+zip compression from the jar or optimized png.

I'd simply make the optipng and svgcleaner part of the build process. That means we have small release but don't need to take care for the SVN. As said I already do this for the embedded icons of the Styles/Rules/Presets/Plugin data file.

Here a short quality example (trunk/images_nodist/uploadproperties.svg)

Tool	Size
Original	9920
Scour	4247
svgo	3310
svgcleaner	2551

[bastiK]

Replying to stoecker:

I'd simply make the optipng and svgcleaner part of the build process. That means we have small release but don't need to take care for the SVN.

Okay, but for excessively large svg, we could consider shipping the rendered png instead.

Here a short quality example (trunk/images_nodist/uploadproperties.svg)

Tool	Size
Original	9920
Scour	4247
svgo	3310
svgcleaner	2551

The zipped file size is what matters, but I guess it looks similar.

[stoecker]

Replying to bastiK:

Okay, but for excessively large svg, we could consider shipping the rendered png instead.

Actually I think our goal should be to have vector everywhere, so that we can adapt to higher screen sizes.

[skyper]

Replying to stoecker:

Replying to bastiK:

Okay, but for excessively large svg, we could consider shipping the rendered png instead.

Actually I think our goal should be to have vector everywhere, so that we can adapt to higher screen sizes.

+1

[Klumbumbus]

There are missing icons at Help/Plugin/Wikipedia after [7668]

[bastiK]

Stuff in images/markers/* is still used, see Marker.java.

[stoecker]

In 7672/josm:

see #10479 - readd two markers and their keep-alive code

[stoecker]

Replying to Klumbumbus:

There are missing icons at Help/Plugin/Wikipedia after [7668]

Then the missing ones need to be added to wikipedia plugin. :-)

The above two? I find no other icon reference in wikipedia plugin.

[Klumbumbus]

Replying to stoecker:

The above two?

Yes, the two at point 8 in the section Recommended Usage at the linked page.

[stoecker]

Ah, you mean the wiki page. Fixed it and the plugin as well. On the wiki page one of the icons was missing anyway, independent from my change.

[Klumbumbus]

Replying to stoecker:

On the wiki page one of the icons was missing anyway, independent from my change.

You're right. I only checked the first one. The second one was deleted already 2 years ago :) ​http://josm.openstreetmap.de/log/josm/trunk/images/blankmenu.png?rev=7675&mode=path_history

[stoecker]

Automated icon stripping is active from tomorrow (svg and png). Saves about 50KB on the final JAR. Please tell issues with the images if there are some. I didn't detect any with my test file.

[Klumbumbus]

So there is nothing special to consider when uploading new svg images to josm/osm svn?

[stoecker]

So there is nothing special to consider when uploading new png/svg images to josm/osm svn?

Yes, that's the plan.

Current Status:

SVG salamander has a bug which breaks optimized SVG. I fixed it in my local copy and tried to report it ​here but actually they have the worst bug tracker I have ever seen. So ATM I disabled SVG cleaning again.

[stoecker]

In 7676/josm:

update SVG code to current SVN (fix line endings), see #10479