Yeroc ha scritto:
Andrea....
I just tried v1.5.0 but so far it has been a real step backwards for me. 
Maybe I'm doing something(s) wrong. I've got both v1.4.0 and v1.5.0
installed as separate contexts in a single Tomcat v5.5.17 instance running
under JDK v1.6.0 with native JAI/ImageIO. Both versions are configured to
use the same data directory (and thus have identical configurations).
The first issue is that the rendering under v1.5.0 is all messed up. I'm
using the layer grouping functionality to create a virtual basemap layer but
v1.5.0 doesn't seem to handle it properly. It looks like it might be
rendering the layers using the default style associated with the feature
type rather than the one specified with the virtual layer.
Hum...
The second issue (as noted below) is that the GIF output produced by v1.5.0
is badly dithered (I haven't noticed any dithering in v1.4.0). Do you know
what caused the output quality regression between v1.4.0 and v1.5.0?
Moving from Geoserver 1.4.0 to Geoserver 1.5.0 we moved from the classic
Java encoder to a JAI based one, that uses dithering to simulate colors
it does not have in its palette.
I tried out removing that code and inserting back the old ImageIO based
one, rendering times are 50-100% bigger, but the image quality is definitely superior (it's taking the time to figure out an optimal palette at runtime, now I see why it was so slow with 1.4.0).
The third issue is that the JPEGs produced by v1.5.0 seem to have colour
issues. The background colour is defined as a blue but becomes a rather
bright orange with v1.5.0. v1.4.0 gets the colour right.
I noticed this one too, after releasing 1.5.0 thought...
http://jira.codehaus.org/browse/GEOS-1042
And yeah, turning native acceleration off makes the image appear fine. Btw, I'm on Windows, so it does not seem to be a platform dependent issue to me...
The Goeserver 1.4.0 was using JAI too, but without native acceleration,
I guess that's why we never saw this issue.
aaime wrote:
In Geoserver 1.5 it's controlled programmaticaly, but we don't expose it
to the user level (in 1.4 I do think the default compression was used).
We have currently troubles modifying configuration and UI because people
that made those subsystems are no more with us, and to add a single
configuration option (like the jpeg compression level) we have to modify
some 10-12 files. We are investigating a new UI and configuration subsystem, but the thing it's taking a lot longer than anticipated.
I've opened a new issue for this, tentatively scheduled for 1.5.1
http://jira.codehaus.org/browse/GEOS-1041
That would be great... Maybe a stopgap solution would be to default to
higher-quality output? Or would this negatively affect existing users?
It would, for sure, since it would generate bigger images too.
We have to find a way to expose this settings to the user, either
with configuration, or with request parameters (so that you can use different compression on different layers).
In any case, I have completed the first part of my png8 work, that
renders both fast and with decent quality (but you'll have to give up antialiasing, sorry, there's nothing I can do about it).
Here is some sample output:
http://docs.codehaus.org/display/GEOS/Paletted+images
You can try it out when today's nightly build is out at:
http://geo.openplans.org/nightly/1.5.x/
(the server is in Canada, so it should be a matter of a few hours
before the Apr 19 nightly is out).
Then, add &palette=safe to your GetMap requests to work against the
internet safe palette, or if you want better quality, create a
"palettes" subfodler inside your data directory, and drop a .png
or .gif image with the desired palette there, then user "palette=xxx"
where xxx is the name of the file with the palette, minus the extension
(that is, if you have palettes/mypalette.png, use palette=mypalette).
In my experiments pngs and gifs generated with such a fixed palette
are both good looking and very fast to generate (faster than 24bit
png's).
Cheers
Andrea
