Ciao Martin, Hi list, I am sending this email in order to straighten out issues related to the JIRA issue mentioned in this email's subject.
---> 1 Martin writes: "I didn't ported yet the changes done in the getImageLayout(...) method, because the coverage branch contains some changes that I do not yet understand. Why the tile size computation were replaced by a single tile covering the whole image? " I need more details in order to understand this question but, anyhow, I do not see where this replacement is. I am looking at the getImageLayout method right now. The one thing I did not like about the old method for calculating the tile size was that (beyond being a bit obscure or me :-) ) it aimed to computing a tile size such that the tile grid would have overlapped the image bound in order to avoid having tiles crossing the image bounds and being therefore partially empty. Well this approach is good for small coverage but it can be a problem with medium and big coverages since you end up having too many tiles (the so called tile explosions) which is a big performance problem for some operations. Please refere to this discussion thread I opened in the JAI ml. http://forums.java.net/jive/thread.jspa?messageID=112181 Of course, we can discuss about the changes I made and improve them. As you can notice that method is not what I would call definitive. --- --->2 Martin writes: "I also omitted the 'tileImage' method for now. This method tiles the image after it has been read. It is a little bit late for such operation - the tiling should be requested before the operation ("ImageRead" in this case) is executed. I don't think that the "tileImage" bring a performance benefit, because requesting even a single tile of the image created by "tileImage" will require the computation (or loading) of the whole image, since the original image was untiled. I may be wrong, but this method seem to take twice the amount of memory usually needed for an image without obvious benefit. Will add this method later if my analysis appears to be wrong. " I think your hypotheisi is right but the conclusion is wrong :-). Let me explain. >Why you are right< Processing a tiled image is in general more complex that processing an untiled image provided that you have both of them in memory, due to the additional complexity of managing tiles. When you tile an image there is an explosion of objects to deal with (sample models, color models, etc..) for each tile. Hence when tiles are too small we can assist to the "tile explosion" effect that means too many tiles may produce poor perfomances. When we deal with raster that are NOT natively tiled, where with the term natively I mean on disk, we have the only option to load the complete image in memory even if just need a small part of it (I have to admit that this is not the truth, but I am anticipating the next step for the coverage plugin. For the moment believe what I stated before). In this case it might seem useless and also counterproductive to tile the image in memory right after having loaded it. Well this feeling is mostly wrong for various reasons. Let me assume that we compute the tile size correctly and we do not run into the tile explosion effect. I am going to give at least 2 examples that show how the "in memory tiling" is important especially on big raster. 1>Let's look t the following chain Read ----> Scale by N ----> crop -->visualize We go from a source (Read) to a sink (visualize). Until we reach the visualize operation no actual pixel is loaded due to the "deferred execution" or "pull" model that JAI-ImageIO implements. Let us assume the raster is untiled on disk. We have a very big raster but we just want to visualize a small part of it (hence the crop) at a very low resolution (hence the scale). We load it we, we scale it, we crop it and the we visualize it. What happes along the operation chain? Once the operation reach the sink (the display device) pixels are pulled through the chain, tile by tile. Since the raster we have is untiled we will scale it all even if just need a small portion of it because it is made up by only one tile! Morevoer this way the tile cache is not used correctly since we will end up (if do not avoid caching at any node) having two big tiles plus a small one for the result of the crop. If we do this: Read ----> tiling --> Scale by N ----> crop -->visualize Things are way better since after the tiling we will use and retain only the tiles we need even if the underlying image is untiled. Usage of the tile cache is far better ad moreover if we enable tile recycling it is more likely to recycle them due their size and number. Annotation: This example is a bit artificious since if do: Read ----> crop--> Scale by N -->visualize things are acceptable. But I would rely on users doing things the right order. I would prefere to add a hint to control in memory tiling in plugins and doing it always as default. 2>What if we want to add native tiling to a coverage? We need to tile it first in memory and then we can write it on disk in order to have it naively tiled next time, hence we need the tileImage image method. Plz take a look here at the tiling section: http://java.sun.com/products/java-media/jai/forDevelopers/jai-imageio-1_1-alpha-docs/com/sun/media/jai/operator/ImageWriteDescriptor.html --- --->3 Martin writes: "Other methods were refactored in a new class: org.geotools.image.ImageWorker. Some methods were close to identical, so I tried to avoided duplication (hopping that they still have the correct behavior)...." Martin plz go easy with renaming because you are going to kiil all the code I have which relies on those methods!!! :-) --- -------------> Conclusion <----------------------- I have to admit that I was a bit surprised that you started the merge basically without asking anybody, because me, Andrea Aime and Jesse Eichar were fine tuning the last minor aspects but it is fine we will do that afterwards. In case you have some questions plz send some emails on the devel list so that I can try to explain what I did and, in case, we can change it! Thanks a lot for the great work though! Simone. -- °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°° Simone Giannecchini Software Engineer Freelance Consultant http://simboss.wordpress.com/ °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°° Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
