On Sunday 06 August 2006 16:00, Simone Giannecchini wrote: > I fully agree with Andrea, we have been playing around the all week > with different writers and the conclusion is that if you want to speed > up things you need to use gif or png with indexed color model, if you > want to dramatically speed up thing you need to used natively in the > streaming renderer image with an index color model instead or drawing > true color rgb and then reducing. > What I am going to do next days is enabling the streaming renderer to > use directly indexed buffered image with a standard prefixed palette > of 256 color enabling that for GIF and paletted PNG and TIFF. > > Next step, as Andrea pointed out, would be investigating some sort of > customization of palettes for optimal quality. The options we have > right now on the plate are as he described, let's see if someone has > some others bright ideas for step 2 (that is, after the standard > palette work fine). that's great guys, it was just the idea i had but still hadn't the time to accomplish. Wouldn't it be possible, instead of using a fixed pallete, to create it at runtime by inspecting the colors needed by the SLD object?
2c- Gabriel. > > > > Simone. > > On 8/6/06, Andrea Aime <[EMAIL PROTECTED]> wrote: > > Hi all, > > during the last week I spent some time trying to get the best possible > > performance out of GIF WMS serving. > > > > Now, during my tests I noticed that GIF encoding took as much time > > as pure rendering, if not more. One way to speed encoding up in a > > dramatic way (5/10 times faster) is to render stuff directly on a > > 256 colors palette, something that you can get by creating a > > buffered image with the TYPE_BYTE_INDEXED flag. > > > > The drawback about this approach is that the TYPE_BYTE_INDEXED > > provides you with a fixed 256 colors palette. Now, thinking about > > this, it's not such a great problem if we allow the user to create its > > own palette, or give him some tools to estimate a good one. > > > > It would not be so difficult: take the map you want > > to render, with all of the layers enabled, and render it into true > > colors. Then perform a reduction to 256 colors -> the palette you get is > > a stable palette and it's a good estimate of the one you need. > > Of course this would be only a tool for estimation, leaving the user > > free to perform the estimation in another way (for example, we could > > learn to import paint shop pro/gimp palettes). > > > > I haven't tried, but hope the same would apply to PNG images as well > > (with various palettes, ranging from 256 to 65xxx colors). > > Me or Simone are going to try this out on the coverage branch next week. > > > > Cheers > > Andrea > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > your opinions on IT & business topics through brief surveys -- and earn > > cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Geoserver-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Gabriel Roldán ([EMAIL PROTECTED]) Axios Engineering (http://www.axios.es) Tel. +34 944 41 63 84 Fax. +34 944 41 64 90 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
