[Geoserver-devel] Possible improvements for png8?

Hi,
I just stumbled on this article on the net:
http://blog.klokan.cz/2008/11/png-palette-with-variable-alpha-small.html

Hum... this sounds like very very interesting, is it not?
What do you think, worth pursuing?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Having pngs that display transparent in ie 6 would be great, and half the size is definitely amazing. So yeah, worth pursuing at some point for sure. With GWC/TileCache now image size per tile is hugely important.

Andrea Aime wrote:

Hi,
I just stumbled on this article on the net:
http://blog.klokan.cz/2008/11/png-palette-with-variable-alpha-small.html

Hum... this sounds like very very interesting, is it not?
What do you think, worth pursuing?

Cheers
Andrea

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

been there than that :slight_smile:

The algorithm we use is a (super) optimized version of the octtree
algorithm. Notice this sentence in the documents pointed out in the
blog post:
"The quantizer is fairly slow compared to median cut or octree methods".
NeuQuant gives good quality but if you want to use it in place like we
do (the guy is doing offline preprocessing) ou'd give up a lot in
terms of speed.

I should still have around the speed tests I had made with the various
algorithms, I could put them somewhere (I have a blog as well! :slight_smile: ).
Anyway, there are others novel algorithms that we could try and
implement but I wonder if ATM it is worth the effort, I think there
are many other things that we could optimize with a similar effort.
Mmmmmmhhh, probably topic for an intern.

Simone.
-------------------------------------------------------
Eng. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

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

On Thu, Nov 13, 2008 at 8:45 PM, Andrea Aime <aaime@anonymised.com> wrote:

Hi,
I just stumbled on this article on the net:
http://blog.klokan.cz/2008/11/png-palette-with-variable-alpha-small.html

Hum... this sounds like very very interesting, is it not?
What do you think, worth pursuing?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Simone Giannecchini ha scritto:

been there than that :slight_smile:

The algorithm we use is a (super) optimized version of the octtree
algorithm. Notice this sentence in the documents pointed out in the
blog post:
"The quantizer is fairly slow compared to median cut or octree methods".
NeuQuant gives good quality but if you want to use it in place like we
do (the guy is doing offline preprocessing) ou'd give up a lot in
terms of speed.

I should still have around the speed tests I had made with the various
algorithms, I could put them somewhere (I have a blog as well! :slight_smile: ).
Anyway, there are others novel algorithms that we could try and
implement but I wonder if ATM it is worth the effort, I think there
are many other things that we could optimize with a similar effort.
Mmmmmmhhh, probably topic for an intern.

I agree that for the use case of online data serving having a slow
encoder is not the best option. Yet, for a tile cached set, provided
you have enough processing power to handle either the pre-seeding
or the on line tile generation, it makes sense to offset lower
performance for good quality, as the cost of producing the
tiles becomes a one time only one.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Ciao Andrea,
you are perfectly right, I did not think about this use case.
We can do this, I can resurrect my tests again, but if we then want to
make the quantization algorithm pluggable, I'd need your help for the
integration.
Do we have a deal?

Simone.
-------------------------------------------------------
Eng. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

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

On Fri, Nov 14, 2008 at 10:16 AM, Andrea Aime <aaime@anonymised.com> wrote:

Simone Giannecchini ha scritto:

been there than that :slight_smile:

The algorithm we use is a (super) optimized version of the octtree
algorithm. Notice this sentence in the documents pointed out in the
blog post:
"The quantizer is fairly slow compared to median cut or octree methods".
NeuQuant gives good quality but if you want to use it in place like we
do (the guy is doing offline preprocessing) ou'd give up a lot in
terms of speed.

I should still have around the speed tests I had made with the various
algorithms, I could put them somewhere (I have a blog as well! :slight_smile: ).
Anyway, there are others novel algorithms that we could try and
implement but I wonder if ATM it is worth the effort, I think there
are many other things that we could optimize with a similar effort.
Mmmmmmhhh, probably topic for an intern.

I agree that for the use case of online data serving having a slow
encoder is not the best option. Yet, for a tile cached set, provided
you have enough processing power to handle either the pre-seeding
or the on line tile generation, it makes sense to offset lower
performance for good quality, as the cost of producing the
tiles becomes a one time only one.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Simone Giannecchini ha scritto:

Ciao Andrea,
you are perfectly right, I did not think about this use case.
We can do this, I can resurrect my tests again, but if we then want to
make the quantization algorithm pluggable, I'd need your help for the
integration.
Do we have a deal?

Deal :slight_smile:
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Good to see this deal hatched :wink:

I think it’ll be an increasingly popular use case, especially as we figure out how to get GeoServer rendering tiles on EC2 and other clusters. Users will want to optimize for the smallest tiles over the fastest processing. We’ll make people happy if we give them control over optimizing for speed of response and file size, instead of pre-setting what we think is the best (though of course that should be the default).

Might be interesting to have GWC use a different quantization default from GeoServer too, since we already know the use case when people are using it.

Chris

On Fri, Nov 14, 2008 at 4:20 AM, Andrea Aime <aaime@anonymised.com> wrote:

Simone Giannecchini ha scritto:

Ciao Andrea,
you are perfectly right, I did not think about this use case.
We can do this, I can resurrect my tests again, but if we then want to
make the quantization algorithm pluggable, I’d need your help for the
integration.
Do we have a deal?

Deal :slight_smile:

Cheers
Andrea


Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.


This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

The code GWC uses to chop up metatiles into individual tiles is pretty trivial (see [1], createTile() and writeTileToStream() below).

Will that process kill the optimization done by GeoServer, or does the palette survive ? In the current 8 bit PNG case it appears to survive, afaict.

-Arne

1: http://geowebcache.org/trac/browser/trunk/geowebcache/src/main/java/org/geowebcache/layer/wms/WMSMetaTile.java#L142

Chris Holmes wrote:

Good to see this deal hatched :wink:

I think it'll be an increasingly popular use case, especially as we figure out how to get GeoServer rendering tiles on EC2 and other clusters. Users will want to optimize for the smallest tiles over the fastest processing. We'll make people happy if we give them control over optimizing for speed of response and file size, instead of pre-setting what we think is the best (though of course that should be the default).

Might be interesting to have GWC use a different quantization default from GeoServer too, since we already know the use case when people are using it.

Chris

On Fri, Nov 14, 2008 at 4:20 AM, Andrea Aime <aaime@anonymised.com <mailto:aaime@anonymised.com>> wrote:

    Simone Giannecchini ha scritto:
    > Ciao Andrea,
    > you are perfectly right, I did not think about this use case.
    > We can do this, I can resurrect my tests again, but if we then
    want to
    > make the quantization algorithm pluggable, I'd need your help
    for the
    > integration.
    > Do we have a deal?

    Deal :slight_smile:
    Cheers
    Andrea

    --
    Andrea Aime
    OpenGeo - http://opengeo.org
    Expert service straight from the developers.

    -------------------------------------------------------------------------
    This SF.Net email is sponsored by the Moblin Your Move Developer's
    challenge
    Build the coolest Linux based applications with Moblin SDK & win
    great prizes
    Grand prize is a trip for two to an Open Source event anywhere in
    the world
    http://moblin-contest.org/redirect.php?banner_id=100&url=/
    <http://moblin-contest.org/redirect.php?banner_id=100&url=/&gt;
    _______________________________________________
    Geoserver-devel mailing list
    Geoserver-devel@lists.sourceforge.net
    <mailto:Geoserver-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  
--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers

Arne Kepp ha scritto:

The code GWC uses to chop up metatiles into individual tiles is pretty trivial (see [1], createTile() and writeTileToStream() below).

Will that process kill the optimization done by GeoServer, or does the palette survive ? In the current 8 bit PNG case it appears to survive, afaict.

It should survive in fact... but keep me posted should you notice
anything goes wrong.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.