<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
<html xmlns="http://www.w3.org/1999/xhtml";><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</head><body style="font-family: arial,helvetica,sans-serif; font-size:
13pt"><p><br></p><blockquote type="cite"><p style="font-family:
Arial,Helvetica,sans-serif; font-size: 14px;"><strong style="color:
#000;">envoyé :</strong> <span style="color: #666;">13 octobre 2020 à
12:22</span><br><strong style="color: #000;">de :</strong> <span style="color:
#666;">ede <e...@users.sourceforge.net></span><br><strong style="color:
#000;">à :</strong> <span style="color: #666;">"[jump-pilot:bugs] "
<5...@bugs.jump-pilot.p.re.sourceforge.net></span><br><strong style="color:
#000;">objet :</strong> <span style="color: #666;">[jump-pilot:bugs] Re: #507
GeoImage and high zoom level</span></p><br><div
class="ox-b1768e9a68-markdown_content"><p>On 10/12/2020 19:27, michael michaud
wrote:</p><blockquote><p>There are two problems in GeoImage.paint when using
very high level of zoom :<br> - the image to display is computed with jai
transformations like scaling, subsampling or cropping which use float
parameters : at very high levels of zoom, the lower right corner of the image
is not displayed at its right position compared with vector data which use
doubles for transformations.</p></blockquote><p>we could use the
vector(envelope) calculation results to scale the image. that'd solve the
disparity. questions is though which of the two is the more correct one, as i
understand that floating point has a higher accuracy than then doubles when
talking about small values.</p></div></blockquote><p>the envelope is already
used. In my test, I can see the problem on an image wich is exactly 10 000
pixels x 0.2m = 200m. Every corner of the image should be aligned with a grid,
either of 100m, 10m, 1m or 0.1m resolution.</p><p>But when the image size is
computed using floats (4 bytes of precision only, which is about 8 digits
instead of 16 for doubles) : we get 0.2f * 10000f = 2000.0000298023224 instead
of 2000.0 if we use double ()</p><p>Floating points have always a lower
accuracy. Doubles is the standard as far as JTS is concerned, and using floats
produce results with a lower accuracy.</p><blockquote type="cite"><div
class="ox-b1768e9a68-markdown_content"><blockquote><p>I tried to replace jai
transformations usinf floats by other transformations using doubles (like jai
affine transform), but it is much slower.</p></blockquote><p>performancewise we
might be able to switch scaling algorithms for some
operations</p></div></blockquote><p>In my tests to scale the image with the
full precision of doubles, I did not only switch operations, I completely
replaced the usage of jai (scaling/subsampling, cropping) by the usage of
Graphics2D.drawRenderedImage(Image, AffineTransform) which probably delegates
scaling/interpolation/cropping to awt.</p><p>With jai, the only scaling method
which seems to be very fast is the method using subsampling, and it uses float
parameters.</p><p>It is probably possible to switch between jai and awt method
depending on the scale level, but I'm afraid we obtain an illegant code quite
difficult to maintain. </p><blockquote type="cite"><div
class="ox-b1768e9a68-markdown_content"><blockquote><p>It seems that current
implementation efficiency is for a large part related to the use of subsample
jai transformation which is way faster than other type of scaling, but which
use float parameters.</p></blockquote><p>when we know which is more accurate
(float/double) we can can streamline vector/image calculation and the
difference would disappear</p></div></blockquote><p>Double is more accurate for
sure, but I don't understand what you mean by "streamlining vector/image
calculation".</p><blockquote type="cite"><div
class="ox-b1768e9a68-markdown_content"><blockquote><ul><li>the second point,
maybe related to the previous one is that zooming finally ends with an
exception : Caused by: java.lang.IllegalArgumentException: Crop The rectangular
crop area must not be outside the image.<br> at
javax.media.jai.JAI.createNS(JAI.java:1087)<br> at
javax.media.jai.JAI.create(JAI.java:973)<br> at
com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:298)</li></ul></blockquote><p>this
should probably be checked beforehand. of course it makes no sense to add a
crop if there is nothing to crop ;)</p></div></blockquote><p>Ya, it is probably
possible to catch the error. The problem is that the error is thrown in a
situation where the image should be shown (and where cropping should be
possible), but is not because of the roundings made by floats
usage.</p><blockquote type="cite"><div
class="ox-b1768e9a68-markdown_content"><hr><p><strong> <a
class="ox-b1768e9a68-alink"
href="https://sourceforge.net/p/jump-pilot/bugs/507/";>[bugs:#507]</a> GeoImage
and high zoom level</strong></p><p><strong>Status:</strong> open<br>
<strong>Milestone:</strong> OJ_future<br> <strong>Created:</strong> Mon Oct 12,
2020 05:27 PM UTC by michael michaud<br> <strong>Last Updated:</strong> Mon Oct
12, 2020 05:27 PM UTC<br> <strong>Owner:</strong> nobody</p><p>There are two
problems in GeoImage.paint when using very high level of zoom :<br> - the image
to display is computed with jai transformations like scaling, subsampling or
cropping which use float parameters : at very high levels of zoom, the lower
right corner of the image is not displayed at its right position compared with
vector data which use doubles for transformations. I tried to replace jai
transformations usinf floats by other transformations using doubles (like jai
affine transform), but it is much slower. It seems that current implementation
efficiency is for a large part related to the use of subsample jai
transformation which is way faster than other type of scaling, but which use
float parameters.<br> - the second point, maybe related to the previous one is
that zooming finally ends with an exception :<br> Caused by:
java.lang.IllegalArgumentException: Crop The rectangular crop area must not be
outside the image.<br> at javax.media.jai.JAI.createNS(JAI.java:1087)<br> at
javax.media.jai.JAI.create(JAI.java:973)<br> at
com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:298)</p><hr><p>Sent
from sourceforge.net because you indicated interest in <a
href="https://sourceforge.net/p/jump-pilot/bugs/507/";>https://sourceforge.net/p/jump-pilot/bugs/507/</a></p><p>To
unsubscribe from further messages, please visit <a
href="https://sourceforge.net/auth/subscriptions/";>https://sourceforge.net/auth/subscriptions/</a></p></div><div>
<br></div></blockquote></body></html>
---
** [bugs:#507] GeoImage and high zoom level**
**Status:** open
**Milestone:** OJ_future
**Created:** Mon Oct 12, 2020 05:27 PM UTC by michael michaud
**Last Updated:** Mon Oct 12, 2020 05:27 PM UTC
**Owner:** nobody
There are two problems in GeoImage.paint when using very high level of zoom :
- the image to display is computed with jai transformations like scaling,
subsampling or cropping which use float parameters : at very high levels of
zoom, the lower right corner of the image is not displayed at its right
position compared with vector data which use doubles for transformations. I
tried to replace jai transformations usinf floats by other transformations
using doubles (like jai affine transform), but it is much slower. It seems that
current implementation efficiency is for a large part related to the use of
subsample jai transformation which is way faster than other type of scaling,
but which use float parameters.
- the second point, maybe related to the previous one is that zooming finally
ends with an exception :
Caused by: java.lang.IllegalArgumentException: Crop The rectangular crop area
must not be outside the image.
at javax.media.jai.JAI.createNS(JAI.java:1087)
at javax.media.jai.JAI.create(JAI.java:973)
at
com.vividsolutions.jump.workbench.imagery.geoimg.GeoImage.paint(GeoImage.java:298)
---
Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/jump-pilot/bugs/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list._______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
