Scaling huge JPEG files leads to java.lang.OutOfMemoryError

[part_uploader]

I'm using Jumploader to upload scaled instances of JPEG images from my digital camera (10 Megapixel, ~2 MB filesize). This often leads to Applet Memory errors (i also tried it on your scaled instance demo page)

When I use smaller JPEGs, this doesn't happen. I can provide you with sample images if necessary.

[...previous lines omitted...]
11.01.2009 19:45:01 - DEBUG - Invoking JS method uploaderFileStatusChanged([Ljava.lang.Object;@14afa30)
11.01.2009 19:45:01 - DEBUG - uploadThread uploadThread_0, current file: Upload File [status:1, path:C:\Dokumente und Einstellungen\ichbinich\Eigene Dateien\Eigene Bilder\GeoTagTest\PA051487.JPG] uploading Upload File [status:1, path:C:\Dokumente und Einstellungen\ichbinich\Eigene Dateien\Eigene Bilder\GeoTagTest\PA051487.JPG]
11.01.2009 19:45:02 - DEBUG - file status change: Upload File [status:1, path:C:\Dokumente und Einstellungen\ichbinich\Eigene Dateien\Eigene Bilder\GeoTagTest\PA051487.JPG]
11.01.2009 19:45:02 - DEBUG - uploader status change: uploader, status:0
Exception in thread "uploadThread_0" java.lang.OutOfMemoryError: Java heap space
11.01.2009 19:45:02 - DEBUG - Invoking JS method uploaderFileStatusChanged([Ljava.lang.Object;@19568ff)

here are my applet settings

[code]
<applet id="jumploader" name="jumpLoaderApplet" code="jmaster.jumploader.app.JumpLoaderApplet.class" archive ="static/java/jumploader_z-291.jar" width="715" height="500" mayscript>
<param name="uc_imageEditorEnabled" value="false"/>
<param name="uc_uploadUrl" value="upload"/>
<param name="uc_sendExif " value="true"/>
<param name="uc_sendFilePath" value="true"/>
<param name="uc_uploadScaledImages" value="true"/>
<param name="uc_minFileLength" value="100000"/>
<param name="uc_directoriesEnabled" value="true"/>
<param name="uc_preserveRelativePath" value="true"/>
<param name="uc_scaledInstanceNames" value="thumbfile"/>
<param name="uc_scaledInstanceDimensions" value="200x200"/>
<param name="uc_scaledInstanceQualityFactors" value="900"/>
<param name="ac_fireAppletInitialized" value="true"/>
<param name="ac_fireUploaderFileAdded" value="true"/>
<param name="ac_fireUploaderFileStatusChanged" value="true"/>
<param name="vc_useThumbs"value="true"/>
<param name="vc_lookAndFeel"value= "system"/>
<param name="uc_fileNamePattern" value="^.+\.(?i)((jpg)|(jpe)|(jpeg)|(gif)|(png))$"/>
<param name="vc_fileNamePattern" value="^.+\.(?i)((jpg)|(jpe)|(jpeg)|(gif)|(png))$"/>
</applet>
[/code]

[part_uploader]

see update below

[part_uploader]

UPDATE:

The Upload failure mustn't necessarily be caused by the image size. I conducted a few tests on your Scaled Instances Demo page and found out that also corrupted EXIF/IPTC metadata could be a cause.

My test showed that the upload failure occurs with multiple high-res JPEG files that have EXIF/IPTC metadata attached. When I programmatically removed the metadata, I had no problems. However, as I don't know about Jumploader's internals, I can't guarantee for this assumption.

To ease further debugging, I provide a ZIP with 3 high res JPEGs that caused upload errors when added all at once to the upload queue.

http://www.buchinger.biz/jl-scaled-instances/failed_upload.zip

regards,

Franz

[part_uploader]

Some links that might help on the problem

http://java.sun.com/products/java-media/jai/forDevelopers/jaifaq.html#memory1

http://today.java.net/pub/a/today/2007/04/03/perils-of-image-getscaledinstance.html



regards,

Franz

[jmaster]

Here are alternative scaling implementations for testing: http://jumploader.com/_test/is/imageScaleTest.html

As you can see, there are 3 methods:
1) Default - load image "as is", then scale - current method jumploader use
2) Subsampled - loads subsampled images (read each N-th pixel for axis, drop others). I.e. subsampled image dimension is source image dimension / factor. Subsampled image scaled to result.
3) Tiled - creates buffer image (tile size * tile size) and target image (that have same ratio as source image and fits into box specified by "Box size"). Then starts loop, that reads portion of source image to buffer (tile) and scales tile to target image correponding tile location. Then target image scaled to result.

I've tested with 12Mpx images (may get some from here: http://www.dpreview.com/gallery/canoneos5d_samples/) using form defaults, and here are results (time to process, mem used). You can see memory pressing 'm' in java console, for example this:
Memory: 65 088K Free: 9 444K
Says that 65 088 - allocated, 9 444 - free, i.e. 55 644 used.
Hit 'g' before each test to garbage collect

1) 2s, 55M (hey, I still can't see OOM error!)
2) 1.5s, 15M
3) 9s, 10M

Imho all result images are equal in quality.
What do you think?

[Skype]

Hi Jmaster,

The image quality is great here (FF on XP and Safari on OSX).

Either solution should work great for my purposes.

p.

[part_uploader]

Hi jmaster,

thanks for digging into this!

Here is my feedback on the three methods and their application:

1) Default Scaling Method

For Images < 2 Megapixel you could use the Default Scaling Method (the risk of getting an out of memory error is quite low with these small images, and if, you could catch the OutOfMemory exception and try another scaling method).

2) Subsampling

Subsampling is a great option because it significantly decreases memory demands and is quite performant (contrary to the Tiling approach). However it's downside is that it only works when the image is scaled down to at least 50% of its length and width (which is the default case in most of the time with high-res pictures).

3) Tiling

Tiling is the slowest method, but it works for High-Res-Pictures and imposes no limits on the scaling ratio. For some less obvious uses it still has its application, e.g. scaling down a 12 Megapixel image to 80% of its size and applying a better compression to save upload time.

I think you should handle the scaling options implicitely and choose the best method depending on image size and scaling ratio.

About your memory limits: 50megs is only the scaling part, but i guess in conjunction with Uploading/Scripting API the memory might quickly exceed the 64 MB limit of JVM.


greetings,

Franz

[part_uploader]

Hi jmaster,

when do you plan to release a jumploader version with the improved scaling engine?

Can't wait to try it out!

greetings,

Franz

[jmaster]

In a 2-3 days.

[part_uploader]

Hi Jmaster,

thanks for the great release! I will test it in detail tomorrow. Just some questions in advance concerning the changes:

- is the ImageSubsampling Factor turned on by default, or do I have to activate it by using the UploadOption?

If I unterstand the Subsampling Formula right, the subsampling ratio correlates with the Megapixel size, i.e., if i upload a 1 Megapixel file, then you scaling function reads every pixel of the source Image, but when I upload a 10 Megapixel file then I get a subsampling ratio of
1+ 10/7 = 2,42 which means that every second pixel in x and y is read?

- unfortunately, jmimemagic is poorly documented. what filetypes can it detect/how do i specify a mimetypepattern?

Thanks a lot in advance,

Franz

[jmaster]

Hello Franz,

- image subsampling default value is 7, you can turn subsampling off specifying 0 value.
- yes, you understanding is correct. in simple words, subsampling increased by one each time image MPX increased by subsampling factor. thus SS=1 for images 0..7MPX, 2 for 7..14 and so on (if SSF=7).
- jmimemagic can match common file types (images, documents, media files), at least bundled test worked fine. anyway, you can download and check that yourself. even more, you can extend magic.xml and use that (if you know what are you doing). mimeTypePattern usage is similar to fileNamePattern - specify regex for file being added, this will be added if filetype matches pattern, error message will show if not. For example specify image/.* to allow image files only.

[part_uploader]

Hi again,

thanks for your explanations! Only one question remains: where do I find the magic.xml file (i already inspected the .jar, but couldn't locate it). Or do i have to provide it with an additional UploadConfig parameter?

greetings,

Franz

[jmaster]

Sorry, the magic.xml was missing from jar jar was missing due to invalid build - fixed now.
Somewhy jmimemagic succesfully detects content type for particular files, but returns "???" result for mimetype. Here is sample output for .exe file:

[jmaster]

Previous post was edited - green - added, red should be trated as removed.