I have a simple question for anyone who knows the answer to this... I am making a social photo sharing app and I want to save a large enough image in the app so that it can be used in a full screen website app moving forward. Think...Facebook.
I've been playing around with JPEG compression in iOS and also testing sizes and quality with Photoshop CS5. I get really different results with these two. In photoshop, even at high compression, the image is quite clear and retains lots of detail. In iOS, once the compression dips below about 0.5 it looks horrible and blocky. It almost seems like there's a point where the image quality just dips after a certain magic compression number.
With photoshop, I use the "Save for Web" option and with iOS I am using UIImageJPEGRepresentation(image, 0.6). Is there a huge difference in these two? Aren't all JPEGs use the same kind of compression?
I am really not that informed in this world of image processing. Can anyone advice me on what is a good way to have images compressed to a level that preserves quality and stay bandwidth friendly? I want my images to stay about 1280px in length.
Any advice on this or smarter ways to move JPEGS over the network is welcomed. Thank you.
If your app is producing images from an iOS device, you should continue to use UIImageJPEGRepresentation. I don't think it's productive comparing the UIKit JPEG compression to Photoshop's.
I would find a JPEG compression level you're happy with using the available UIKit APIs and go with that. When you're serving up 30+million images a second it might be worth looking at optimisations but until then leave it to UIKit.
Related
I am into iOS development from past 1+ months and what I have experienced is that I have to put images for 1x 2x 3x for iphone and then 2x retina for ipad. One of the experienced designers has sugguested to me to go for svg format as it scales itself according to the screen sizes.
So my elaborated questions are:
Can I use svg instead of png?
Is it necessary to still put images in 2x and 3x for iphone and ipad if I'm using svg?
Will the images in svg scale according to the phone size and not lose quality?
If any other information according to your experience please share.
Thank you.
Official iOS Dev documentation says "the PNG format is the one most recommended for use in your apps". You can read it for a lot more information here.
Yes, although the supported file types table doesn't list it. Apple values user experience. SVG scaling consumes a few more CPU cycles which they don't like. PNG rendering is more efficient than SVG.
Yes, Apple explicitly recommends using multiple versions of the image at different sizes. Then scaling can be done from the file having the nearest dimensions.
Refer 1. There are cases like zoom-in / out scenarios where SVGs would be better though.
You could use vectorized PDFs alternatively. You can read more here. It isn't without limitations, but with vectorized PDFs, Xcode automatically generates scaled versions. That should make life easier. Note that sometimes the scaled results look quite poor.
My app requires that each user has a profile picture of around 140*140px. Right now I am using jpgs, I am wondering if performance wise it will be better to use pngs. I read pngs are good for small UI elements and images, jpg for large images with detail such as photos. Obviously my profile pics are photos but they are small. Would it make much difference switching to png? Thanks
JPEG is best for small file sizes of photos, even for low resolutions.
PNG makes sense when there are many pixels of the exact same color next to each other. This is not the case with photos.
These should be helpful for you.
When to use PNG or JPG in iPhone development?
PNG vs. GIF vs. JPEG vs. SVG - When best to use?
Apple optimizes PNG images that are included in your iPhone app bundle. In fact, the iPhone uses a special encoding in which the color bytes are optimized for the hardware. XCode handles this special encoding for you when you build your project. So, you do see additional benefits to using PNG's on an iPhone other than their size consideration. For this reason it is definitely recommended to use PNG's for any images that appear as part of the interface (in a table view, labels, etc).
As for displaying a full screen image such as a photograph you may still reap benefits with PNG's since they are non-lossy and the visual quality should be better than a JPG not to mention resource usage with decoding the image. You may need to decrease the quality of your JPG's in order to see a real benefit in file size but then you are displaying non-optimal images.
File size is certainly a factor but there are other considerations at play as well when choosing an image format.
I have a question about png-8 vs png-24 usage vs Xcode's built in "image compressor".
Some images converted to png-8 are just fine saved like that, because difference between png-24 version can't be noticed easily. But some images have to be stored as png-24 so that quality remains at high level... Same image is about 3 times smaller when saved like png-8, so I guess there would be some benefits in memory consumption when using png-8 vs png-24. But what I am not sure is:
Does iOS "likes" more png-24 ?
Are there any problems with using png-8 instead of png-24 in iOS and what is a preferred choice ?
What are benefits to optimize image in PS (or some program like TexturePacker) when COMPRESS_PNG_FILES in Xcode is set to YES because I suppose Xcode in some way overwrites our optimization done in PS?
What actually Xcode does when optimizing images?
I know that just letting Xcode to do what it suppose to do is probably more than enough, especially for newer devices with enough memory and cpu power, but I am curios what's happening "under the hood" and is it wasting of time doing optimization in Photoshop?
Does iOS "likes" more png-24?
iOS certainly likes its images to be close to its own hardware format (see below). However, it may not presume a certain format, or convert images at will. This would mean that the default postprocessing could convert images from palettized (8-bit) to true-color images, and that would be destructive if the application expects its images to contain a palette. There are many good & proper uses of palettized images.
Are there any problems with using png-8 instead of png-24 in iOS and what is a preferred choice?
Color depth - higher is better, for some kinds of images (but not all). Size - smaller is better (and for deciding when, you are on your own). Other than Sangony states, the PNG specification is generous enough to allow more than a single bit of alpha even in indexed mode. That is, the usual RGB palette may also be RGBA, including alpha. I am not aware of any "problems" with more common PNG formats, or even the uncommon ones.
What are benefits to optimize image in PS (or some program like TexturePacker) when COMPRESS_PNG_FILES in Xcode is set to YES because I suppose Xcode in some way overwrites our optimization done in PS?
Photoshop is not extremely good at optimizing PNGs, but then again it's certainly not one of the worst. pngcrush (the original) is written specifically to try and squeeze the very last byte out of a PNG -- but at its highest setting, it can really take a while to do so. I may have used Apple's modified pngcrush unknowingly, since it is "on" by default; I have not found such a huge delay when compiling code, so Apple's default may be not the highest possible setting. This suggests that manually running pngcrush could be worth the time, in which case you definitely do not want XCode to undo it.
What actually Xcode does when optimizing images?
The most visible 'optimizations' are: switching storage order from RGB to BGR and discarding the alpha channel by premultiplying it with the color channels. See also my earlier answer.
The storage order thingy is, presumably, optimal for the default target devices (iPads, iPhones). Premultiplying alpha is a common method of optimizing, because then it takes less calculations to display the images in real time. (There are some disadvantages to it as well.)
Without any exact measurements, one can only speculate if these optimizations really matter on modern hardware. All internal conversions to 'display' format may very well be cached as quickly as possible.
Xcode uses PngCrush behind the scenes to optimize .png files. Here is also a good blog post that can answer your questions.
Aside from the available colors between PNG8 and PNG 24, the main difference is the the transparency aspect.
PNG8 alpha can sometimes be somewhat jagged in appearance whereas PNG24 is much smoother. If alpha is not a concern for you and the image looks good enough, then PNG8 is probably the way to go.
PNG8 Alpha
PNG24 Alpha
I am trying to load a scaled down version of an image without loading original sized image into memory. To reach this goal I was using ImageIO framework. However in this case I face unacceptable loss of quality.
This way I can re-size my image, however original size has to be loaded into memory.
Is there a way to get good quality lower resolution image without loading large image into memory?
Using apple libraries would be preferable, but if there is no other way, third-party library would also be acceptable.
May be Accelerate.framework can help. Use vImageScale_Planar8 to resize image. As I know, this framework supports tiling, probably it will reduce memory required.
Well, i wonder, what compression procession processes they are using..
I uploaded a test image of 2.3mb and suddenly downloaded it
It was only only 92 kbs, what the heck, only 92 kb's
and the thumbnail was only 11 kbs..
How this all is done and what algorithms are utilized.. how do i do it..
If I had to guess, the file size decrease is probably due primarily to just old-fashioned downsampling. Images on facebook are sized to be viewed on part of a screen, but not much larger.
For instance, I uploaded a picture that was 3456x2304 (3.2MB) which is 7,962,624 pixels. This was downsized by facebook to 960x602 (85kB) which is only 577,920 pixels. That only about 1/14th the total number of pixels.
This probably explains the majority of the difference, but it also looks like they are using the sRGB color profile, which can reduce file sizes.
One other possibility is that most JPEG encoders have a quality setting. They may be using a lower quality setting than that of the original.