Avoid Use of Multiple Copies/Resolutions of Same Image

[Brahmanathaswami]

I'm just getting started with mobile. Also for the past 20 years (yeah... really) I have always interacted with other users (hypercard, super card metacard, runrev, livcode) via the mailing lists... I see a lot of activity over here on the forums, so I'm giving them a shot.

I have spec for an app that will require a lot of images. For now I'm content not to worry too much about iPad or larger tablets... I thinking just to targer iOS and Android, but even these phones have pretty big screens. If I read the docs on this issue, the whole bit about making 5 versions of the same image with different image names that LC will automatically call, make sense from one point of view. With Photoshop/Bridge action scripts it would be easy to generate all these automatically. My problem is: if the app wants to include e.g 500 photos... then if you have 5 different resolutions of each one... the total '"weight" of the app start so bloat drastically. So, now, with the full screen scaling option, I'm thinking that we can just pick one optimum image size for all... and if it is a big android rect or iPhone 6Plus... then let LC scale it up or if smaller then, down.

I'm sure someone has already been through this loop dozens of times and I'm looking for "best practice" for going in with a single image for all contexts/rects.... of course "best practice" probably is :supply all five resolutions for each image... but that just seems like too much data...

What are you doing?

[jacque]

I think I would just create a single image at the highest resolution you think you'll need. Then scale it down (and lock it) to fit your stack, which should be for one of the smaller screen resolutions. Then using the fullscreenMode property, LC can scale it upward for larger screens.

[Brahmanathaswami]

what would that "biggest' we need be? I guess this is really about my education here... I'm really confused with the retina display info... PPI, pixels etc. iPHone six plus seems to be a middle ground between iOS and the super big Android phones... Retina HD display, my problem is I have been living in a web world for so long the working principle is "small as possible at the most tolerable quality level your users (or superiors) will accept. Because this is going to affect the download speed of you web page (etc). 16:9 seems to be the target now to accomodate video on landscape mode. iPHone six Plus

5.5-inch (diagonal) LED-backlit widescreen Multi‑Touch display with IPS .1920-by-1080-pixel resolution at 401 ppi
1300:1 contrast ratio (typical)Retina HD display

This is "scary" to me... if I crop a hi-res image from my print world (300 ppi) and then change it to 401 PPI I get a 7.2 MB photo shop file... Save for web I think photoshop is switching to 72dpi.. but I still get a 600K file for a single image. Did I get that right? we would never do this in a web site development space...

*300 /100 this is 180MB just for my images alone that I would like to ship with the app..."yikes" Then if you did use multiple versions of those for different resolutions the total weight of the images become astronomically off the charts.

Either I have this very wrong or no one ships a lot of full screen images with their apps and then just downloads them via the web as needed over time. (or swops them out) but I'm wanting most of modules to function off line, and my spec uses a lot of "random pick" routines, to keep the user's interest and the "fascination" factor very high (every thing they touch has a cool image they haven't see ever, or only rarely.) Apps like Flipbook seem to use lots and lots of images... I need to go off line and see if I still get lots and lots...

So I feel like I'm missing a piece(s) of this puzzle here. OR I have to rethink my strategy about shipping a lot of images with the app package

[jacque]

It's complicated. The goal is the smallest app possible while still accomodating all screen resolutions, which isn't easy to do. There are two ways to handle image scaling -- include all sizes and let the engine choose the best one, or include a single largish-sized image and let the engine scale that. In your case I'd do the second one. But you still need to make some compromises. For example, not all screens have the same width/height ratios. There are different ways to accomodate that; one way is to keep the proportional scaling and allow the card to show around the edges, which forms a kind of visual border. Another way is to allow the image to scale to fill the screen at its smaller dimension but have some of the edges cropped off if the larger dimension is too big. This is what the different fullscreenMode settings control.

The largest size you'd need will probably vary between iOS and Android devices. Android is all over the map. I think I'd start with just the larger iOS size and see how it looks on Android. Or you could compromise with a medium-resolution image and see how it looks when scaled up. Depending on the image, sometimes that isn't so bad. I'll assume you aren't going to release through either of the Apple or Android stores; if you do, you will have more restrictions.

180 megs isn't too huge for mobile games, but it's on the high side for most of my Android apps. Most phones have limited storage space, and if the user has already installed a lot of other apps, yours won't install if there isn't room for it. News readers like Flipbook download images on demand and dump them from the cache when more space is needed. If you are offline, then typically news readers will not update at all. This works for news apps because people expect to get the latest information from the web. Apps like yours aren't expected to require internet access.

So you will have to compromise. One way would be to include a minimal set of permanent images (highly compressed jpgs if possible) and then test for an internet connection when the app runs. If there is one, pull images from a server on demand. If the user is offline, pull images from the reduced stored set. If you pull from a server, then image size versus quality is something you'll need to deal with because the same problems you're used to will occur -- long download times impair the user experience.

As a general guideline about app sizes, Apple's App Store used to forbid apps that were larger than 500 MB, but has now doubled that amount since the iPhone 6 introduced new size requirements. The Android Play Store, I believe, is still at a 500 MB limit. On my Android device, it looks like most of my apps run between 2 and 30 MB except for some games, which I usually delete after completing them to free up space. The last one I downoaded was about 450 MB and took about 10 minutes from intial download to final installation. Usually apps download and install in under a minute.

Every app is different, so the method you choose will depend on individual factors and how much compromise you're willing to do.

[Brahmanathaswami]

Thanks Jacques... everything you said pretty much confirms my thinking on this already. That in itself is helpful.

Yes: compromise: subset of permanent images ship with the app. fetch others on demand... looks like the way to go.

Obviously testing is key to making decisions. A lot of the art work we would use would be very forgiving for medium compression scaled up... but photos of course can't take this at all. (120% is considered max in the placed image for print world)

I'll end with two questions from something you said that I do not understand:

Jacques: "Or you could compromise with a medium-resolution image and see how it looks when scaled up. Depending on the image, sometimes that isn't so bad. I'll assume you aren't going to release through either of the Apple or Android stores; if you do, you will have more restrictions."

a) I did not think it was even possible to *not* release via the Apple Store or Google Play. I thought iOS users cannot install an app that is not from the store. Am I wrong?

b) What restrictions do they (Apple/Android stores) have related to image resolution(s) in the app?

[jacque]

You can release an Android app from anywhere, which is the primary way malware gets out on that OS. As long as the user allows downloads from third party sources (a system setting) they can get an app from anybody. You're right about the Apple App Store, you'll need to release for iOS from there. (I've just been working with the Mac App Store where that isn't a requirement, and had an unfortunate thinko about that. So yes, iOS requires the App Store.)

The primary restriction for iOS in this case would be the size of the app. I don't think there are too many actual image/resolution requirements outside of the app icons, but I'm not completely up to date on that. There are lots of other (picky) reasons Apple will reject your app though. If they think your interface doesn't conform well enough, or it takes too long to load, or it breaks any of their other rules, it will be rejected.

The Android Play Store is far more lenient. As long as your app doesn't do anything bad, it's okay. The way you manage the assets is up to you. If it doesn't conform to the current UI specs the Play Store won't care, though the reviews may show lower ratings if users complain.