I am having a problem on how to display user provided images to other users across different devices. For example, I have multiple copies of varying sizes for the same image for my app. These are images I created during development and are part of the app which can support different sized screens. Inside of my app though users can upload a picture of themselves. Obviously now I do not have control of the dimensions of this image. Some users may have new fancy phones which produce very high quality pictures while other users may have not so great phones and produce lower quality images. As well, with user uploaded pictures there is only one image upload. What is the best practice to display these images across various devices. So a user who took a picture on their new iphone 6 will appear nicely on a smaller 3 year old android device as well as a photo taken on a smaller 3 year old android device will appear nicely on an iphone 6?
http://developer.android.com/guide/practices/screens_support.html provides information on how to control images inside of android if I the developer have control of the images, but what if I don't? What if I receive a low quality image from a user, what is the best practice to show it nicely on an ipad for instance?
You can read those guide:
http://developer.android.com/training/displaying-bitmaps/index.html
http://developer.android.com/training/displaying-bitmaps/load-bitmap.html#load-bitmap
When receive your image, you can read its size and decide the scale size it base on user device. (But a small image still looks nasty on a big screen).
Beside, I think you can use other download library like Picasso or Glide to support download and decode image.
Hope this helps.
Related
Working on an Application that displays images in various sizes as grids, lists (Instagram like), images that take up the whole screen.
Ex. - you might have is a grid view image (not very big), but also this same image is shown in another screen that's almost the size of the entire screen. It's like a blown up version of this. There are also the smaller thumbnails of these images.
Working with the Backend team to come up with an optimal solution.
Questions:
What's the most optimal way to handle images for different screen sizes? I know instagram sends the URLs for high resolution low resolution and thumbnails.
Do we need multiple sizes for each image? example. grid view (do we need a 1x, 2x or 3x) for each image?. or can one size serve all phone screen sizes and we can just set the scale mode in code? Would this be ok even for smaller screen sizes? Would this be a poor experience for smaller phone sizes since they need images. To me this wouldn't be optimal since smaller phones like SE don't have the same processing power as iPhone 8 plus.
If we're using the same API to serve iPhone and Android - how can this api be leverage for android given that they have more image sizes to handle.
Any guidance would be greatly appreciate it.
PREMISE:
You are talking about images from web server. Not svgs, not interface
graphics. There's no official documents of this field, just
suppositions and results of experience. I'm sharing mine.
If you meant interface graphics, there are official documentations from Apple and Google. If you meant svgs, they're automatically scaled. If you intended to have answer for those, please edit the topic or open new ones
A solution could be, instead of acting only on images sizes, to change the quality of JPGs.
You can use a full quality ~200x~200 image for little thumbnails (avatars, photo icons), which could be ok for all devices sizes, resolutions and models, without being too heavy.
Then, for bigger previews/full image opened you could maintain the same size (the original one, or a maximum size you define) but, using two version of the image: one with little JPG quality (so that it can be loaded quickly, consume less bytes and show the image content) and the other with the original quality (which requires loading and bytes, but it's only shown by demand).
To choose the right value of the little thumbnail (the ~200px), check the bigger thumb size you have. If you have an avatar bubble which is 96x96 on smallest res, multiply it for 3 (96*3=288) and you have the size!
It is true that the smallest res screen will only require a 96x96 image, but, given that those are little numbers, the difference is not relevant (also, because we are talking about photos and not vectorial images, if you scale manually or if you leave the scaling to the device, the result is the same).
I've found some documentation from Google, which explains some things about image formats and how to reduce download sizes: https://developer.android.com/topic/performance/network-xfer.html
They say to use JPEGs, PNGs, or WebPs and show some examples and guidelines for choosing the right format
You can use svg resources(which is a vector-based-image) : By doing so, you don't need to generate a resource for each resolution, and just need 1 resource. In realtime, the svg image will expand to the resolution of the device.
According to the documentation, you have a lot to gain here :
Using vector drawables instead of bitmaps reduces the size of your APK
because the same file can be resized for different screen densities
without loss of image quality
I have used this in Android, and it solves your issue in Android.
I Haven't used this in iOS but, it looks like there's a similar solution as well.
Your all questions are nearly have same goal. So Basically save 6 versions of images like 50px 100px 200px 400px 800px and 1600px etc.
6 will be enough since you can cover nearly all screen sizes like google does in android. which is ldpi mdpi hdpi xhdpi xxhdpi and xxxhdpi
Use an API for picture requests, send your screen sizes to api as parameter then give back resulting images width and height. for ex: for a 800x600 screen send back 400px version of it.
If you not do so, you will have to resize them on client size which is bad for performance and also bad approach for auto layout in IOS.
You can use third party image managing solutions like Cloudinary.
https://cloudinary.com/
Cloudinary generates images of different aspect ratio which can be serve to all types of devices.
We are trying to build a photo app for a client where large photos are required to be fetched using a web service. These photos will be high resolution JPGs ranging in size (between roughly 5 - 7 mb).
The issue we're facing is how to fetch a batch of photos (say 10-15), store them locally on the app, and allow the user to perform editing tasks on them. What I understood from my team is if we edit the high resolution photos it will crash the app due to memory. This means we will have to reduce the resolution and size of the photo, which is reasonable, but could take a while. What is the best practice to download and reduce the photos so a good user experience is maintained?
To give some background, we are build the app for both Android and IOS. The features expected are typical swipe, pinch, editing with basic editing and advance editing like frames, text overlay, etc.
Not sure this is a UX question so much as about app architecture.
Maybe better suited to StackOverflow or another stack exchange site instead, but I'll try to approach it from a UX angle...
USER EXPECTATIONS
Do your users expect to edit high-res & have control over maintaining maximum quality? Or are they casual users just interested in making funny pix & won't care about loss of quality?
If they expect to have control, you could check disc space or device capability before downloading & offer them a choice of smaller size vs. slower response time.
For example, if they're on an older non-retina/low-pixel-density device, display an alert that editing high-res images might be difficult & offer a smaller version as an alternative.
How will saving/uploading edited versions work? Users might be upset if they overwrite originals w/lower quality versions & weren't given an option to "save as" or set quality level.
USE CASES & DEVICE SPECIFICS
Assumption: A user on a mobile device will only work on 1 image (maybe 2) at a time.
No mobile device is large enough to show multiple high-res images on screen at once anyway. Keep current image in memory; only show thumbnails of others (saved on disc) until requested for editing & then swap; release/reload resources as necessary.
If your users are using older hardware (pre-retina iPhone 3GS or iPad 2 for example), then a 5-7MB image (anything >3000px per side) might be a bit slow, but newer devices take/handle 8-12MP pictures themselves. Should be well within the device's capability to open/edit one at a time.
Are you saying this is not the case?? Can't even open 1 image? Is it being saved to disc first, or opened in-app directly from web service?
Verify adequate storage space either for the whole batch beforehand, or as each image is saved
If device storage is full, cancel remaining downloads & alert user which images are missing
USABILITY & RESPONSIVENESS
Download the images asynchronously to avoid blocking the UI
Create much smaller low-res thumbnails to act as a placeholder for the high-res versions. Download & show thumbnails first to give a sense of progress, but differentiate between an image that's still loading & one that's available for editing (with a progress bar, transparency, etc).
Download in the background (as you might an "in-app purchase") and save to disc.
Download individually & save to shared location. This keeps them organized as a batch of 10-15, but lets the user start working as soon a the 1st image is available. Don't make them wait for all of them.
Could use a separate "downloads" view w/progress bars & let user continue work in another tab/view
Only once the user selects a thumbnail do you need to worry about loading/displaying the large version from disc. You can release thumbnail/loading view from memory & free up resources if necessary while the large image is being edited. Reload only as necessary.
Auto-save to disc in background to prevent loss of work & take opportunity to clean up caches & whatnot.
If working memory is already a concern, you won't have many options for undo/redo. Most image-editing apps manage this ok though, so there's a way.
I saw many questions like these and read many docs, but I'm still not sure what is the proper way. I have application with 500 photos, and first how I was doing it was to scale every photo 5 times, to the pixel sizes for each ldpi, mdpi, hdpi, xhdpi and xxhdpi. But, after doing this, application got much bigger than it should have and since you can only upload .apk with 50MB to market, I found myself in trap.
I found several options which can be made here, but not sure which is the proper one:
Make a multiple layouts for each of this densities on devices and scale with different dp's in them
Make multiple .apk files, each for every device with different densities (still, Google is making accent on this option to make it only if you really can't make it anyhow else - why is that? this would be perfect for me, since I already have photos prepared for each density)
Make multiple pictures and put it just in one .apk - this can't work for me, since the .apk is too big
Make pictures which are good for MDPI device, put them in "drawable" and they will automatically resize bigger for other devices and smaller for smaller density devices - this makes problem since pictures, when they're being resized from MDPI to other bigger dpi devices, pictures are blurry.
So, anyways, proper way of handling this would be to follow first option, am I right? I should just take xxhdpi pictures (so they're always scaled from the best picture), put them into drawable-nodpi? However, I have some problems with scaling on ImageButtons.
Please, tell me how to make it properly.
My practice is using only one apk to keep the app simple and easy to develop and publish.
Use only one drawable, the high the better. it depends the final apk size you(market) can bear.
May be this question will help:
Only use XHDPI drawables in Android app?
An addition to the Loki's answer. You could resolve the poor perfomance on small scale devices making a cache folder for images. Downsize the image the first time the device loads it, according to the density of the device, save it to the cache folder, and the next time use the cached image.
Bonus if you make this in an batch process in the background!
I don't know but could this be done as an update to the app. You download a plain vanilla app that prompts the user to upgrade, or just does it automatically.sounds like something Google needs to improve on. When I download an app I only need one app for one language one device.sounds like Microsoft mentality
I am building a mobile application that will target iPhone/iPad and Android phones. The application will involve users taking photos and uploading to my server and later on the users will be able to look at those photos on their mobile devices (although not necessarily their own photos so an Android user might be looking at a photo taken with an iPhone).
Which sizes should I save the photos to be able to cover the most use cases? iPads are 1.333 W/H, most mobile phones are 1.5 or 1.333 W/H with some rare 1.666 W/H. Specifically:
iPad: 1024x768, iPad3: 2048x1536, iPhone and some other phones: 960x640, 480x320, 800x480.
To be able to keep it manageable, I need to decide on a few certain image sizes and save the photos in those sizes. I am not really looking for help on the technical side. I can do image scaling on the server side etc. I am looking for recommendations / best practices / lessons learned about image sizes before I go too far into building it.
Which sizes should I save the photos in to cover the most use cases?
Do you recommend any client side scaling before uploading to server to save on transfer time (for example scaling down 2048x1536 iPad photos) or should I always transfer originals?
How should I handle incompatible image sizes (showing a picture taken with an iPad on an Android device for example)? Should I pre-cut those images on my server before sending to client or should I let the client phone handle image resizing?
There is also the issue of UI. There will be other things on the page other than the photo maybe a button or two for navigation. Should I go for something smaller than the full screen size while keeping the same aspect ratio when saving pictures?
I know some of these questions don't have one answer and the answers are relative but I wanted to get some opinions. Thanks.
For Android, I think the best place for you to start would be here, it has a lot of information including standard screen sizes and how to display images while keeping them in the best possible quality.
http://developer.android.com/guide/practices/screens_support.html
I'd also suggest doing as much image manipulation as possible on your server. Images are a pain to work with on Android due to memory constraints and fragmentation. Two phones may store pictures taken the same way with different orientations, and there is no simple way to handle rotations, though it can be done (thankfully, I've yet to encounter a phone that incorrectly records Exif data, but I wouldn't be surprised if they existed...). The more you rely on the phone to do, the more chances you have for error due to manufacturers putting wrappers around and otherwise customizing how it handles media.
As for how to display, ideally if your back end is already doing a bunch of different resizes, you can include your screen density when you request the images and send the best size based on the dev guide. If you want to keep differences to a minimum, at least support med or high density for phones, and extra high density for tablets.
Just my two cents, I'm sure you'll have a lot of opinions. Good luck.
I don't have a full answer for you, but I do have some thoughts...
1) I'd suggest reducing the image sizes before uploading. If I were using your application and I had to upload a 4 meg photo, everytime I wanted to use your application, I'd probably pass. And as we venture forward, we're hitting much better technology in terms of camera phones; Nokia has released a 41 megapixel camera, which I'm guessing will create rather large images. Users having to download a 4-6 MB image is also not a great idea. Just some thoughts from a user point of view.
2) I wouldn't cut the images. You don't necessarily know what parts of the image aren't important, so how would you know where to crop it? Let the phone size the pictures accordingly and rely on the ability to zoom into pictures to see things at a larger size.
3) You could try to make a UI that hides buttons. If you have something really simple (like just going forward or backwards) you could rely on gesture controls (swiping) to move around your application. You can implement sliding drawers and menus that take up space temporarily, when in use, but give you the space back when you want to look at the main content (pictures, in your case). I've typically found that hiding buttons doesn't work well and people seem to want/search for buttons that let them navigate, but the Android gallery works just fine with menu + swiping only, so who really knows.
As we know it there are several screen layout out there on various android devices. Now, my question is, what's the best solution for displaying image on screen (full sized image) on that various device?
Should I (this is several strategy I have in mind right now):
resize every images for that target device? (with the cost of resizing it and lost of quality on larger device)
create several images for all or several common screen size? (with larger download size)
create core application and let them download images appropriate to that screen size (that means, I have to prepare hosting of those images)
something I don't know yet...
So, if you guys have experience in this kind of situation, your recommendation is greatly appreciated.
Update: My application will have several (20-30) images.
This is documented ( http://developer.android.com/guide/practices/screens_support.html ) and answered quite a few times already I believe.
Create different images for the different screen resolution (store in drawable, drawable-hdpi... accordingly).
You can also define different layouts for different screen sizes (although to display full screen images, it does not sound like you need that).