Picasso: Large images do not load

[christopherperry]

I'm loading very large images from a local 'Uri' and scaling with resize() (also calling skipMemoryCache()). Picasso silently fails. Smaller images load fine with the same code. I was using an older version of Picasso and was seeing OOM logged. I tried the latest version and the problem persists, but the log is now nonexistent.

Can you point me to the code that decodes the Bitmaps?

[JakeWharton]

If you exceed the max texture size of GL the image will silently fail to decode. The various implementations of BitmapHunter to the decoding based on the source.

[dnkoutso]

What is the URL here?

[christopherperry]

These are local Uri from images taken from the Camera on high res Sony phones.

[JakeWharton]

What size? format? Picasso command in use? We can't really know what's happening here without some information to try and reproduce or debug.

[christopherperry]

Standard call:

Picasso.with(context) //
  .load(uri) //
  .resize(screenWidth, screenHeight) //
  .get();

Screen size is 1080 x 1920.

[JakeWharton]

How big is the image and what format is it in? What device and how much heap does it have? Maybe post a sample image so we can try to reproduce or debug.

[christopherperry]

Images are 13 megapixel (I'm pretty sure). JPG format.

These are JPG bytes coming straight from

void takePicture(ShutterCallback shutter, PictureCallback raw, PictureCallback jpeg)

in the Camera class.

[dnkoutso]

Device? Android version?

[christopherperry]

I don't think it matters. I'm actually not sure at this point, I rolled my own code and moved on. We have a ton of Xperia phones lying around. I'm actually too busy babysitting team members right now to dig further into this.

[dnkoutso]

Would love to help generally. I am closing for now.

[christopherperry]

Raw image {w, h} = {3840, 2160}

[dnkoutso]

Assuming RGB_8888 (which is default) this is:

3840 * 2160 * 4 = 33MB image

Switching to RGB_555 will be around 8mb but will reduce quality...

skipMemoryCache() has no effect on the decoding. The bitmap will be loaded in memory so it can be displayed. It just wont be stored for future usage or evict other images.

It will also allocate intermediately a new bitmap for 1920x1080 for your transformation. Both bitmaps would be in memory for a bit of time until the original is recycled and gc'ed.

You probably need android:largeHeap=true in your manifest to load this.

[christopherperry]

Shouldn't you just decode the bounds before decoding the final scaled version? This only puts the scaled version into memory. You shouldn't have the full size image in memory if you know the user is scaling.

What I mean is, calculate the BitmapOptions.inSampleSize (even if it's just 1) and always use that during decode.

I rolled my own code and got this working no problem.

[JakeWharton]

We do that already.

[christopherperry]

It will also allocate intermediately a new bitmap for 1920x1080 for your transformation. Both bitmaps would be in memory for a bit of time until the original is recycled and gc'ed.

Gives the impression that you don't.

[JakeWharton]

Well you didn't really provide a concise description of what you were loading or how so we have to guess at a lot of it.

[AllenVork]

I encountered the same problem.when i invoke resize option,big pictures(such as the pictures that the camera captures) will not show