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.
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
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.
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.
Server Config:
Windows Server 2003
IIS 6
ColdFusion 8 Standard Edition
Java Version 6 Update 18
I have a ColdFusion application that allows users to upload images that will be added to an existing PDF. When the images are added to the PDF, they have to fit within a minimum/maximum height and width, so the uploaded image needs to be scaled to fit.
For instance, let's say the minimum height and width for a given image is 100x100, and the maximum height and width is 200x200, and the user uploads an image that is 500x1000. I use the logic below to scale that image down without skewing the image (it keeps its original shape) to 100x200. For an image smaller than the minimum, it is scaled up (in the example above, a 50x50 image would be scaled up to 100x100).
Unfortunately, I'm running into a lot of problems with users uploading "invalid images". I know that ColdFusion has problems working with Progressive JPEGs and CMYK JPEGs, but even some TIFFs are throwing errors. Also, a 3MB TIFF image takes over a minute to scale (not to mention the loss of resolution that occurs, which I have submitted as a separate question here.)
I've added logic to prevent ColdFusion from trying to process an "invalid image" by using the IsImageFile() function, but the users are very frustrated when they have an image that they can open and view on their PC, but we can't accept it. Do online print companies (i.e. Shutterfly, Kodak, etc.) have these issues? I can't remember ever having an issue on these websites (though I know they may not necessarily use ColdFusion).
Any thoughts on what I can do to allow more types of images to be used (Progressive, CMYK, etc.) and improve performance?
You will likely have to use a non-CF solution like we had to do before CF8. Some libraries mentioned here: https://stackoverflow.com/questions/158756/what-is-the-best-image-manipulation-library
Scaling time is heavily dependent on the algorithm you chose to use. Adding images to PDFs in ColdFusion is unpredictable at best. I found them to be often inflated, dramatically increasing the PDF file size.
Here is some information from the docs:
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=functions_in-k_16.html
Supported image file formats
The cfimage tag operates on a number of different file formats. To list the formats that are supported on the server where the ColdFusion application is deployed, use the GetReadableImageFormats function and the GetWriteableImageFormats function.
ColdFusion supports the following default image formats on Macintosh, Windows, and Unix operating systems:
JPEG
GIF
TIFF
PNG
BMP
ColdFusion does not support the following image formats:
Animated GIF
Multipage TIFF
PSD
AI
CMYK support
The cfimage tag supports reading and writing CMYK images, but does not support actions that require converting the images. For example, you can use CMYK images with the read, write, writeToBrowser, resize, rotate, and info actions. You cannot use CMYK images with the convert, captcha, and border actions. The same rule applies to image functions. For example, the ImageNew, ImageRead, and ImageWrite functions support CMYK images, but the ImageAddBorder function does not.
I generally use Fireworks PNGs (with different layers, some hidden, etc.) in my iOS projects (loaded into NIBs in UIImageView instances). Often, I take the PNG and resave it as PNG-32 to make the file smaller, but I'm questioning this now (because then I have to store the Fireworks PNG separately)....
In my cursory tests, a smaller file size does NOT affect the resultant memory use. Is there a relationship, or is it the final rendered bitmap that matters?
Note: I'm not asking about using an image that is too big in pixels. A valid comparison would be a high-quality jpeg that weights 1mb vs. a low-quality jpeg of the same content that weights 100K. Is the memory use the same?
UIImageView does not do any processing so if you set a large image the whole thing is loaded into memory when the imageView needs it regardless of the size of the imageView. So, yes, it does make a difference. You should store the smallest images that work within the imageView.
While your current example is using NIB's, if you were creating an app that displays large images acquired from other sources (e.g. the device camera or an external service) then you would scale those to a display size before using them in a UIImageView.