On Thu, Oct 20, 2011 at 8:22 PM, Gabriel Roldan <groldan@anonymised.com> wrote:
On Thu, Oct 20, 2011 at 3:08 PM, Andrea Aime <andrea.aime@anonymised.com>
wrote:
On Thu, Oct 20, 2011 at 7:18 PM, Gabriel Roldan <groldan@anonymised.com>
wrote:
> Hello raster experts,
> out of an issue raised in gwc land, I wonder whether we can support semi
> transparent 8 bit png images (I assume we just don't so far?).
> A little investigation (as I was trying to reject the proposal of using
> the
> pngquant external program to achieve this) suggests that what we need is
> to
> use the NeuQuant quantization algorithm[1], and surprisingly it looks
> like
> JAI actually supports it:
>
> <http://download.oracle.com/docs/cd/E17802_01/products/products/java-media/jai/forDevelopers/jai-apidocs/javax/media/jai/operator/ColorQuantizerDescriptor.html>
> So question is has this even been considered, is known to (not)work? and
> if
> yes, do you think we could add support for it in GeoServer?
It's sometihng that has been in my wish list for a while. The neuquant
algorithm in
JAI does not support translucency and it's, afaik, quite slow, so it's
really useless.
See here:
http://download.oracle.com/docs/cd/E17802_01/products/products/java-media/jai/forDevelopers/jai-apidocs/javax/media/jai/operator/ColorQuantizerDescriptor.html
"This operation generates an optimal lookup table (LUT) based on the
provided 3-band RGB source image by executing a color quantization
algorithm."
The op won't work on RGBA images as far as I know.
We can extend the current mediant cut, and I've put eyes on another
fast C implementation
that does support translucency that would need to be ported over to
Java/JAI. but so far
I haven't had time to work on it. It would require a few days of work
to do the port and
test it over the various input types, the pre-cooked palettes and so on.
disappointing on the JAI side. Still, the following page[1] points to a java
implementation that claims to support semi
transparent: <http://members.ozemail.com.au/~dekker/NeuQuant.java>
may that be a good starting point?
[1]http://members.ozemail.com.au/~dekker/NEUQUANT.HTML
The code mentions a "alpha" variable, but it never actually uses the alpha
values from the pixels, so I'm inclined to believe it still just works for RGB
images.
There are two interesting C implementations around that can do RGBA,
one, pngnq, uses neuquant, the other, pngquant, uses a median cut.
When faced with a RGBA input image the difference in output seems small,
to the naked eye, negligible, but the performance one is staggering.
Let's take a image that GeoServer will still allow to generate, since these
algorithms work particularly bad on screen sized images:
http://demo1.geo-solutions.it/playground/wms?LAYERS=boulder&STYLES=&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A2876&BBOX=3058543.3075541,1247612.764777,3064807.4077617,1251136.3211438&WIDTH=1600&HEIGHT=900&transparent=true
and then translate it with the two tools:
time pngnq boulder.png
real 0m3.568s
user 0m3.560s
sys 0m0.000s
time pngquant 256 boulder.png
real 0m0.743s
user 0m0.730s
sys 0m0.010s
Consider that both had to pay the same price to decode the input and
re-encode the output, and that takes some time too. As a reference:
time gdal_translate -of PNG boulder.png boulder2.png
Input file size is 1600, 900
0...10...20...30...40...50...60...70...80...90...100 - done.
real 0m0.378s
user 0m0.370s
sys 0m0.010s
It looks like pngquant is 10 times faster and still able to produce good
looking output.
Also, its source code is small and relatively easy to understand, at least
compared to a neuquant implementation.
I understand that you're hitting for png8 for tile cache and so the
interest in large images may not be there, but consider that once
you add that output format it can be used for WMS as well, and we
allow relatively large request, if the png8 implementation is not careful
it can be easily used as a way to mount a DOS attack on the server
slamming its cpus to death.
If we go for a very slow implementation we should also be conscious
and allow the administrator to turn it off somehow
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
