Support gif as an output format for the WMS

This is the patched class for writting GIF images. Needs modified org.shetline.io.GIFOutputStream which is gifencode.jar

This is a modified GIFOutputStream class. It does not flush the output, as it's done by geoserver.

This is the source class. Maybe we could include it into the org.geotools, so no external jar file will be needed.

Patched file to add image/gif support.

Ok, a few emails on the list that didn't get in here:

First, the new JAI ImageIO release candidate supports GIF, so users could just use that. But it is RC, and actually didn't work in my tests.

Patrick responds:
> About the support in the java advanced imaging. It's release
> candidte thing. Either we integrate the GIFOutputStream class - which
> works perfectly into org.geotools tree, so no additional jar is
> needed.

I was thinking that it was more than one class. I agree, I think we should just integrate it into the tree. Though I think org.vfny.geoserver.responses.map.gif is a more appropriate place than on GeoTools, as I don't think GeoTools so much wants to deal with out put formatting. If they end up wanting it we can move it, but I think it's fine on GeoServer for now.

I'll test this out and roll it in when we move trunk to 1.3

Hey Gabriel, did you finish this (or at least get the same functioinality)? You want to go ahead and close it?

Actually it is in place, but needs a slight fix.
It has it's own MapProducer and factory implementation, which is registered in
META-INF/services.
And yes, gif support in JAI is broken and we had the factory precedence problem (aka. which factory is found first for producing a
given map format). As a workaround, we declare the GIFMapProducerFactory before the JAI one, in the services meta file, so it is found prior to the jai factory.

Here is a brief resume of the discussion lost in the email list that did not reach this issue:

• at first, GifOutputStream used a fixed color for transparency. For instance, it was black, which lead to all black lines and fills being transparent.
• then, the map's BGCOLOR was used as the transparent one, but this lead to having strokes and fills transparent then they are equal to the bgcolor, which, unfortunatelly, defaults to WHITE. So this is not a good approach too.
• Now, I think there are 2 possible solutions:
• the first one is to use a less common fixed color for transparency, say, magenta. I guess this is a common approach since I saw a lot of gif images having magenta as transparent color in the windows land.
• the other would be to programatically create a color that is not in the image's pallete.

Patrick: may be you could take care of this? if you do not have time please tell me so I may be have a run.

I've moved this to a later release since it will not be done by tomorrow.

So I think a good bit of this work has been rolled in. We now report gif on our capabilities, and things seem to go along when you call it, but instead of an image I get:

The image "http://localhost:8080/geoserver/wms?bbox=-130,24,-66,50&styles=population&Format=image/gif&request=GetMap&layers=states&width=550&height=250&srs=EPSG:4326" cannot be displayed, because it contains errors.

Any ideas?

I've tested the GIF support - it appears the bottom edge of the image is getting cliped (by 5 pixels).

I changed the writer to a new one, added colour reduction algorithm and changed how transparency was done.