georeferenced images can't be scaled with mouse wheel, NullPointerException

[anonymous]

Only portrait images seem to be affected, landscape images are not.

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2017-12-02 00:59:36 +0100 (Sat, 02 Dec 2017)
Build-Date:2017-12-02 02:33:20
Revision:13180
Relative:URL: ^/trunk

Identification: JOSM/1.5 (13180 de) Linux Debian GNU/Linux 9.1 (stretch)
Memory Usage: 1035 MB / 2000 MB (649 MB allocated, but free)
Java version: 1.8.0_151-8u151-b12-1~deb9u1-b12, Oracle Corporation, OpenJDK 64-Bit Server VM


=== REPORTED CRASH DATA ===
BugReportExceptionHandler#handleException:
No data collected.

Warning issued by: BugReportExceptionHandler#handleException

=== STACK TRACE ===
Thread: AWT-EventQueue-1 (17) of main
java.lang.NullPointerException
	at org.openstreetmap.josm.tools.ImageProvider.createScaledImage(ImageProvider.java:1411)
	at org.openstreetmap.josm.gui.layer.geoimage.ImageDisplay.paintComponent(ImageDisplay.java:659)
	at javax.swing.JComponent.paint(JComponent.java:1056)
	at javax.swing.JComponent.paintChildren(JComponent.java:889)
	at javax.swing.JComponent.paint(JComponent.java:1065)
	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5210)
	at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:290)
	at javax.swing.RepaintManager.paint(RepaintManager.java:1272)
	at javax.swing.JComponent._paintImmediately(JComponent.java:5158)
	at javax.swing.JComponent.paintImmediately(JComponent.java:4969)
	at javax.swing.RepaintManager$4.run(RepaintManager.java:831)
	at javax.swing.RepaintManager$4.run(RepaintManager.java:814)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:814)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:789)
	at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:738)
	at javax.swing.RepaintManager.access$1200(RepaintManager.java:64)
	at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1732)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
	at org.GNOME.Accessibility.AtkWrapper$5.dispatchEvent(AtkWrapper.java:700)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

[Don-vip]

can you please attach your image?

[anonymous]

You can create a image, which triggers this bug:

convert -size 4128x3096 xc:white jpeg:- | exiftool -Orientation#=6 -GPSLongitudeRef=E -GPSLongitude=139.0 -GPSLatitudeRef=N -GPSLatitude=35.0 - -o test.jpg

[Don-vip]

The command gives me:

Error: Can't create JPEG files from scratch

Can you please attach your test.jpg?

[Don-vip]

Thanks.
@cmuelle8: do you think this would be enough?

ImageDisplay.java

@@ -652 +652 @@
 
             if (selectedRect == null && bilinLower < scale && scale < bilinUpper) {
                 BufferedImage bi = ImageProvider.toBufferedImage(image, r);
-                r.x = r.y = 0;
+                if (bi != null) {
+                    r.x = r.y = 0;
 
-                // See https://community.oracle.com/docs/DOC-983611 - The Perils of Image.getScaledInstance()
-                // Pre-scale image when downscaling by more than two times to avoid aliasing from default algorithm
-                image = ImageProvider.createScaledImage(bi, target.width, target.height,
-                            RenderingHints.VALUE_INTERPOLATION_BILINEAR);
-                r.width = target.width;
-                r.height = target.height;
+                    // See https://community.oracle.com/docs/DOC-983611 - The Perils of Image.getScaledInstance()
+                    // Pre-scale image when downscaling by more than two times to avoid aliasing from default algorithm
+                    image = ImageProvider.createScaledImage(bi, target.width, target.height,
+                                RenderingHints.VALUE_INTERPOLATION_BILINEAR);
+                    r.width = target.width;
+                    r.height = target.height;
+                }
             } else {
                 // if target and r cause drawImage to scale image region to a tmp buffer exceeding
                 // its bounds, it will silently fail; crop with r first in such cases

[cmuelle8]

@Don-vip: No, the problem is not the orientation of the plain image,
but what results from applying the exif orientation tag.

I.e. if you create images like this

PARAM="-GPSLongitudeRef=E -GPSLongitude=139.0 -GPSLatitudeRef=N -GPSLatitude=35.0"
convert -size 4128x3096 xc:white jpeg:- | exiftool $PARAM - -o test-landscape.jpg
convert -size 3096x4128 xc:white jpeg:- | exiftool $PARAM - -o test-portrait.jpg

they will work without problem.

If you looked at attachment:josm-image-loading_check-ram-constraints-to-prevent-oom-exceptions_do-not-use-expensive-scaling-while-dragging.patch:ticket:15574​ you recognized that it already does contain the check if (bi != null) { .., but it will not solve the issue of this ticket.

This may not be a regression. Have you checked that the test image in comment:3 really works with older versions (e.g. r13037 or earlier)?

Since test-landscape.jpg and test-portrait.jpg work, I suspect the root cause to be within the range of line 251​ and line 269​ of trunk/src/org/openstreetmap/josm/gui/layer/geoimage/ImageDisplay.java?rev=13186​.

It's probably better to create a new VisRect there (so that init is set correctly), instead of just swapping width and height of the one already created at this point. I'll update the attachments of ticket:15574 to contain this fix within some minutes, once I've tested the fix.

[cmuelle8]

@Don-vip:

src/org/openstreetmap/josm/gui/layer/geoimage/ImageDisplay.java

@@ -242 +242 @@
                 }
 
                 if (!error) {
-                    ImageDisplay.this.image = img;
-                    visibleRect = new VisRect(0, 0, img.getWidth(null), img.getHeight(null));
+                    int width = img.getWidth(null);
+                    int height = img.getHeight(null);
 
-                    final int w = (int) visibleRect.getWidth();
-                    final int h = (int) visibleRect.getHeight();
-
+                    boolean switchedDim = false;
                     if (ExifReader.orientationNeedsCorrection(orientation)) {
-                        final int hh, ww;
                         if (ExifReader.orientationSwitchesDimensions(orientation)) {
-                            ww = h;
-                            hh = w;
-                        } else {
-                            ww = w;
-                            hh = h;
+                            width = img.getHeight(null);
+                            height = img.getWidth(null);
+                            switchedDim = true;
                         }
-                        final BufferedImage rot = new BufferedImage(ww, hh, BufferedImage.TYPE_INT_RGB);
-                        final AffineTransform xform = ExifReader.getRestoreOrientationTransform(orientation, w, h);
+                        final BufferedImage rot = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB);
+                        final AffineTransform xform = ExifReader.getRestoreOrientationTransform(orientation,
+                                img.getWidth(null), img.getHeight(null));
                         final Graphics2D g = rot.createGraphics();
-                        g.drawImage(image, xform, null);
+                        g.drawImage(img, xform, null);
                         g.dispose();
-
-                        visibleRect.setSize(ww, hh);
-                        image.flush();
-                        ImageDisplay.this.image = rot;
+                        img.flush();
+                        img = rot;
                     }
+
+                    ImageDisplay.this.image = img;
+                    visibleRect = new VisRect(0, 0, width, height);
+
+                    Logging.info("Loaded "+file.getPath()+
+                            " with dimensions "+width+"x"+height+
+                            " exifOrientationSwitchedDimension="+switchedDim);
                 }
 
                 selectedRect = null;

This patch will solve this ticket, but you know I'd rather like you to apply the smaller patch of ticket:15574. It will close this one and fix scaling while dragging, among some other minor stuff.

Greetings

[anonymous]

Replying to cmuelle8:

This may not be a regression. Have you checked that the test image in comment:3 really works with older versions (e.g. r13037 or earlier)?

It works with r12976.

[anonymous]

It also works with r13056!

[anonymous]

r13119 is also working!

[cmuelle8]

@Don-vip:
BTW: If exif orientation causes the AffineTransform to apply, rot is allocated. rot will need the same size as img, so we need memory available that can hold both rot and img until img = rot; is carried out and the garbage collector frees the old img.

This is another reason to rather directly apply the smaller patch of ticket:15574, because it will only load images, if there is enough mem left to carry out such an operation.

@anonym:
Thanks for checking. Issue should be fixed within the next couple of changesets. Please note that r13056 and r13119 had worse issues with image scaling, see ticket:15511.

[anonymous]

r13128 is NOT working.
So the bug has been introduced between r13119 and r13128.

[anonymous]

Replying to cmuelle8:

@anonym:
Thanks for checking. Issue should be fixed within the next couple of changesets. Please note that r13056 and r13119 had worse issues with image scaling, see ticket:15511.

Ok, thanks!

[Don-vip]

In 13191/josm:

fix #15625, see #15574 - geo image loading: do ram constraint checking; add some javadoc; do not use bilinear scaling when image is dragged (patch by cmuelle8, modified)

[Don-vip]

Ticket #16196 has been marked as a duplicate of this ticket.