memory overflow loading/working with photos

[johnw]

Loading photos can lead to out of memory reports. This happens on a machine with over 600Mb of ram. Presumably all the photos are being held in memory, instead of extracting the relevant exif data and a thumbnail (suggest on full display of photo load it from disk -- on large ram caching will automatically make this fairly fast anyway).

[imi]

see #110

[anonymous]

working with geotagged photos seems to have a memory leak, too. (though it is a great feature)

loading an 1mb image several times leads to "out of memory. strange things can happen. please restart". reproduceable on a machine with 1 gb ram working on a small space

[josmbugs@…]

I've been looking at this - for my use-case, I'd like to be able to sensibly deal with a photo a second, taken from the back of the car.

Currently - though it sort-of-works, it does not work well.

What would be ideal (for me) would be to make the thumbnails optional.
Add two panels, a GPS/waypoint panel, and an image display.

The first would have the following details filled in when hovered over a GPX point (loaded tracks only):

---

Speed:    30MPH
Altitude: 200M

###############
###############
###         ###
###  Image  ###
###         ###
###############
###############

Name: foo
Distance: 10m nw.

---
The first two lines are populated from the GPX trackpoint that the cursor is hovering over.
This is of use for working out layer tags, and places where you slowed or stopped.

The second half of this panel displays waypoints.

It shows waypoints from loaded GPX files.
If the waypoint contains an ImageUrl(is there a standard?) tag in the GPX file, then this is displayed.

The idea is that you load a raw GPX track, perhaps with waypoints, perhaps not.
You then supply a URL - which may be ​file:/// where a directory of pictures is, with EXIF tags, and do the existing 'sync' thing.

Now, right-clicking this waypoint layer - which has trackpoints, waypoints loaded from the GPS, and waypoints created for the pictures with ImageUrl tags - gives another option - Save.

When saving this combined layer, there are several options - keep the base URLs as ​file:///photos/1.jpg, or alter them to ​http://mywebsite.com/images/1.jpg.

This means that you can either save the GPX track, and reload it later and use it.
Or you can upload it to OSM with the URLs setup to be accessible by anyone.

The waypoint layer would when active show loaded waypoints, which may or may not include thumbnails.

[framm]

The out of memory problem should be fixed now. The other suggestions have not been worked on.

[Holger Leskien <holger@…>]

I get still (snapshot 411) an error while viewing too much images. I believe, the (another?) problem is in the viewer. The memory seems not to get freed.

java.lang.OutOfMemoryError: Java heap space

at java.awt.image.DataBufferInt.<init>(DataBufferInt.java:41)
at java.awt.image.Raster.createPackedRaster(Raster.java:458)
at java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:1015)
at sun.awt.image.ImageRepresentation.createBufferedImage(ImageRepresentation.java:235)
at sun.awt.image.ImageRepresentation.setPixels(ImageRepresentation.java:487)
at sun.awt.image.ImageDecoder.setPixels(ImageDecoder.java:120)
at sun.awt.image.JPEGImageDecoder.sendPixels(JPEGImageDecoder.java:97)
at sun.awt.image.JPEGImageDecoder.readImage(Native Method)
at sun.awt.image.JPEGImageDecoder.produceImage(JPEGImageDecoder.java:119)
at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:246)
at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:172)
at sun.awt.image.ImageFetcher.run(ImageFetcher.java:136)

[anonymous]

i can acknowledge that the error is still there. (using version 479)

way to reproduce:

• load ~60 images (~1mb per image)
• click on different thunmbnails several (~10) times
• error occurs

[Gabriel Ebner <ge@…>]

I tried reproducing this. I loaded about a hundred images and clicked on them, but memory usage only increased by a few megabytes. This is using java 6 on amd64.

Maybe this is due to some JVM's doing excessive caching. Could you please post which java version you are using?

[Harry Wood]

bug #526 seems to be a duplicate of this, but there's a suggested fix there. Is that the kind of fix which has been made?

The fix seems to have improved the situation a lot. I can now load in over 100 large images, and flick through them. Much improved, but I think there may still be some spurious memory problems.

One thing I notice, is that you can open more that one photo window at once. Is that a deliberate feature? because if you click several photos in the background, the windows open in exact alignment on top of each other, so you might not realise it's opening many windows. I got an out of memory error when I did too much of that. ...but that's not so surprising I guess.

[christian.gallioz@…]

In fact, it seems that it's indeed the same as #526. Sorry, I didn't search correctly before creating that second ticket. The fix I gave was only for Geotagged plugin, but I reckon that it's the same problem in JOSM, and that the fix can be adapted.

So, on my system (Ubuntu i386, JVM Sun 1.6.0_03, 1Gb ram), the new ImageIcon(String filename) method seems to keep a cache of the loaded images (so, as this method is called on the full size images, the memory gets full quickly when loading many photos). This method probably relies on java.awt.Toolkit.getImage() method. That's why I proposed to use the Toolkit.createImage() method instead, which doesn't keep a cache of the image. But then, we have to manage the fact that the image data is loaded asynchroneously (ImageIcon constructor was useful for that it returned the image only after it was fully loaded),

[framm]

This bug is still unsolved. JOSM currently creates a BufferedImage instance when it displays a scaled image, but that is definitely released when the image is not longer shown. I can load 100s of images in sequence and nothing breaks. But others still report out of memory problems.

[anonymous]

are you using a start script for josm, because java's default settings ignore your actual amount of memory and limit heapspace to 64mb. try starting josm with

java -Xms128m -Xmx512m -jar josm-latest.jar

[Hasienda]

Even if I closed #516 now as a duplicate, it might be well worth the time to read there about a solution, as already proposed by christian.gallioz@… almost 11 months before.

[stoecker]

Fixed in r1183.