Ciao Martin, I have committed to trunk un der org.geotools.image.palettea few classes. Part of them comes from geoserver part of the comes from some other work we did for other projects.
There is a class called CustomPaletteBuilder which is a deep refactor of an ImageIO class, and I think that sooner or later I will donated it back to that project. It implements a nice octree quantization algorithm which can take into account alpha band ,source subsampling, max num of desired colors and also transparency thresholds. It build a good palette for the provided image but it also give a decent-quality indexed image if requested. If not you could use one of the other JAI ops to create it using the computed palette. I also added a few classes that may be used a start up to wrap thi class into a JAI operation. There is also a class called EfficientInverseColorMapComputation which can be used to go from an RGB or RGBA image to a paletted one using a provided palette. There is also some code to create a BufferedImageOp and a RasterOp for it. Creating a JAI operation for this would be, using the mentioned classes, pretty easy. Tomorrow I should commit some code to build animated GIF. A few annotations: 1>JAI operations for doing color reduction are not bad but they have some not-so-nice limitations. For example none of them handle alpha band. That's why I had to come up with that long chain at first, to work this limitation around. Consider also the fact that there is a quite stringent trade-off between quality and speed when building the (near)optimal palette. It is not easy to find a good balance. 2>Most JAI operations don't compute directly the indexed image but they rather build a palette that you can then use for doing the error diffusion or the ordered dither. This means 2 operations at least. To be honest some of he color reduction ops returns a nearest neighbor indexed image as part of the computation of the (near)optimal palette but its quality is often pretty bad. 3>Speed is animportant factor for these algorithms and that was the main reason to replace the code that you were evaluating since we wanted faster GIF output in GeoServer WMS. However large raster and GIF don't get along very well for various reasons: - GIFWriter in ImageIO request the whole input coverage to be in memory and does not do any tiling. This applies also to other comemrcial libraries I have evaluated in the passt. - Computing a good palette for a raster is pretty expensive since you might have to walk through all its pixels to decide which colors are worth to keep and which not. If you are thinking about using GIF for large raster, I would rather suggest looking into TIFF. Hope this helps, Simone. On Jan 11, 2008 10:28 PM, Martin Desruisseaux <[EMAIL PROTECTED]> wrote: > About maskComponentColorModelByte again... > > I think I'm begining to understand how the method tries to process. If I'm > understanding right, it basically uses a lookup for replacing every occurences > of the "color to turn into a transparent color" to RGB value of (0,0,0), which > is black. Then it uses a "band combine" followed by "binarize" followed by > "band > select" in order to get the alpha chanel, to be merged again with the RGB > image. > > Problems that I see: > > * If the original RGB image has black color (0,0,0), they will be turned into > transparent color as well as a side-effect of current algorithm if I'm > understanding right? > > * This is a lot of image operations!!!!!!!!!! > > "BandSelect" --> "Lookup" --> "BandCombine" --> "Extrema" --> "Binarize" --> > "Format" --> "BandSelect" (one more time) --> "Multiply" --> "BandMerge" > > Up to 9 image operations (with all the potentially huge rasters to copy that > amount of time in memory) for turning an opaque color into a transparent > one!! > We would get waaaaaaaaaaaaaaaaaaaayyyyy much more speed and memory > efficiency > by writting our own JAI operation if there is none suitable. It would also > be > more determinist (the "binarize" method invoked above depends on statistics > on > pixel values) and avoid unwanted side-effect like turning black color to > transparent one. It would also be easier to maintain I believe. > > I will leave the current method as is, but we should consider seriously > replacing it by a custom JAI operation. Or is it really used? If not, it may > be > safer to remove it... > > Martin > -- ------------------------------------------------------- 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 ------------------------------------------------------- ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
