strmchsr / sanselanandroid

Automatically exported from code.google.com/p/sanselanandroid
0 stars 0 forks source link

Low or out-of-memory reported when writing EXIF into an existing image. #1

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Call one of the ExifRewriter.updateExifMetadataXXXX methods to update 
the EXIF of a large image (e.g. one with 6MBytes of image data).

What is the expected output? What do you see instead?
Updating the EXIF should happen without out-of-memory errors thrown by 
Android or even emergency soft-reference clean-up by Android.

Please use labels and text to provide additional information.
OutOfMemory, Large Image

Original issue reported on code.google.com by flyingdu...@gmail.com on 3 Oct 2009 at 4:03

GoogleCodeExporter commented 9 years ago
The out-of-memory was caused by a getStreamBytes(InputStream is) call in the 
JpegUtils.traverseJFIF method. It reads all the image-data of the image into a 
byte-
array. This array can get too large and an out-of-memory can be thrown.

This byte-array is held onto for a while until the image (data and exif) is 
finally 
written out. 

The idea of the fix is this:
Instead of lugging around a large byte-array, why not hold on to the 
input-stream 
instead. This will save a lot of memory. When the image-data needs to be 
written 
out, instead of writing a byte-array, the contents of the input-stream are 
written 
out instead.

Changes:

Add one more method to JPegUtils.Visitor interface:
public boolean visitSOS(int marker, byte markerBytes[], InputStream is);
It differs from the other 'visitSOS' method in that it accepts an input-stream 
instead of a byte-array.
This method returns true only if the implementor of this method will close the 
given 
InputStream itselft. If the method returns false, the caller should close the 
InputStream.

Change all implementations of JpegUtils.Visitor to implement this new method. 
All but two of the implementations do absolutely nothing when this method is 
called, 
except returning false (the caller should close the specified InputStream).

The other two will store the InputStream in an instance-member:
   ExifRewriter.analyzeJFIF implements this.
   JpegRewriter.analyzeJFIF implements this.

Both these two implement this method by adding a new new JFIFPieceImageData
(markerBytes, is) to the JFIFPieces.pieces list. When the 
JFIFPieceImageData.write
(OutputStream) method is called, the stored InputStream will write all its data 
out 
to the specified OutputStream (and close the InputStream).

Modify JpegUtils.traverseJFIF:
Remove the call to 'getStreamBytes(is)'.
Call 'doClose = !visitor.visitSOS(marker, marketBytes, is)' instead.
Only if 'doClose' is true, close the inputstream 'is' in the finally block.

Original comment by flyingdu...@gmail.com on 3 Oct 2009 at 4:22