Modify

Opened 12 years ago

Closed 10 years ago

Last modified 5 years ago

#84 closed enhancement (fixed)

memory overflow loading/working with photos

Reported by: johnw Owned by: imi
Priority: trivial Milestone:
Component: Core Version: latest
Keywords: many photos memory overflow Cc:

Description

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).

Attachments (0)

Change History (13)

comment:1 Changed 12 years ago by imi

see #110

comment:2 Changed 12 years ago by anonymous

Keywords: photo memory added
Summary: memory overflow loading photosmemory overflow loading/working with photos
Version: release

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

comment:3 Changed 12 years ago by josmbugs@…

Type: defectenhancement

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.

comment:4 Changed 12 years ago by framm

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

comment:5 Changed 12 years ago by Holger Leskien <holger@…>

Type: enhancementdefect
Version: releaselatest

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)

comment:6 Changed 11 years ago by 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

comment:7 Changed 11 years ago by 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?

comment:8 Changed 11 years ago by 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.

comment:9 Changed 11 years ago by 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),

comment:10 Changed 11 years ago by 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.

comment:67 Changed 11 years ago by 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

comment:68 Changed 10 years ago by Hasienda

Keywords: many photos overflow added; photo removed

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.

comment:69 Changed 10 years ago by stoecker

Resolution: fixed
Status: newclosed

Fixed in r1183.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain imi.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.