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.
Related
I need to develop a feature into an iPhone app which will allow the user to zoom in very much on an image and display high-quality details of the image without loading the large and loading it online. I've found a example here: developer.apple.com/library/ios/#samplecode/ScrollViewSuite/ but it dont seems to zoom at full details,
And the images are store locally.
I have seem apple developer example like PhotoScroller, scrollviewsuite.
but feels they work differently just cutting the image in tiles.
Is it Possible To access asynchronously chunk of data and render it to view at same time in didReceivedData function delegate.
Please provide some tutorial or example.
Thanks
Avinash
Based on what you have said, PhotoScroller is really what you are describing. It is the only example that I know that can handle HUGE images and only display what is needed. I have used it for 100 megapixel images and it works great.
I have a large png Image that I need to Zoom&Move.
I therefore created a UIScrollView and embedded a UIImageView.
The App works fine in the simulator, but when running it on the device (8GB iPod Touch) it crashes as soon as the view is loaded.
I tried with a smaller test Image (4MB) works fine and suspect the iPod can't handle a 20MB PNG. I also tried different other formats, such as JPG (in various save patterns), but that did't help either.
Any clues how I can solve this?
Ouch, 20M is a large image. The first thought that comes to mind is can you dice up the image? I.e. instead of one image have a whole bunch of small images which together make up the larger image. Then you can load on demand the same way google maps downloads image squares.
have a look at the ScrollViewSuite Example from apple. Sounds exactly like what you are trying to do.
3_Tiling demonstrates:
How to subclass UIScrollView to add content tiling
Reusing tiles to optimize performance and memory use
Changing the resolution of the content in response to zooming
I suggest the Example Photoscroller. It demonstrates CATiledLayer which you can use to tile your image and even use smaller images as lod images. It's much smaller then the complete ScrollViewSuite example but has everything you need to do what you want. It contains only 2 classes which you should be able to use in your project with minor edits.
You might want to check the WWDC 2010 Session #104 "Desinging Apps with Scroll Views"... they handle and explain that example.
You will need to tile your image. I suggest imagemagick for that :)
I'm seeing my app being killed by iOS with an out of memory message, however, while tracing the progress of the app in the Allocations Instrument, I see lots of mallocs that seem to be occurring outside of the code I've written.
I'm not seeing any leaks being caught, so I assume these allocations are supposed to be there. Thing is, because I'm not sure about why they have been allocated, I'm not sure what I can do to optimize the app and prevent the OS from jettisoning my app.
Does anyone know why the memory is being allocated, or is there any way for me to find out?
Here are a couple of shots from Instruments showing the mallocs. In the second shot, all of the allocations have the same stack trace.
EDIT
I' displaying a single large image as the UIView background (1024x768), then overlaying a smaller (600px square) UIView with some custom drawing and a third UIView (550px square) over the top of those that contains two 550px square images overlayed.
I'm guessing that this is not appropriate, and there is probably a better way of achieving the composition of views I need for the app to work.
Should this be possible on the iPad?
I think there's not really much information to go on here - if you add a bit more information about what this view in your app is doing you might get some more informed suggestions.
From the screenshot, it would appears large blocks are being allocated to display an image.
Given that I'd hazard a guess that either you're trying to display some very large images, or you UIView is large, or you have more UIViews in memory that you need to display the current screen.
I guess the easiest way to track down exactly where they're coming from would be to disable the part of the application you suspect then run again and see if the allocations still occur.
EDIT
Are all the images the same size as you're displaying them? (ie. are you trying to display a 5M photo as the 1024x768 background?) If not you probably need to scale them down to the size you are display them, or at least closer.
If you're not needing transparency, make sure to make all the views opaque.
I figured out the source of the problem - I was using
[UIImage imageNamed:#'Someimage']
to load in my images. This, as I'm sure many people are aware, caches the image data. I had enough images of sufficient size to cause my app to be jettisoned.
The problem was apparent not because of the size of the image but because of both the size and number of images I was using. The lesson here is be careful with [UIImage imageNamed:].
Thanks for all of the help, chaps!
Mallocs can occur inside of other API's that your app calls (such as loading images, views, playing long sounds, etc.) You can try changing the size of your images, views, sounds and other objects by various amounts as a test, and see if the size of the malloc'd memory changes track one of the changes that you've made.
In my application I use lots of images based in interface builder. The problem with this is that it uses large amounts of memory because interface builder caches it much liked "imageNamed" so I've begun removing the image from imageViews in interface builder and instead adding them once the view starts using "imageWithContentsOfFile". After several hours I have made little progress because I have literally hundreds of images. I'm just wondering if there is a more straightforward way to do this?
Yes, don't do it. UIImage and the whole xib business pretty much delay loading until things are needed, as well as drop cached images where possible and needed. You can even see this happening in Instruments. It helps to split your design over several xibs, so they can be loaded when needed.
What you can do however, is to make sure that you don't scale images but display them 1:1, and that you save them in the lowest acceptable quality. For photo's, take JPEG. For other images, take PNG.
I have around 20 tableview cells that each contain a number (2-5) thumbnail sized pictures (they are VERY small Facebook profile pictures, ex. http://profile.ak.fbcdn.net/hprofile-ak-sf2p/hs254.snc3/23133_201668_2989_q.jpg). Each picture is an UIImageView added to the cell's contentview.
Scrolling performance is poor, and measuring the draw time I've found the UIImage rendering is the bottleneck.
I've researched/thought of some solutions but as I am new to iphone development I am not sure which strategy to pursue:
preload all the images and retrieve
them from disk instead of URL when
drawing cells (I'm not sure if cell
drawing will still be slow, so I want
to hold off on the time investment
here)
Have the cells display a placeholder
image from disk, while the picture is
asynchronously loaded (this seems to
be the best solution, but I'm
currently not sure exactly how to do
best do this)
There's the fast drawing
recommendation from Tweetie, but I
don't know that will have much affect
if it turns out my overhead is in network loading
(http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/)
Thoughts/implementation advice? Thanks!
Suggest you do a search in the XCode help docs for LazyTableImages. It's a sample app provided by Apple that asynchronously loads images into a table cell. It should be a good starting point.
You'll probably want to add a local cache to save the images so you don't have to keep downloading them each time, and a way to prune out old images out of the cache.