I have a set of ~400 PNG images that I am current using UIImageView to animate. This is in Objective C for iOS 7.
I was wondering if there is a more efficient way to display this animation?
For information, the animation will be on one part of the screen in the background, while other actions are taking place.
400 images is a lot of images. If these images are large, you are going to eat up a lot of memory in displaying them, and may crash. (Images in memory take 3 bytes per pixel, or 4 bytes if the image has an alpha channel as most PNG images do.) For a a 400 x 400 point retina image (800x800 pixels) that's 800x800x4, or 2,560,000 bytes per image. With 400 image, that's 1,024,000,000 bytes, or about 976 MB. Way, way more than you should take for a single animation in your app.
You might want to convert the image sequence into a video and display the video in your app. Video uses hardware-accellerated streaming that only loads a frame at a time into memory.
Related
The login view in our app uses large background images. To try and save on memory/app size I resized and compressed these images, which reduced their filesize significantly (less than 1mb, down from several mb).
When monitoring my apps memory usage (XCode debugger) there is a clear spike when a modified image is displayed (around 30-40mb). I'd accepted this as normal and simply made sure to release the image asap to limit memory usage.
I've recently started replacing a couple of the images and wanted to preview the new ones before resizing/compressing them. I noticed that these images (one of which is 11mb on disk and 4640x3472 pixels) has no visible effect on app memory usage whatsoever, increasing 'Other Processes' instead (by around 20-30mb).
Can anyone explain what's happening here? I want to confirm it is advisable to continue resizing/compressing the images.
Note that I'm loading the images using UIImage(contentsOfFile:) and I resized/compressed the images using GIMP. The new images have been taken straight from Flickr and unmodified.
Cheers.
The in-memory size of the image (as a UIImage) is different to the compressed on-disk size (your JPEG)
The UIImage takes 4 bytes (RGBA) per pixel x height x with - so for a 4640 x 3472 image, you're looking at 64,440,320 bytes - quite different to the 11MB on disk
I'm using Unity3d (4.3.1) and NGUI for creating an 2d iOS (iPad) app. Also I need to use a lot of full screen images (about 100 images with size 2048x1536), for Gallery for example.
Now I'm using them with GUI type, override for iPhone with max size 2048 and compression quality: normal. And I'm using a UITexture with Unlit/Transparent shader to show them.
However, after about 40 images in the project XCode returns the terminated due to memory error. So the question is, what type of images do I need, and with which preferences to make them work?
I'm using iPad 3 as a test device with XCode 5.1.1. I'll be thankful for any help!
Also I need to use a lot of full screen images (about 100 images with size 2048x1536), for Gallery for example.
I think your 2048x2048 size images use a very huge memory area. Basically, 2048 image use 16MB memory. So, this case need to use about a 1600MB memory! Normal application don't over about 200 MB.
So, I think you need to be reduce using a memory:
Remember that this texture is going to be expand 2048x2048 by unity.( http://www.opengl.org/wiki/NPOT_Texture ) So, if you are going to reduce file size to 1500x1000, your application still use 2048x2048 image. But if you can reduce file size to 1024x1024, do it. 1024 image just use 4 MB memory.
If you can use texture compression. Use it. PVRTC 4 bit ( https://docs.unity3d.com/Documentation/Manual/ReducingFilesize.html ) compression is make file size 1/8 than true color. Also memory size is going to reduce.(maybe reduced to half)
If your application don't display all images, load image dynamically. Use thumb nail.
Good luck:D
If you want to make a gallery-like app to render photos maybe you can try a different approach:
create two large editable textures and fill texels with image data (it must be editable otherwise you will no have access to write directly image data into them).
if you still have memory issues or if you want to use lower memory you can use several smaller textures as tiles. You can render then image parts to each smaller texture. Remember to configurate correctly the texture borders or so not use border texels to avoid wrapping problems.
Best way is to use a smaller texture. In an ipad you will need a magnifying glass to really appreciate the difference between 1024x1024 and larger textures. Remember an ipad screen is smaller (7"~10") than a computer one and with filtering enabled is really hard to tell the difference.
If you still need manager such a large texture for some other reason (zooming or similar) I recommend you one of the following approaches:
split the texture into layers with alpha channel (transparency): usually backgrounds can be rendered with lower resolutions.
split also the texture into blocks: usually most textures have repeating patterns.
use compression.
Always avoid use such large textures if possible.
I have an app that has 12 images contained in an array. All these images are displayed at the same time on the screen. (1 view - 12 much wider and higher images (UIImageView's) one on another. When user does something, app moves the images, thus the view displays different scenes)
The images themselves are not too heavy (it is about 2500x5000 in size, but the whole folder with images is around 3.5 MB).
After loading, the app consumes 355 MB.
When I put breakpoint in viewDidLoad (and all images are loaded at that time), xcode shows that the app consumes only 9 MB, but in viewDidAppear it is 355 MB.
What is the reason of it? And how can I store images compactly? (As I assume that the problem is in the images).
Thank you for any help!
An image open will occupy something like : H x W x number of channel x number of bit for channel, the file size is another thing, because images are compressed according to their type. Your images are 50Mb each one in memory.
The only way is to resize the image before displaing them. There are plenty of image resizing categories online, just google a little bit.
The other suggestion is to not load all the images togheter, just bring in the array the file path, and instantiate the image lazily.
If you need to use hires images you should look for CATiledLayer and tiling techniques.
These images probably cannot be displayed all at the same time onscreen, so you may want to load them only when necessary.
If you still need to display them all together onscreen, think about reducing their size.
Still, 355Mb is huge. Are you doing anything else in that application, that might use up all of that memory?
In Xcode go to Product->Profile. You will find there a lot of useful instruments which will help you to find problems with memory, CPU or battery usage. However, check it if you haven't seen it before.
I'm working on an iOS app using PhoneGap. I ran into an annoying problem where some of my images weren't loading. Thinking it was a cache issue I played around swapping images.
I finally discovered that the issue had to do with the height of my image. After a whole bunch of trial and error I discovered that an image taller than 7864px will not load in the iPad simulator or the iPad itself. It will load fine in Safari. It's not a file size limitation as these are only 45k in size and I'm loading images that are 700k in size elsewhere without a problem.
Has anyone run into this? I can't find any documented restrictions on image dimensions within mobile Safari. If there are restrictions, knowing them would be handy.
For native apps, Apple says images larger than 2048x2048 1024x1024 are to be avoided and should be broken down into smaller ones. The problem here is not the file size on disk, but the size in memory: the image has to be decoded and turned into a "flat" representation.
So let's do some math: assume an image 5000x5000 pixels, with 8-bit RGB. This means each pixel occupies 3 bytes:
5,000 * 5,000 * 3 = 75,000,000 (roughly 71.5 MiB)
So you see your seemingly small image really fills up the memory very fast. iOS now cannot throw parts away if it's under memory pressure, it's the whole image or nothing.
Your only solution is break down the image into smaller parts. iOS can then remove images that aren't visible any more from memory (I doubt with such a huge image that all parts are visible all the time).
I want to display a page containing about 6000 tiny image thumbnails (40x40 each). To avoid having to make 6000 HTTP requests, I am exploring CSS sprites, i.e. concatenating all these thumbnails into one long strip and using CSS to crop the required images out. Unfortunately, I have discovered that JPEG files cannot be larger than 65500 pixels in any one dimension. Wary of further limits in the web stack, I am wondering: are any of the following unable to cope with an image with dimensions of 40x240000?
Internet Explorer
Opera
WebKit
Any CSS spec
Any HTML spec
The PNG spec
Edit: the purpose of this is simply to display an entire image collection at once, requiring that the user at most has to scroll. I want the "micro-thumbnails" to flow into an existing CSS layout, so I can't just use a big rectangular image. I don't want the user to have to click through multiple pages to see everything. The total number of pixels is not that great - only twice what would fit on a 2560x1600 display. The total file size of all the micro-thumbnails is only a couple of megabytes. Assuming every image is manipulated uncompressed in the browser's memory, taking 8 bytes of storage per pixel (RGBA plus 100% overhead fudge factor), we are talking RAM usage in the low hundreds of megabytes; not unreasonable for a specialized application in the year 2010. The only unreasonable thing is the volume of HTTP requests that would be generated if all micro-thumbnails were sent individually.
Well, Safari/iOS lists these limits:
The maximum size for decoded GIF, PNG, and TIFF images is 3 megapixels.
That is, ensure that width * height ≤ 3 * 1024 * 1024. Note that the decoded size is far larger than the encoded size of an image.
The maximum decoded image size for JPEG is 32 megapixels using subsampling.
JPEG images can be up to 32 megapixels due to subsampling, which allows JPEG images to decode to a size that has one sixteenth the number of pixels. JPEG images larger than 2 megapixels are subsampled—that is, decoded to a reduced size. JPEG subsampling allows the user to view images from the latest digital cameras.
Individual resource files must be less than 10 MB.
This limit applies to HTML, CSS, JavaScript, or nonstreamed media.
http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/CreatingContentforSafarioniPhone/CreatingContentforSafarioniPhone.html
Based on your update, I'd still really recommend not using this approach. Don't you think there's a reason that Google's image search doesn't work like this?
As such, I'd recommend simply loading images as required via Ajax. (i.e.: When the user scrolls below the currently visible set of images.) Whilst this will use more connections, it'll mean that you can have sensibly sized thumbnails and as a general approach is much more manageable than having to re-generate pre-generated thumbnail image "sheets" on the back-end when a new image is added, etc.