Whats the most effective way of dealing with different image resolutions in Parse for the different ios devices?
For instance
Would it be better to have 1 image in parse at the highest res and download for every device? (slower download speeds for lower res devices)
Have 1x 2x and 3x versions of the image in Parse and download for relevant device. (takes up more storage space on Parse)
Run cloud code on Parse to resize the images to their correct resolution as they are downloaded to the devices. (possible slower download speed for all devices?)
Any other options anyone can think of would be welcome.
Al
I would say this strongly depends on the usage case. For example, if you have a profile picture, I would recommend uploading it in 2-3 versions, as those pictures may be downloaded very often (for example in a social networking app where you have profile pictures in posts, user profiles, messages, etc.). When the picture is downloaded a high amount of times, you would rather download a smaller one to minimise download time and save parse data transfer resources.
On the other hand, for pictures that aren't downloaded as often as other ones, I'd recommend storing them in a high-res format, and scaling them down (if necessary) as they are downloaded. Take for example again a social networking app. A post contains a profile picture (which is downloaded quite often) and the actual post (a photo in this case). The actual post photo is only downloaded a single time (ideally), so there should be no reason to worry about the download speed.
Basically (and that's the way I handle this), you should always try to cache every image. Images that can be cached easily and don't have to be retrieved very often can be stored in a single high-res format (saving data space on parse). Images that cannot be cached easily or have to be refreshed quite often, should be stored in different sizes, which will, in the end, save you data transfer. The small amount of extra storage does not have that much impact, to be honest, especially if you store them in scaled down sizes.
Related
I want my app to have a bunch of 30-sec mp4 clips. I want to ship these clips with the App and not have the users download them from the cloud
Each of my clip is around 5 MB and I expect to have a lot of them.
Is there a way to compress them to reduce the app download size? ( the 5Mb size is after all the CODEC's etc) I need an iOS solution for this.
MP4 is very compressed already so there isn't a way to compress it more. That's why zipping mp4s barely changes their size.
You have two options:
1) Include whichever ones the user needs first and download the rest, hopefully before they're needed.
2) If you absolutely have to have them all in the app you could reduce the resolution and/or encode at a lower bitrate.
If you go with option 2, you could still download higher quality ones from the cloud in the background and use those if available, but default to the lower quality ones if not.
I'm building an Asp.Net MVC4 Application with product pages. I have come by the ImageResizer Library for handling and serving the images. My page has jpg thumbnails 160x160px in dimensions and 3~5KB size each.
To my understanding using the ImageResizer library i could just upload the original large product image 600 x 600px & 10~20KB and resize it on the fly to the thumbnail size when the visitor requests the page. Something like:
<img src="#Url.Content("~/images/imagename?width=160&height=160")" alt="">
Which i understand is fine for a couple of images but my product page consists of 20 to 100 product jpg unique thumbnails (depending on pagesize).
Should performance hurt with processing on-the-fly 20-100 pics each time? Has anyone faced a similar scenario? I could always go back back and generate 2 different images (thumbnail and large) during the upload process but i'm very curius if i could get away with just one image per product and dynamic resizing.
When i say performance i mean that anything above 0.5 - 1s extra response time is a no-no for me.
In documentation it is mentioned, that there's caching plugin, which improves performance by 100-10000X:
Every public-facing website needs disk caching for their dynamically resized images (no, ASP.NET's output cache won't work). This module is extremely fast, but decoding the original image requires a large amount of contiguous RAM (usually 50-100MB) to be available. Since it requires contiguous, non-paged, non-fragmented RAM, it can't be used a (D)DOS attack vector, but it does mean that there is a RAM-based limit on how many concurrent image processing requests can be handled. The DiskCache plugin improves the throughput 100-10,000X by delegating the serving of the cached files back to IIS and by utilizing a hash-tree disk structure. It easily scales to 100,000 variants and can be used with as many as a million images. It is part of the Performance edition, which costs $249. The DiskCache plugin requires you to use the URL API (read why).
http://imageresizing.net/plugins/diskcache
http://imageresizing.net/docs/basics
When it comes to websites, every operation that can be cached should be. This allows the server to deal with more visitors rather than more processing.
You could either use the caching plugin for ImageResizer, or manually write to file using a certain filename, e.g.: product_154_180x180.jpg where 154 is product id, and 180 is the width and height, then check for whether it exists when you want to display it.
If you do the latter, you may be able to use the server to manage this for you, by linking to the expected filename in the page source, and if it doesn't exist, the server then calls a script that resizes and writes the resized image to disk using imageresizer.
This last method will also avoid the call to ImageResizer saving you some processing power.
I'm facing the iOS app size issue that the app size over 50 MB cannot be downloaded over 3G/4G connection. My iOS app is heavy because of large amount of images (.png). I have already tried some solutions but it's not enough.
Separate between iPhone and iPad.
Use Compressing PNGs Technique but this just reduce my app size little.
Use zip archiving like SSZipArchive.
I saw an app with download size less than 50 MB but after downloading and installing the usage size is more than 100 MB. How this can be done?
I think they may download some resources later in some way but I do not know how. Any one please give me some suggestions. Thank you.
EDIT:
The texture package sprite-sheet of format such .pvr.ccz also be used. This can be handle the same way as .png.
If your app is heavy on PNGs, you could apply something similar to #2, but with better results. I have used the ImageOptim + ImageAlpha combo with great results.
Here is a interesting case study about this method.
Yes most apps do this. Since you are talking about .png they already go through 2-stage compression. So I dont think further compressing or zip is going to help you.
Lets say you have several heavy images which bloat up your app size. So you remove those heavy images from app packaging and when the user downloads the app for the first time, at that time fetch those images as static files using usual http. You could either do this in a separate setup step (showing progress bar et al.) or you could download these images at runtime based on what the user does in your app.
Once you fetch them you can keep these images locally in your app documents folder or any other folder & serve them up locally from next time onwards (see SDWebCache). or you could keep it simple at make it pure http calls (no locally storing) but this might impact your users experience.
I am working on an IOS app that will display images uploaded by user from my website.
What is the best practices on re-sizing the images on mobile or server?
Option A - Resize thumbnail, desired size and stored it on a cloud server, Amazon S3 for example which host images for iphoneretina_ImgA, Iphone_ImgA, Ipad_ImgA, IphoneThumbnail_ImageA.
Option B - Resize to thumbnail, desired size on the device.
What is the best approach on displaying server image to iphone/ipad devices?
You will get optimal performance on the device if you can do as much image processing on the server-side as possible and deliver optimally sized images to the device (i.e. smallest possible image to support the desired user interface), which will save not only download time (esp if user is on slower cellular networks) but also precious device memory and processing time (if you download high resolution images to device, the amount of CPU cycles and memory required to convert them to appropriate sized images or, worse, not resize them and try to let the poor ol' UIImageView try to render them).
In short, if you can do it server-side, that's ideal. If you do it on the device you'll suffer network bandwidth, memory consumption, and processing time on the device.
If the original images aren't too big, though, you can get away with some reasonable compromises which entail a modest device-side processing. For example, I'm interfacing with a legacy CMS system with modestly sized images and limited existing server-side image processing capabilities, so I just make my thumbnails on the device lazily as they're downloaded/required, but (a) the original images weren't huge; (b) I needed the original resolution images on the device anyway; and (c) I had to do some clever GCD (or you can use some other equivalent concurrent processing technology) to make sure the user interface wasn't too noticeably impacted as the app does one-time thumbnail generation (thumbnails that are then cached locally for optimal performance in the future).
As always in these cases, your final architecture will be a function of the particulars about your images, your server capabilities, the app requirements, but, if there's any rule of thumb, it would be do as much server-side as you can, balancing network bandwidth and server complexity issues with other demands on the device.
I have a question on using the AssetLibrary with iOS. It it possible to store a pointer to an image in your app rather than the actual image? Let's say I want to create a playlist, but I don't want to store the actual image.
The reason I am asking, is that I find when I use the image picker, I can save an image to the devices documents directory, but once I get to 25 or so, it starts to slow down the device (iPad 1). I scale down the images if they are very large, I ran through the leaks instrument many times, and there are no leaks. I am just at a loss as to where to turn next, so I wanted to investigate alternatives. As I see nowhere where I can free up memory.
That's where I am at now, I'm curious if the AssetLibrary might be a option since I won't be storing physical images. I know it has some dis-advantages (requires users location, can be a bit slow when looping through images)
Any thoughts on this would be greatly appreciated.
Storing 25 images to the documents directory shouldn't slow down the device, unless you're trying to load all 25 extremely large images into memory at the same time.
You can't permanently store a pointer to the assets library asset, but you can store the URL you retrieve from the ALAssetRepresentation's url property and then use ALAssetsLibrary's assetForURL:resultBlock:failureBlock: to get back the corresponding ALAsset later. Do note that it is possible for the user to delete the asset from outside your program, even when your app is in the background, so if you are hanging on to an ALAsset you must listen for ALAssetsLibraryChangedNotification to know when to reload the assets.