Support for WebP image format

[nejento]

Hello,
I'd like to ask, whether it would be possible to add a new render image format WebP. It's now widely supported by all Chromium browsers and if it would be optional as the jpg format is, it would be quite handy because we would be able to create maps in higher quality with smaller size.
I know that it's not supported by Gecko (Firefox) but it will be hopefully supported soon and it wouldn't be set as the default one.

Thank you for your response.

[bmarwell]

@mikeprimm do you accept pull requests? i saw the project has not been updated for a while.

[rhylos]

Yes he does.  On Friday, December 1, 2017, 10:27, Ben <notifications@github.com> wrote: @mikeprimm do you accept pull requests? i saw the project has not been updated for a while. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[bmarwell]

I thought that would be an easy one. Sadly, the library https://bitbucket.org/luciad/webp-imageio does require native libraries. I'm not sure shipping native libraries and need to configure them is wanted. :-(

[bmarwell]

I found out that there are Java classes provided by Google. I'll take a look into this issue soon.

[mikeprimm]

Support could be added - I'd just be concerned about the span of browser support: see https://caniuse.com/#feat=webp

[bmarwell]

@mikeprimm
Don't have time for tests right now, but can you please take a quick look?

https://github.com/bmhm/DynmapCore/commit/c94057707312ea198c871ba0dd9ddc289b0030e2

[bmarwell]

This is the actual commit for webp: https://github.com/bmhm/DynmapCore/commit/a0c256300ab988ae70e58c04f083bfea3c171be0

[bmarwell]

@nejento @rhylos @mikeprimm

while my commits will add native webp support, one might opt to use mod_pagespeed and nginx instead for performance. This way there will be both jpg and webp files generated (webp in nginx process) which are only served to capable clients.

Anyway, webp would still be interesting as soon as you configure lossless or another lossy compression factor and more browsers will support it.

[nejento]

Regarding the browser support, it's actually not that hot with the browser support for the WebP format when you keep in mind that Chrome (and Chromium based browsers) are widely used by most of the web users. And when you implement the dynmap into your website you can always create a warning about unsupported browser or you can have secondary map in lower quality in jpg-80 so that it doesn't take up that much space and users of other browsers still can see the map.

The main thing about WebP is especially saving the space when keeping the high resolution and thus saving the space on servers hostings which offer for example only 10 GB space for you map.

[rautamiekka]

^ Not everyone is gonna change. Like me, I'm not changing from Firefox for WebP, and such thinking is just wrong.

[nejento]

I'm definitely not forcing anyone to switch to Chrome nor Opera nor Vivaldi nor to anything else. I'm just pointing out that since there is a majority of users using Chromium based browser that there can be the option to use WebP as smaller sized high quality image format.

Not everyone is using dynmap as a public thing. Just as some kind of supervision or just for great renders of the world. For that and many more reasons is implementing WebP a good step. :)

[bmarwell]

So, would you test and accept a pull request with the commits from above?? ^^

[mikeprimm]

I'd accept it as a format option (so long as the library support for encoding WebP is pure Java - not getting in to building and distributing JNI libraries for every platform in creation....). Definitely wouldn't be default, nor a suggested format option: I really don't think the browser support is broad enough, and while the gains exist they aren't compelling enough to impact user's browser selection (latest data puts Chrome at 55% overall, 60% of desktop - that's majority, but the unsupported browser users represent at least 1/3 of the likely user community) - and, if you wind up using something that just-in-time converts the webp images to jpeg or png for non-supporting browsers, you're adding a bunch of runtime compute load.
Most folks with size sensitivity just opt for the JPEG format with some dialing in on the quality (since this will save a lot - more than lossless WebP vs PNG- even at relatively high quality (the default for our jpeg format (85% quality) tends to result in 60+% file size reduction versus PNG, with almost no perceivable difference in appearance)). I don't doubt that, lossy vs lossy, WebP will outperform classic JPEG (on size, cannot say for encoding performance), but I'd take the relatively slow adoption by non-Google browsers as supporting the notion that it isn't exactly a level of advantage that is being found to be particularly compelling.

[bmarwell]

@mikeprimm
Pure Java is not possible yet. No one has published this with acceptable licence and/or performance. Good thing is: There is no need to compile C libraries. For those interested, just drop the .dll file or .so file into the java native lib path. That's it.

So, even with these restrictions -- why not give the user a choice? Is it our choice to make that the user may not use WebP, because it is not adopted widely yet? If that were true, we have a hen-and-egg-problem. Someone just has to start using it. If someone wants to use it and it works, why stop them from using it?

Just my 2 cents. I'd still be happy if someone could test it. I'd also volunteer to write a wiki page on how to use it (java native lib path plus configuring).