Hi,
today I've been working on the coverage speedup patch
again and managed to get background color handling
working better.
In the end it was just a matter of setting the ROI
in the mosaic.
I've did some extensive testing with different
combination of input image, output formats,
transparency settings, reprojection and all
see to work fine besides a single odd case
that I'll describe at the end of the mail.
I think we're getting past the point where only
developers can move this forward, and we should
instead engage the community, report about the
speedup and ask for help in testing it to the various
GeoServer users.
To remind people the speedup factor is around 2,
so I guess there should be people interested in
it.
Which brings me to look for the best way to merge
the patch itself.
Well, first off we need to bring back the GridCoverageRenderer
and the raster symbolizer visitor changes to GeoTools.
What about the methods that read the coverage, and
the one that handles the coverage and makes sure
the proper bg color and target color models are
dealt with?
For the first (coverage reading) I'm inclined to move
the method into the GridCoverageRenderer, so that
we can share it with the StreamingRenderer.
For the second, it has to deal with a number of
params coming directly from the WMS request (transparency,
background color) so I guess we could keep it inside
GeoServer. It may also have to be refactored further
once we start supporting rendering over the fast path
multiple stacked coverages.
Opinions?
Cheers
Andrea
PS: oh, about the failing case. It happens with
the patch applied, and against the release data directory,
with this request:
http://localhost:8080/geoserver/wms?HEIGHT=385&WIDTH=512&LAYERS=sf%3Asfdem&STYLES=&SRS=EPSG%3A26713&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&BBOX=580470,4906552.8515625,618510,4935157.1484375&transparent=true
The result is a black image. And if you try image/gif,
an exception will be thrown.
The issue is that the raster symbolizer used has one
color that's fully transparent, this generates a color
model that has alpha, and while
ImageWorker.forceBitmaskIndexColorModel
does the necessary Lookup to bring it back to a index
color model with no alpha + transparent pixel
a new index color model with 256 slots gets generated.
That is incompatible with the sample model and the
Lookup will end up ignoring the target color model
and just use a ComponentColorModel instead, that
will result in a black image.
Now, I did not work it out fully, but imho if the
original index color model has a fully transparent
pixel that can be used as the new transparent
index, there is no need to add one at the end
of the palette (and thus expand it).
Also the method should not take the target transparent
pixel as a parameter, but figure it out by itself
so that it can use the above trick to avoid the
palette expansion.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
(attachments)
coverageSpeedup2.patch (66.6 KB)