Ok, I will start to guess some by myself. After getting my RenderedOp as result from my operation, this, as I expect, is waiting for someone to pull the data out of it.
This happens usually by triggering methods like getWidth, getData, getTile etc. The rendereop is the result that I want to dump to disk, so I supposed that I would trigger rendering only at that point. Instead, the computation is triggered several times, because I go through the process of creating GridCoverage2D from it, which probably internally triggers some method that wakes up the operation. Does this make sense? In fact, if I require the bufferedimage from my renderedOp: BufferedImage pitfillerImage = renderedOp.getAsBufferedImage(); and work on with that instead of the JAI implementations of RenderedImage, everything works as it should. Operation is triggered in that moment and that's it. Any best practice around I could look at? Thanks Andrea On Fri, Nov 28, 2008 at 12:16 AM, andrea antonello <[EMAIL PROTECTED]> wrote: > Thanks for the info. It is important to know that at some point > investing in some additional tailored component will help, but we are > on the right trail :) > > I would like to go on in this thread to solve some problems related to > JAI operations. > > I am porting some morphological operations to jai operation level to > work in geotools. > I implemented an AreaOpImage, which worked well and now I am > implementing a PointOpImage. > > The problem first was that working on a source Planarimage of about > 2000x2000 pixels the the computeRect method was called several times > with teh writableraster as smaller 512 pixels size. > > To get started I tried to define cobbleSources as true, in order to > work just once on a single image. > I set the region on an area of about 200x200 and what happened was > that again the computeRect was called several times, every time with > the same rectangle size of 200x200. > > am I missing simething? Why is the method called more than once. > > Thanks > Andrea > > > > > On Thu, Nov 27, 2008 at 6:35 PM, Martin Desruisseaux > <[EMAIL PROTECTED]> wrote: >> andrea antonello a écrit : >>> Why would it make sense to use tiles when using a writable raster? >>> I mean, it was created in memory and therefore taking just tiles is >>> the same as taking it all? >> >> Probably in most cases. But it would also be possible (not sure if useful, >> but >> at least possible) that the JAI deferred execution model (where raster are >> computed only when first needed) actually creates WritableRaster. So it would >> allow user to modify a WritableTile after it has been computed. We would >> need a >> way to save those modifications (so they are not lost when a new computation >> is >> trigged), but a custom of TileCache may do the trick. >> >>> Or is there a way to already predefine a disk space on which the >>> writableraster in case would be dumped to? >> >> The default JAI implementation doesn't provide this functionality as far as I >> know, but I think we can do that by providing our own TileCache >> implementation. >> >> Martin >> > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
