As title states and as searching on google can give, on iOS there is a limit for what the devices can handle for jpeg images.
As per Apple docs (Know iOS Resource Limits):
Because of the memory available on iOS, there are limits on the number
of resources it can process:
The maximum size for decoded GIF, PNG, and TIFF images is 3 megapixels
for devices with less than 256 MB RAM and 5 megapixels for devices
with greater or equal than 256 MB RAM. That is, ensure that width *
height ≤ 3 * 1024 * 1024 for devices with less than 256 MB RAM. Note
that the decoded size is far larger than the encoded size of an image.
The maximum decoded image size for JPEG is 32MP 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.
I added the enfasis on the point that's bugging me mostly. I'm trying to display a fairly big image, but still largely in the above 32MP mentioned limit, specifically its a 3995px * 2138px for a total of 8.5MP and 396kb weight (jpeg quality/compression set to 25 via PS).
Still whenever I call for that image as ex. source of an <img> tag, nothing is displayed on any iOS device I've been able to test, on emulators and couple real devices (iphone4, ipad2, 3, mini...).
Is there anything I'am missing blatantly or maybe I've not understand from the docs above?
What can I do apart replace it with a reduced file size? If forced to replace it, what is the highest width I can reach without breaking? How can I ensure iOS honor the 32MP limit mentioned?
I'm speaking in a website perspective, not a native app on the device.
It doesn't fix your current problem but if you look at image handling in IOS8 there are no longer any image size limits (CoreImage can automatically tile) - perhaps you could target that?
You can split up images and tile them.I routinely display images 180,000 x 120,000 pixels on IOS devices by chopping them up and using a CATiledLayer.
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 twaindotnet to scan an image with 2400 DPI. Whenever I scan a full page in color I get a message that there is not enough memory to perform this action. I tried it on a different computer with around 4 GB of ram and got the same error message.
If I scan the image as black and white or gray-scale I don't get any error and everything is working fine.
Is that a problem that is related to the scanner driver (Canon 9000F) or is this a general TWAIN problem?
gray-scale images have a bit depth varying from 2 to 8. for an image of legal size and of 2400 dpi, the size can be 163 MB ~ 654 MB.
color images have higher bit depth. take 32 for example, the image of the same size and dpi can be around 2.62 GB. plus the memory occupied by other applications, 4 GB memory likely runs out.
File Size = (height x width x bit depth x dpi2) / 8
dpi2 means dpi square
Looks like that Twain library is scanning to memory, the Twain specification also has a file transfer mode which is generally used for very large images (ICAP_XFERMECH). Twaindotnet may allow you to choose the file transfer mode when scanning.
A GIF image, stored locally on the server (86.8KB, 1430x2246), is not displaying on a mobile website on my iPhone 3G device, running iOS 4.2.1. The site is built with jQuery Mobile and HTML5.
Here are devices and platforms I tested and the result of loading the image:
All major desktop browsers (i.e. Win/IE, Mac/Win Safari, Mac/Win Chrome, Win/Opera, Mac/Win FireFox). PASSED
iPhone 3G, running iOS 4.2.1, Mobile Safari. FAILED
Opera Mini, on said iPhone 3G device. PASSED
A colleague's iPhone 4S, running Mobile Safari. PASSED
iOS Simulator, with Hardware->Version 5.0, Mobile Safari. PASSED
iOS Simulator, with Hardware->Version 4.3.2, Mobile Safari. FAILED
Android device, Version 2.3.3. PASSED
Android SDK Emulator, Versions 1.5, 2.2, 2.3.3. PASSED
I decided to focus my attention on the iOS Simulator, Ver 4.3.2, since the image didn't even load up on a powerful desktop computer.
I thought it may be a memory issue with iOS 4.3.2 and Mobile Safari, perhaps related to the resource limits for images (iOS Development Guidelines). I understand there is a workaround for image limits (i.e. 6.5MB) but that didn't work for me, either (documented later).
The next thing I looked at was the size and dimension of the image. I downloaded a few free images (saved as GIFs) from the Internet and stored them locally on the server, all but one similar or larger in size and dimension than the image in question and they all loaded successfully in iOS Simulator, Ver 4.3.2.
FYI, the image sizes and dimensions were:
238KB, 2428x1531
414KB, 2993x2050
238KB, 2000x1490
196KB, 2192x2541
196KB, 850x638
Going back to the image workaround, if I understand it right, the main idea is wrap the img in a canvas tag (I correctly called the drawImage function in JavaScript), which I did. Unfortunately, the GIF still did not load. I tried loading the image as a background-image in a div tag, as well, and, again, this did not work.
I can't think of anything else to try. Is it possible the GIF is corrupt? I honestly have no idea what else can I do.
Let me add in all the above methods I tried that failed, the other images I had downloaded all worked correctly (again, within the context of iOS Simulator, Version 4.3.2). And I even looked at the simple mistakes like spelling errors and the source and filename of the GIF in question is spelled correctly. I even tried changing the image extension from GIF to JPG and then PNG and the image still did not load.
I would appreciate any help. Thank you.
Update
I tried checking the validity of the image using the link here, How do I programmatically check whether an image (PNG, JPEG, or GIF) is corrupted?, and the image was not corrupt. If I find a solution, I'll be sure to document it.
Thank you.
Update2
I got a copy of iranView and saved the GIF as a JPG (not just renamed it, which is what I did last time) and the image loaded in iOS Simulator, version 4.3.2, Mobile Safari. Using this same method, I tried saving the GIF as a PNG, because JPG is too large, but it did not load. Then, I tried saving the GIF as a JPG, and I saved the JPG as a GIF, but it did not load, either. Only JPG worked.
Update3
It turns out that those images I tested are really JPEGs; so, I had to retest. I downloaded the images from Google images, ensuring they are GIFs and larger than 2 MP. Here is what I found:
Re-reading the Known iOS Resource Limits section from the Apple Developer site, it says:
The maximum size for decoded GIF, PNG, and TIFF images is 3 megapixels
for devices with less than 256 MB RAM and 5 megapixels for devices
with greater or equal than 256 MB RAM. That is, ensure that width *
height ≤ 3 * 1024 * 1024 for devices with less than 256 MB RAM. 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.
The maximum size for a canvas element is 3 megapixels for devices with
less than 256 MB RAM and 5 megapixels for devices with greater or
equal than 256 MB RAM. The height and width of a canvas object is 150
x 300 pixels if not specified.
If all the above is ironclad, then why does images "earth_lights.gif" and "logoJDC_orange_GIF.gif" display on the iPhone 3G (4.2.1), yet does not display on iOS Simulator (4.3.2)? I tested all images with IrfanView to ensure their formats are correct - GIFs are truly GIFs and JPGs are truly JPGs. Based on all this testing, I'm leaning towards deducing Mobile Safari's decoding of GIFs, at least on dated iOS firmware, is inconsistent, as opposed to concluding the GIF image I was originally trying to display is corrupt.
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.