Ciao Martin, What do you mean by the fact that Affine operation was failing? I think this might bring an important use case in the picture, but as of now I can't remember any discussion on this issue ( I might be remembering wrong of course). Anyway, before discussing about the rounding issue itself I guess it would be worth to know something about this issue with Affine.
Ciao, Simone. On Mon, Jul 28, 2008 at 12:32 PM, Martin Desruisseaux <[EMAIL PROTECTED]> wrote: > > Simone Giannecchini a écrit : >> >> Well, with the given semantic I might get an error back since it might >> really be that w and/or h in the raster space are 0 after the >> rounding you describe in the javadoc. >> Same thing would not apply if we followed JAI's or >> (rectangle2d.getBounds() if you like) approach. >> >> What do you think about this issue? > > I think it is a hard one... I remember that I while ago I spend a few days > inspecting why "Affine" operation was failing until I identified this > rounding mode issue. > > If we just replace the current GeneralGridRange behavior by the JAI's one, we > would move the exception from one place to an other. It would work for images > cropped to 1x1 pixels, but resampling of ordinary images using the "Affine" > operation would fails in some cases. It was a while when I worked on this > issue, so we may need to try in order to revisit what the exact error was. > But I think it was related to the images being 1 pixel larger than expected. > The javadoc gives the example of the [-0.25 ... 99.75] range rounded to [-1 > ... 100], but in practice the real cases are rather ranges like [-0.0000001 > ... 99.9999999]. We intented [0 .. 100], but rounding in the JAI's way gives > us [-1 .. 100]. > > The above problem could be avoided by usage of some small tolerance value (an > epsilon). But the choice of that epsilon value is an arbitrary choice, one > that I usually find hard to choose. As a comparaison, > java.awt.geom.AffineTransform uses a tolerance value but has a quite > extensive discussion about it. You can look at > http://java.sun.com/javase/6/docs/api/java/awt/geom/AffineTransform.html and > scroll down to "Handling 90-Degree Rotations". On my side, I'm unable to > provides such a good and rigourous discussion (I may look naive, but one > reason why I like so much Sun's technology is that I tend to be admirative > with the way they nail down their choices with theorical background). The > "nearest integer" rounding mode was a way to eliminate completly the need for > an arbitrary epsilon value, but it was done at the sacrifice of JAI's > semantic (smallest envelope containing fully the original one). > > Cropping to the smallest image that contains fully the requested envelope > make a lot of sense. But if we do so the "epsilon value" issue will be back, > and we would need to test Resample2D (especially when delegating to JAI's > "Affine") for trying to identify what was its issues (I don't remember > exactly which exception we got) and if we can find a workaround. > > One possible approach could be that a GeneralGridEnvelope working in JAI's > rounding mode may needs an explicit "epsilon" argument. But it just push the > choice later (we would still need to choose an epsilon value in Resample2D). > > An other, less disruptive approach would be to make a special case for 1x1 > images only. > > Do you need the JAI's behavior in the general case, or would it be suffisient > to make a special case of the 1x1 pixel case? If we needs the JAI's behavior > in the general case, do you have any though about the epsilon value issue? > (do we need it, which value, where to specify 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 ------------------------------------------------------- ------------------------------------------------------------------------- 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-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
