1. Title : Image file of more than 5 MP are not shown in gallery 2. Precondition : Have images with resolution of more than 5MP 3. Tester's Action : 1. Copy images of more than 5 MP to SDCard 2. Other images are shown expect those more than 5 MP 4. Detailed Symptom (ENG.) : Images files should be displayed in gallery and user should be able to view files which are displayed in gallery 5. Gaia Revision #: de3e5b9205e6cb1a6bd0858a98d159272ad96d11 6. Expected : 7.Reproducibility: Y 1)Frequency Rate : 100% 8.Comparison Results : 1)Model Comparing : 9. Attached files: 1)Log : 2)Test Contents : 3)Video file :

This is a known issue that we have to limit the viewable image size under 5 MP to avoid the OOM problem, and I am not sure what's the suitable solution for now to deal with this. I guess the possible solution might be down sampling or resizing the image files before assgining to a img element so that the img element will not cause OOM? and this also depends on the memory limitaion on different hardwares, like 5 MP is some kind of magic number for unagi only I believe.

5mp isn't any kind of magic number. Its just a guess I put in there. I suppose we ought to make it configurable for each vendor. But the OOM issues are real, and they're now back in bug 847060, even with 5mp images. (If the images had suitable EXIF previews this wouldn't be a problem, but without the preview images, we get OOM.) The underlying issue is that gecko won't free up image memory right away, so quickly viewing images one after the other uses up memory that it would not otherwise. Dominic: your downsampling idea would be great, if it could work, but I think it requires gecko support. In order to down sample an image, we first have to decode it at full size, which uses memory. I'm wondering whether I need to modify the scanning and metadata parsing pass so that images without a preview image get a preview created (and saved to the sdcard) at the same time that we're creating the thumbnail.

Joe - can you reassign to make sure the limit is customizable on a per-partner basis?

CJ, someone from your team able to take this? thanks

SC/ TingYang, Please take this issue. 1. Image size limitation is define in app. 2. At gecko side, we should take care how to decode an image file on resource contrain device.

Our image decoder will store decoded image in a full-sized buffer. If we can restrict the dimension of decoded image buffer, we can ensure the upper bound of memory usage while displaying images. I'm not sure how many works it needs to decouple the real image dimension and image buffer dimension, will take time to investigate the feasibility. @joe, have any suggestion on reducing the memory usage for displaying large image files?

This patch is a proof of concept for reducing image buffer size while decoding a JPEG image that larger than 300 mega pixels. With this patch I can display a 800-mega-pixel image in gallery app on my otoro without oom.

> decoding a JPEG image that larger than 300 mega pixels. With this patch I should be 3 mega pixels. > can display a 800-mega-pixel image in gallery app on my otoro without oom. should be 8-mega-pixel

Comment on attachment 735626 [details] [diff] [review] WIP - directly downscale image size while decoding JPEG image Leaving this to one of the other 4 capable candidates :)

I think we settled on a better approach in bug 854795. Rather than imposing a limit on image size, which would break the Web, we allow pages to specify the image size they want using a media fragment. I think we should dupe this bug to bug 854783 and then fix this in bug 854795.

Thanks Justin, let's fix this in bug 854795.