The images I am getting back from the photo library and camera are HUGE, and it takes a significant amount of time to send them over the network even in good conditions. I can't imagine a scenario in which I would need the full double-digit MB image, but maybe I'm missing something? Is it common practice to resize them before sending them over the network?
Yes it is common practice to alter an image's dimensions and compression so that it is appropriate for application.
As observed, by the default images from the camera are very large so that they can be displayed on large screens, printed to posters, zoomed and cropped etc without appearing unduly pixelated. So unless the app in question is a photo/image manipulating app, then resizing will almost certainly be beneficial in that it can improve networking, the app's memory foot-print and it's overall snappiness.
In terms of how to size and compress, while it is possible to store multiple versions of the image for each device that's being supported.
Practically, it seems that storing a single image at the dimensions required on the lowest resolution device but then only compressing it enough so that the higher resolution devices can scale up as needed without looking ugly seems to deliver reasonable results.
In terms of resizing, there are various posts on SO e.g. How do I resize the UIImage to reduce upload image size
I've also stuck gist for the UIImage extension I'm currently using to do this in my App over on GitHub here.
Have fun.
You can transform the image into data and then use this:
let imageData = image!.jpegData(compressionQuality: 0.5)!
It will make the quality less than usual with 50% to be able to save it quickly and smoothly
Related
Wondering if both a high res and low res image are required for iPhone Apps.
Having a duplicate copy increases file size which is something I need to cut down.
I've built apps in the past and only used high res, without #2x appended to the file name. The apps look great on Low res and High res devices. so...
Let me know
It is not required to have both image types. However, since the resolution is different for the Retina display you might build a Default image that looks nice on the iPhone 4 showing lot of details, but will look different on the other iPhones due to lack of correct resolution. Furthermore the image will be downsampled and if your UI fetish is big enough you rather provide two images than only one very good and take an accaptable sampled image.
I'm not sure if it is the best approach to skip one image just to reduce file size because most of the time the Default images are not the most relevant media part, since icons, sound files etc tend to use more space.
To conclude: I would suggest using both images and try to reduce the App size somewhere else.
I have about 20-ish high quality images (~3840x5800 px) that I need to load in a simple gallery type app. The user clicks a button and the next image is loaded into the UIImageView.
I currently use [UIImage imageWithContentsOfFile:] which takes about 6 seconds to load each image in the simulator :(
if I use [UIImage imageNamed:] it takes even longer to load but caches the images which means its quicker if the user wishes to see the same images again. But it may cause memory problems later with all that caching crashing my app.
I want to know whats the best practice for loading these? I'm experimenting with reducing image file size as much as is possible but I really need them to be high quality image for the purpose of the app (zoomable, etc.).
Thanks for any advice
[EDIT]
Hey again guys,
Thanks for all ye're advice. The project's spec's have changed a little. Now as well as displaying the images they firstly have to be zoomed in to a particular spot and when the user taps next it zooms out and then displays the next image. So I'm not sure if the proposed solutions fits?
Apple's docs recommend against trying to load single images that are larger than 1024x1024. You should look into using CATiledLayer instead, to load pieces of the images as needed.
You can have a look at this Apple sample:
http://developer.apple.com/library/ios/#samplecode/PhotoScroller/Introduction/Intro.html#//apple_ref/doc/uid/DTS40010080
It shows how to load big images, breaking them in tiles for different zoom levels.
You can't see all those pixels at any given time, so there is no need to load them all. Load lower-res copies ("big-thumbnails") to view the complete image, then selected sub-tiles, maybe of 2 or more different resolution sets, after the user zooms in.
The CATiledLayer API may be able to handle some of the latter for you.
I have an app that will display a bunch of images in a slideshow. Those images will be part of the bundle, thus distributed with the app.
All the images are photographs or photographic, etc.
I've read that it's preferred to use PNG as the image format, but seeing that the JPG version will be much smaller, I'd rather be using that.
Are there any guidelines which format to use and in which case?
PNG's are pixel perfect (non-lossy), and require very little extra CPU energy to display. However, large PNGs may take longer to read from storage than more compressed image formats, and thus be slower to display.
JPG's are smaller to store, but lossy (amount depends on compression level), and to display them requires a much more complicated decoding algorithm. But the typical compression and image quality is usually quite sufficient for photos.
Use JPG's for photos and for anything large, and PNG's for anything small and/or designed to be displayed "pixel perfect" (e.g. small icons) or as a part of a composited transparent overlay, etc.
Apple optimizes PNG images that are included in your iPhone app bundle. In fact, the iPhone uses a special encoding in which the color bytes are optimized for the hardware. XCode handles this special encoding for you when you build your project. So, you do see additional benefits to using PNG's on an iPhone other than their size consideration. For this reason it is definitely recommended to use PNG's for any images that appear as part of the interface (in a table view, labels, etc).
As for displaying a full screen image such as a photograph you may still reap benefits with PNG's since they are non-lossy and the visual quality should be better than a JPG not to mention resource usage with decoding the image. You may need to decrease the quality of your JPG's in order to see a real benefit in file size but then you are displaying non-optimal images.
File size is certainly a factor but there are other considerations at play as well when choosing an image format.
There is one important thing to think about with PNGs. If a PNG is included in your Xcode build it will be optimized for iOS. This is called PNG crush. If your PNG is downloaded at run time it will not be crushed. Crushed PNGs run about the same as 100% JPGs. Lower quality JPGs run better than higher quality JPGs. So from a performance standpoint from fastest to slowest it would go low quality JPG, high quality JPG, PNG Crushed, PNG.
If you need to download PNGs you should consider crushing the PNGs on the server before the download.
http://www.cocoanetics.com/2011/10/avoiding-image-decompression-sickness/
The Cocoanetics blog published a nice iOS performance benchmark of JPGs at various quality levels, and PNGs, with and without crushing.
From his conclusion:
If you absolutely need an alpha channel or have to go with PNGs then
it is advisable to install the pngcrush tool on your web server and
have it process all your PNGs. In almost all other cases high quality
JPEGs combine smaller file sizes (i.e. faster transmission) with
faster compression and rendering.
It turns out that PNGs are great for small images that you would use
for UI elements, but they are not reasonable to use for any full
screen applications like catalogues or magazines. There you would want
to choose a compression quality between 60 and 80% depending on your
source material.
In terms of getting it all to display you will want to hang onto
UIImage instances from which you have drawn once because those have a
cached uncompressed version of the file in them. And where you don’t
the visual pause for a large image to appear on screen you will have
to force decompression for a couple of images in advance. But bear in
mind that these will take large amounts of RAM and if you are
overdoing it that might cause your app to be terminated. NSCache is a
great place to place frequently used images because this automatically
takes care of evicting the images when RAM becomes scarce.
It is unfortunate that we don’t have any way to know whether or not an
image still needs decompressing or not. Also an image might have
evicted the uncompressed version without informing us as to this
effect. That might be a good Radar to raise at Apple’s bug reporting
site. But fortunately accessing the image as shown above takes no time
if the image is already decompressed. So you could just do that not
only “just in time” but also “just in case”.
Just thought I'd share a bit of decompression performance data...
I'm doing some prototyping of a 360 degree viewer - a carousel where the user can spin through a series of photos taken from different angles, to give the impression of being able to smoothly rotate an object.
I have loaded the image data into an array of NSData's to take file i/o out of the equation, but create NSImage's on the fly. Testing at near max frame rate (~25 fps) and watching in Instruments I see the app is clearly CPU-bound and there's an approximately 10% increase in CPU load showing ~275 kb png's vs. ~75 kb jpg's.
I can't say for sure but my guess is the CPU limit is just from general program execution and moving all the data around in memory, but that image decompression is done on the GPU. Either way and the JPG vs. PNG performance argument looks to favour JPG, especially when the smaller file sizes (and therefore smaller sizes of objects in memory at least in some parts of the chain) is taken into consideration.
Of course every situation is different, there's no substitute for testing...
I have found massive differences in animation performance when using jpegs vs png. For example placing three screen-sized jpegs side by side in a UIScrollView and scrolling horizontally on an iPhone4 results in lag and a thoroughly unpleasant jerky animation. With non-transparent pngs of the same dimensions the scrolling is smooth. I never use jpegs, even if the image is large.
I think if you want to use transparent, you have no choice except PNG. But, if your background is opaque already, then you may use JPG. That is the only difference I can see
'Use JPEG for photos' as mentioned in Human Interface Guidelines under section Produce artwork in the appropriate format.
I am building an apparel catalog on the iPad. The app will contain over 2000 jpg product images at 2048 x 1536 # 72ppi, plus 2 sizes of thumbnails for each image. The large size of the primary images is to allow for zooming in on the products at reasonable resolution. The larger thumbnails will be displayed on each page to show alternate colors for each product. The smaller thumbnails are used in a side-scrolling pop-up filmstrip-style page browser.
I am dynamically resizing the larger thumbnails from the full-sized images as each page is displayed (in a paging UIScrollView). The smaller thumbnails are pre-rendered in photoShop to maximize the performance of the side-scrolling page browser.
Aside from the space taken up on the device from so many images, what other issues or concerns are there around the large number of images in an app like this? Memory management is under control because I am paging the large images in and out as needed as the user moves between pages in the main UIScrollView.
You are going to want to take a look at the PhotoScroller sample code. Those are mighty large images, and will cause your app to crash with the amount of memory they consume.
To page between pages, that means you'll have 2 images always loaded. If you can tile the images, I strongly suggest you do, that will further reduce your memory footprint.
Keep in mind that just because you can use say, 80 MB of memory for your application, does not mean you SHOULD use that much. Be a nice neighbour, your application will run along side other applications which themselves, use memory. Try and reduce your footprint however possible.
If you are dealing with the large image memory management properly (by tiling) and your customers are aware of the sizes of the app and/or downloads then there really isn't much other concerns.
The iPad has enough processing power to handle this kind of image processing pretty swiftly, but I wouldn't expect this to run great on an older iPhone.
To prevent crashing, I would quadruple check that your memory management works the way you say it does, and that you definitely don't ship with NSZombieEnabled on.
In my opinion, if you're dealing with that much data you should build a hybrid app, and host all the images on a web server somewhere. An image that size can approach 1 MB: 1MB * 2000 images = 2 gigabytes of storage space on the phone consumed.
I have an iPhone app that, among other things, allows users to store photos. When a new photo is added to the app's data store, I cache a thumbnail version of the image so that the photo thumbnail grids load in a reasonable amount of time.
The problem is that these thumbnails look great on a pre-Retina Display screen, but they look a little blurry on RD displays. It's not so bad that the images are unusable, but I would really like to be able to get the full benefit of Retina Display for images users saved with older versions of my app.
The problem is that re-creating all these thumbnails takes way too long. In my tests, it took about a minute and a half to re-encode a sample database to high-res thumbnails (admittedly a large one) on my iPhone 4. It will be even worse on older hardware.
How can I get around this? Doing a one-time migration seems out of the question, given the performance results above. Other options are shrinking the thumbnails lazily (i.e. as they're displayed on-screen) and then saving them to the database at that point. Screens full of old images will be sluggish the first time they're viewed, and then snappier after that.
Are there other approaches to consider? Anyone else faced this problem?
I dont like the idea that you try and convert the images.
User will quickly get impatient and say you app is buggy and takes ages to load.
I think you solve the situation without any re-processing of full sized images.
On older hardware you would not have a retina display (so no need to upsize the images). If they have a retina display then they have a fast iPhone iPod.
I would suggest you graphically solve the problem by how you display the thumbnail images. so instead of fullscreen put a border around this image and show it at its true resolution (dont upscale it). Or show 4 images where you normally show 1 (since iPhone screen is 4x the resolution).
Instead of resampling the original massive image, you could do a bicubic upsample of the thumbnail making it 4x the size. This will make it slightly blurry but it should look better than the iPhone scaling which will look really bad. The upsample would be ultra fast as its working with a small image.
I cannot help you out on upsampling but there will be some code somewhere.
Cheers, John.
Screens full of old images will be sluggish the first time they're viewed, and then snappier after that.
It doesn't have to be sluggish.
It's a bit of a pain, but you can do most of your processing in a background thread. Set the thread priority to something low (like 0.1) to avoid making the UI too slow. The easiest way to do this is to set up an NSOperation for each image you need to convert and add them to a NSOperationQueue with maxConcurrentOperationCount=1.
If writes are not atomic, in -applicationDidEnterBackground: or -applicationWillTerminate: (or in something listening for the corresponding notifications notifications), do something like [queue cancelAllOperations]; for (NSOperation * operation in queue) { [operation setThreadPriority:1]; } [queue waitUntilAllOperationsAreFinished];; you get about 10 seconds or so which should be enough for the image conversion to finish writing to disk (and thus avoid half-written files). For added protection, check [operation isCancelled] immediately before the write if it might take longer than 10 seconds. Obviously, in -applicationWillEnterForeground:, you should restart the conversion (remembering that some of the images have already been converted).
Concurrency issues are fun to track down...
(Note that [data writeToFile:path atomically:YES] isn't sufficient — it's likely to leave temporary files lying around if the app is killed during the write. I'd recommend storing thumbnails in Core Data if you can, but that might be out of the question for existing apps.)