[Geoserver-users] progressive images

Hi,
Maybe this question was answered before but, Could geoserver generate progressive jpeg/images??..

thanks.
Facundi

Hi Facundi,

Currently no. I am not the expert in this area so i am not sure how much
work that would be to accomplish. Andrea or Simone should be able to
give you a better idea of that.

-Justin

Facundo Garat wrote:

Hi,
  Maybe this question was answered before but, Could geoserver generate
progressive jpeg/images??..

thanks.
Facundi

!DSPAM:4007,46d5fc8359661439371379!

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

!DSPAM:4007,46d5fc8359661439371379!

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

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

!DSPAM:4007,46d5fc8359661439371379!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Justin Deoliveira ha scritto:

Hi Facundi,

Currently no. I am not the expert in this area so i am not sure how much
work that would be to accomplish. Andrea or Simone should be able to
give you a better idea of that.

Hum, the native jpeg compressor we use for faster jpeg image generation cannot do progressive images:
http://java.sun.com/products/java-media/jai/README-jai_imageio-1_1.html

Yet, the pure java version shipping with the jdk is able to, it's
a matter of setting a parameter. I'm just not sure how to pick one or
the other dinamically, and if this is possible at all, or if we
are forced to uniformly use the pure java version in order to support
the progressive calls.

Simone, any idea?
Cheers
Andrea

Ciao Facundo (or Garat? :slight_smile: ),
for the moment the GeoServer generates jpeg images without specifying
anything about them being progressive.
What aaime stated in a previous email is correct, anyway I think we
could try out something in order to encode progressive jpeg images.
For example we could create a specific mapproducer (or bend the one we
already have) in order to serve a progressive_jpeg output format which
only relies on the J2SE writer. It should not be too hard to do.

Let me know what do you think about it.
Simone.

On 8/30/07, Facundo Garat <facundo.garat@anonymised.com> wrote:

Hi,
  Maybe this question was answered before but, Could geoserver generate
progressive jpeg/images??..

thanks.
Facundi

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

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

http://www.geo-solutions.it

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

Simone Giannecchini ha scritto:

Ciao Facundo (or Garat? :slight_smile: ),
for the moment the GeoServer generates jpeg images without specifying
anything about them being progressive.
What aaime stated in a previous email is correct, anyway I think we
could try out something in order to encode progressive jpeg images.
For example we could create a specific mapproducer (or bend the one we
already have) in order to serve a progressive_jpeg output format which
only relies on the J2SE writer. It should not be too hard to do.

On trunk we already have support for a generic format_options parameter.
In the case of jpeg, we could leverage it to specify jpeg parameters
such as:

http://host:port/geoserver/wms?request=GetMap?...&format_options=progressive:true,compression:80

to have a progressive, 80% compressed jpeg output. Of course, we need
to add code to process these parameters, but they are already getting
down to

Cheers
Andrea

Mmmmmhhh sounds nice,
I have just started working on 1.6.x so I still have to discover the
full potential.

This feature sounds pretty interesting though, we could have a wide
range of options to open up to users' control.

Simone.

On 8/30/07, Andrea Aime <aaime@anonymised.com> wrote:

Simone Giannecchini ha scritto:
> Ciao Facundo (or Garat? :slight_smile: ),
> for the moment the GeoServer generates jpeg images without specifying
> anything about them being progressive.
> What aaime stated in a previous email is correct, anyway I think we
> could try out something in order to encode progressive jpeg images.
> For example we could create a specific mapproducer (or bend the one we
> already have) in order to serve a progressive_jpeg output format which
> only relies on the J2SE writer. It should not be too hard to do.

On trunk we already have support for a generic format_options parameter.
In the case of jpeg, we could leverage it to specify jpeg parameters
such as:

http://host:port/geoserver/wms?request=GetMap?...&format_options=progressive:true,compression:80

to have a progressive, 80% compressed jpeg output. Of course, we need
to add code to process these parameters, but they are already getting
down to

Cheers
Andrea

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

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

http://www.geo-solutions.it

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

Simone Giannecchini ha scritto:

Mmmmmhhh sounds nice,
I have just started working on 1.6.x so I still have to discover the
full potential.

This feature sounds pretty interesting though, we could have a wide
range of options to open up to users' control.

Indeed. If you're happy to have params just as strings, look at how
I used antialias in DefaultRasterMapProducer. If you want them to be
parsed into objects, just write a kvp parser for them and the format_options parser will use it (so for example you could write
a "compression" kvp parser that checks the value is between 1 and 100
and then turn it into an Integer while you're at it).

Cheers
Andrea