I am working on a mobile web accelerator proxy server that aims to reduce bandwidth usage for mobile clients.
Currently I am looking at image files. The most fail safe way of reducing file size is to use higher compression/lower quality, while maintaining resolution.
However, I think halving the horizontal and vertical resolution of gifs, pngs and jpegs would greatly reduce the bandwidth requirement.
For each of these formats, is it possible to "trick" the browser to render a 500 pixel wide image as if it is having 1000 pixels width?
Remember; I don't control the HTML, JavaScript and CSS.
JPEG has progressive encoding. Could I utilize that? PNG and and GIFs may have a DPI-metadata?
Related
So, how do they look? Tiny? Does chrome/the OS scale them up? I'd like to publish an app but I don't have a high dpi screen to test this things out and I'm really curious about it.
If they in fact look tiny, would a device-pixel-ratio media query that sets the html font-size fix it? All my units are set in rems, no images and only a few text.
Chrome apps generally look great on high-DPI screens -- just as Chrome itself does.
Even if your CSS specifies all dimensions in px, those are CSS pixels, and adapt to the display based on the device-pixel-ratio.
With rems, and no images, your app should look much better on a high-DPI display than on a standard one.
Low-DPI Images on a high-DPI screen can look pixellated -- not because they are tiny, but because they have been scaled up, and they are being presented beside crisply rendered text. For those cases, there are techniques that you can use to present high-resolution images to those displays, and standard images to others.
The other issue to be aware of is drawing with a <canvas> -- if you want a sharp image, you have to remember to scale the canvas area by device-pixel-ratio, and scale up all of your coordinates the same way as you draw.
I have 2 iOS apps that have been in the market, 3 years on iPhone, 2 years on iPad HD version. The apps are a popular reference tool in the medical field. They are both comprised of 1100+ images. The current app size is roughly 52mb.
Approximately 400 images will be redone. They are currently jpg and low resolution. The replacements will be png, with higher resolution.
I'm uncertain on pixel size for these images. If they are in the 280x280 range, each file is about 100k, if in the 560x560 range, each file is almost 400k.
So I'd be looking at additional 40mb for the smaller images and 160mb for the larger.
There are plans for another 400+ images in the near future. So, I'm somewhat concerned with final app size.
If I went with the larger size for Retina devices, can I downsize for non-Retina devices?
If I supplied both sizes, image.png and image#2x.png, that would be 200mb just for these images.
I'm a little uncertain on how to manage these with regards to their individual size and, more importantly, their total size.
Any comments or suggestions are welcomed and would be helpful.
TIA,
jb
Here are a few options you have:
1. Downsizing Retina Images
I would not recommended downsizing retina images for the non-retina devices. This produces non-optimal performance and makes the images look bad. Your still loading in all the pixels of a retina image, but only displaying 1/4 of them.
2. Bundling All of the Images
Honestly for a medical reference app, I think it would be understandable if your app size would be quite large. I wouldn't imagine people would need to download this app over 3G or LTE. Your users understand this is a large database app which provides high resolution images, thus they should be okay with the large app size via this method.
3. Hosting the Images on a Web Service
Another alternative would be to host the images on a server, allowing them to be downloaded individually as needed, or in bundles. I think your users would prefer being able to fully use the app without internet connection rather than having a smaller app size.
4. Alternative Image Loading
This approach takes a bit of work and could be a little risky. You could bundle only 2x versions of your images into the app. Then on App launch you could force the user to wait until you resize all the images to their 1x counterparts and save them off to the disk. Then you could create an image loading convenience method which loads a UIImage from either disk or the app bundle based on whether or not it needs a retina image.
I definitely recommend option 2 for your purposes. I only mentioned the others to be thorough.
I've made an "magic" app with a lot of coins/playing-cards.
Therefore I have a lot of images of coins, dollar bills, playing cards etc. (regular + retina resolution)
This results in a relative big file size of the final app, which I would like to avoid; since it can't be downloaded without a wifi-connection.
Currently it's 48.6 mb when downloading it from the App Store.
The images (100+) is all .png's saved in two versions, for the regular and retina displays.
Is there anyway to optimize this and reducing the final file size of my app?
I've considdered only storing the big (#2x) .png's and the scaling them accordingly.
I have had a lot of success using ImageOptim to compress the size of images in my application.
Also, if your images are png-24, you can reduce them png-8 and save a lot of space as well. png-8 doesn't support transparency though.
Why save 2 sizes? Do you have to display so many at a time that loading the retina version takes up too much memory on a 3G? Personally I don't think you should still think of supporting such an old device. Apple also dropped support for it a while ago and it really is lacking the memory for some decent applications.
Also, have you tried using some tools to compress your images without the users noticing it? like photoshop "save for web & devices", or yahoo's services etc.
why do you need to store TWO versions of images? Just use hires imges in regular displays. Or, if you whant so, you can distribute 2 apps...
Are you shure, that your images has necessary sizes? i mean retina display has 680x920 pixels. if you are don't zooming images, you don'n need to make them bigger. And in this case, mb *.app file, in archive... there must be 1000 images...
Is there a way to not add 1x images to an iPhone/iPad app?
I'm developing an iPhone app and also testing on my iPad.
When I just use #2x images, the iPad successfully resizes down to the 1x size.
Is there any downside to not to add 1x images? Or are they still important?
By forcing the device to downsample, you're sacrificing performance and memory for a negligible amount of disk space. It's a really bad trade-off. Plus, downsampling a larger image on the fly on the device is likely to use a lower-quality downsampling algorithm than what's available in, say, Photoshop (for performance reasons).
I had an app with 100+ near-fullscreen photos, and dropping the #1x versions made possible to keep the app below the 50 MB limit for downloading over a cellular connection.
In my case, I had no choice, but as #Kevin Ballard mentions, perhaps the trade-off is not worth it. Remember that non-retina images are 25% the size of the retina ones, so in terms of pixels you are only going from 1.25 to 1.00.
Granted, with compressed images the relation might not be linear (i.e., #1x PNG/JPEG may weight more than 1/4 of the equivalent #2x image on disk).
I have built a photo app for the iphone which has albums of high resolution images that the user can flick through. It's based on Three20 and the TTThumbsViewController.
The images are currently mostly 2048x2048 or thereabouts but this seems too large given the screen is only 1024x768.
Is there any value in leaving them at the higher resolution or should I drop them to 1024x768?
If you want to allow some kind of zoom/pan functionality, then there is value leaving them at a higher resolution. Otherwise there isn't: they take up more space and need to be scaled down anyway.
Just a note: scaling up or down by a couple of pixels is bad for sharp edges. Try to avoid this.