Media.insertImage locked to heavy compression

by Julian » Tue, 22 Jun 2010 04:28:16 GMT

Sponsored Links
 So from what I can tell Media.insertImage is locked to heavy
compression on all images. This includes when passing in the path to a
photo in the filesystem. As a test I used a 3000x2000 pixel jpg which
had been previously saved at maximum quality and was ~6MB. After
passing the path to Media.insertImage, the resultant copy (still
3000x2000) is 623KB.

I passed in another copy of the 3000x2000 image, this one compressed
down to 393KB. After Media.insertImage, the image filesize is 492KB.

I'm wondering if there's a way to specify the compression when images
are saved by insertImage.

I'm also wondering why this is recompressing jpgs, rather than simply
copying them into DCIM. A side-effect of opening and re-compressing
these images is that it imposes a rather low VM cap on what
insertImage can handle. I'm getting out-of-memory errors when trying
to pass the path of a 10 megapixel image.

As an aside: are there any problems with a developer creating their
own file/folder structure under DCIM? Is this frowned upon?

Thanks for any thoughts,



Media.insertImage locked to heavy compression

by Julian » Tue, 22 Jun 2010 04:34:16 GMT

 I've done some tests with the insertImage call and it looks like it
hard coded to always use a high rate of compression. In my tests I
took a 3000x2000 pixel image, which is ~6MB as a jpeg at max quality,
and passed the file path in to insertImage. The image that was saved
to the phone's DCIM folder ends up being ~600KB, which is tiny for a 6
megapixel image. (I also tried passing in the path to the same
3000x2000 image, this time saved at minimum quality, which made it
around 300KB. After passing through insertImage the resultant image
was ~400KB.)

I have a few questions:
- is it possible to vary the compression that insertImage uses when it
- why is insertImage reading in a jpeg and then writing it back out,
rather than simply copying it? in addition to the undesirable effects
of repeated lossy compression on the same image, this means that the
device's VM becomes a limiting factor. in practice this means that
insertImage fails on a 10 megapixel image on my n1
- finally, are there any guidelines or rules on writing an image
myself to the device's DCIM folder? is this an accepted practice or
frowned upon? in addition to avoiding repeated compression on my
images, this would allow me to create my own subfolder, giving my
images their own gallery

(I tried submitting this a day ago and haven't seen it show up; I'm
not sure if this is simply how long it takes, or if my message got
lost in the shuffle somewhere, so I'm resubmitting.)


Sponsored Links

Other Threads

1. Shared code for free and paid app


i have published a free app on the market. Now i want to create a
second "pro" (paid) app. According to

i have to publish the new paid app with a different package name.

Is there a way to share the same code for both apps, including
resources (styles, strings, etc)?



2. how many devices have the nexus one / HTC desire multi touch bug and would you release a game utilizing multitouch anyway?

so there's the multitouch issue with the Nexus One and HTC Desire. Is
there some documentation on what other devices have this hardware
error and what the total market share is?

If you had a game idea that needs massive multitouch gestures, would
you go for it on Android or would it currently be a waste of time with
only a few devices supporting it?



3. XMLHttpRequest on Android 2.1 repeats itself after 14 seconds

4. Aplikasi ym android

5. ASK : Gadget dengan lcd 4" ke atas

6. Lapor! Kecepatan internet telkomsel flash

7. cyanogenmod froyo update ver.7.1 (spica)