Picasso: Rotation issues for loaded image on Picasso 2.4.0

Created on 28 Apr 2015  Â·  6Comments  Â·  Source: square/picasso

Hi,

This image:
http://files.parsetfss.com/da393543-4c5b-4303-9227-491994a9f182/tfss-55ea9699-dd4d-451c-8421-1a41af5a4a20-photo_20150428_161247_XtgKPdVVkz.jpg

Loads fine in my browser

But in my android app:
screenshot_2015-04-28-12-16-51

It looks rotated.
I know the picture was taken by my iOS dev using his iPhone.

Any clue if I can solve that?

All 6 comments

No. We do not honor EXIF on images downloaded from the network. Dupe #846.

Hi Jake,

Thanks for the quick answer

So as I understand it, I should check myself for an EXIF tag, and if any rotation is here, use rotate?
https://square.github.io/picasso/javadoc/com/squareup/picasso/RequestCreator.html#rotate-float-

Any code snippet that exists already or should I just use?
http://stackoverflow.com/questions/3647993/android-bitmaps-loaded-from-gallery-are-rotated-in-imageview

Thanks a lot for your help

Stephane

Unfortunately there's no easy way to accomplish this. We rely on Android for decoding and it doesn't honor the tag. The only place to actually read the tag would be in a custom Downloader, but you don't have a way to inform Picasso that it needs to rotate the image. This means that if a non-0 orientation is detected you would have to decode the image, rotate it, and return it from the custom Downloader.

Hopefully we can make this easier in the future, but no one is working on it right now.

Sounds like a big hassle.... I hope this can become a priority in the near future. Thanks for all your work Jake!

Hi Jake,

I came to think about something... No clue if it's easy to implement. But I
know that Picasso has a caching policy for Web images. So I understand that
on first read, you can't parse the Web exif, but on second read from the
cache, should it be possible that you parse the exif (like you would for a
normal image)?

Thanks,
Stéphane

On Tue, Apr 28, 2015, 12:38 PM Jake Wharton [email protected]
wrote:

Unfortunately there's no easy way to accomplish this. We rely on Android
for decoding and it doesn't honor the tag. The only place to actually read
the tag would be in a custom Downloader, but you don't have a way to
inform Picasso that it needs to rotate the image. This means that if a
non-0 orientation is detected you would have to decode the image, rotate
it, and return it from the custom Downloader.

Hopefully we can make this easier in the future, but no one is working on
it right now.

—
Reply to this email directly or view it on GitHub
https://github.com/square/picasso/issues/998#issuecomment-97130192.

We have no idea if images are cached on disk nor access to the disk files.
Even if we did they are in an internal format, not just a raw image.

On Fri, May 15, 2015, 12:58 PM stephanemaarek [email protected]
wrote:

Hi Jake,

I came to think about something... No clue if it's easy to implement. But I
know that Picasso has a caching policy for Web images. So I understand that
on first read, you can't parse the Web exif, but on second read from the
cache, should it be possible that you parse the exif (like you would for a
normal image)?

Thanks,
Stéphane

On Tue, Apr 28, 2015, 12:38 PM Jake Wharton [email protected]
wrote:

Unfortunately there's no easy way to accomplish this. We rely on Android
for decoding and it doesn't honor the tag. The only place to actually
read
the tag would be in a custom Downloader, but you don't have a way to
inform Picasso that it needs to rotate the image. This means that if a
non-0 orientation is detected you would have to decode the image, rotate
it, and return it from the custom Downloader.

Hopefully we can make this easier in the future, but no one is working on
it right now.

—
Reply to this email directly or view it on GitHub
https://github.com/square/picasso/issues/998#issuecomment-97130192.

—
Reply to this email directly or view it on GitHub
https://github.com/square/picasso/issues/998#issuecomment-102458571.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sd6352051 picture sd6352051  Â·  7Comments

ivanmagdic picture ivanmagdic  Â·  3Comments

austynmahoney picture austynmahoney  Â·  5Comments

Meisolsson picture Meisolsson  Â·  3Comments

JakeWharton picture JakeWharton  Â·  3Comments