[Geoserver-users] Larger PNG tiles after geoserver update

GeoServer GeoServer User
1

I am in the process of deploying a newly installed (geo)server, and have hit an odd problem. The new system is a complete refresh (OS, postgreSQL, Java, Tomcat, ...), but I don't think most of these changes are relevant. The old system is running geoServer 2.4.2, and the new one uses 2.5.2. Both have identical layer and style definitions configured, and otherwise have similar setups. When I pull a specific PNG based tile from the old system the size is about half that from the new system with the exact same query/result. Does anyone have any suggestions on places to check to find why there is such a notable difference in the results?

Thanks - Tom

2

On Wed, Oct 8, 2014 at 2:16 AM, Tom S <tom-sourceforge@anonymised.com>
wrote:

I am in the process of deploying a newly installed (geo)server, and have
hit an odd problem. The new system is a complete refresh (OS,
postgreSQL, Java, Tomcat, ...), but I don't think most of these changes
are relevant. The old system is running geoServer 2.4.2, and the new
one uses 2.5.2. Both have identical layer and style definitions
configured, and otherwise have similar setups. When I pull a specific
PNG based tile from the old system the size is about half that from the
new system with the exact same query/result. Does anyone have any
suggestions on places to check to find why there is such a notable
difference in the results?

Your description is quite generic, so I'm going to have to make a few
guesses.

When you say larger, do you mean the size of the output in bytes?

I guess you were running on Windows, where GeoServer was using the JDK
built-in PNG encoder that did not respect our compression hints, and was
spending
a very large amount of time trying to get the smallest possible image,
whilst
in 2.5.x we have a pure java version, which is noticeably faster, and that
does respect the PNG compression parameters configured in the WMS panel.

If you want smaller PNGs you can try increasing the compression rate in the
WMS
panel. Also, have you tried the png8 compression (image/png8), it should
also
improve quite a bit the size of the result, with a un-noticeable loss in
quality
(well, unless you're trying to serve aerial imagery, in this case PNG is
simply
the wrong format, use JPEG instead).

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

3

I am using Windows, and it is the returned tile file size that was radically different. Based on your comments, I checked the configuration (Settings/JAI) and revised this. I do not have the Java ImageIO library installed, so it looks like the system defaults to using the PNGJ library on the newer releases. When I switched to using ‘Java own encoder’, the sizes shrank to be the same between the old and new instance.

In my case the extra file size was enough to have a major impact on slow (Mobile) connections. I’ll test version 2.6, and perhaps ImageIO later to see how it behaves. In any case, even with the compression set to 90, PNGJ is still a bit larger than the original library result. It will take a bit longer to see if the system CPU impact is less using this encoder with the equivalent compression ratio.

Thanks you for this information, and for the great work you do for this community.

···

On 10/7/2014 11:16 PM, Andrea Aime wrote:

On Wed, Oct 8, 2014 at 2:16 AM, Tom S <tom-sourceforge@anonymised.com> wrote:

I am in the process of deploying a newly installed (geo)server, and have
hit an odd problem. The new system is a complete refresh (OS,
postgreSQL, Java, Tomcat, …), but I don’t think most of these changes
are relevant. The old system is running geoServer 2.4.2, and the new
one uses 2.5.2. Both have identical layer and style definitions
configured, and otherwise have similar setups. When I pull a specific
PNG based tile from the old system the size is about half that from the
new system with the exact same query/result. Does anyone have any
suggestions on places to check to find why there is such a notable
difference in the results?

Your description is quite generic, so I’m going to have to make a few guesses.

When you say larger, do you mean the size of the output in bytes?

I guess you were running on Windows, where GeoServer was using the JDK
built-in PNG encoder that did not respect our compression hints, and was spending
a very large amount of time trying to get the smallest possible image, whilst
in 2.5.x we have a pure java version, which is noticeably faster, and that
does respect the PNG compression parameters configured in the WMS panel.

If you want smaller PNGs you can try increasing the compression rate in the WMS
panel. Also, have you tried the png8 compression (image/png8), it should also
improve quite a bit the size of the result, with a un-noticeable loss in quality
(well, unless you’re trying to serve aerial imagery, in this case PNG is simply
the wrong format, use JPEG instead).

Cheers
Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

4

On Thu, Oct 9, 2014 at 12:29 AM, Tom S <tom-sourceforge@anonymised.com>
wrote:

I am using Windows, and it is the returned tile file size that was
radically different. Based on your comments, I checked the configuration
(Settings/JAI) and revised this. I do not have the Java ImageIO library
installed, so it looks like the system defaults to using the PNGJ library
on the newer releases. When I switched to using 'Java own encoder', the
sizes shrank to be the same between the old and new instance.

In my case the extra file size was enough to have a major impact on slow
(Mobile) connections. I'll test version 2.6, and perhaps ImageIO later to
see how it behaves. In any case, even with the compression set to 90, PNGJ
is still a bit larger than the original library result. It will take a bit
longer to see if the system CPU impact is less using this encoder with the
equivalent compression ratio.

The 90% case of using PNGs is encoding rasterized vector data, so the PNGJ
work (which was done exclusively in my spare time) concentrated on having
much faster PNG encoding for vector data
because the existing encoders were almost 80% the reason we lost the last
WMS benchmarking competition (which is normally based on WMS serving speed
over a local network):
http://www.geo-solutions.it/blog/developers-corner-fast-pure-java-open-source-png-encoder-for-geoserver/

The raster case was not investigated in deep, and I guess we could do some
more work to improve on that end, but right now my spare time
is fully busy doing a rewrite of the CSS subsystem so... I cannot offer
help there (well, not personally at least).

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------