5

According to the research done here http://imageoptim.com/tweetbot.html, Xcode's conversion of PNGs to the proprietary Apple CgBI format does not create a noticeable performance improvement. Their claim is that the conversion only reduces PNG loading speed by 1 nanosecond.

If this is true, why does apple bother with the CgBI format at all? Has anyone else benchmarked loading CgBI images vs regular PNG images on iOS devices to see if they perform differently?

Gdeglin
  • 159
  • 3
  • 3
    I have a feeling the answer to this is "Apple wants to push their proprietary format"... – Roc Martí Oct 23 '12 at 02:19
  • 1
    I thought Apple had given up pushing their proprietary formats when they found out they could make more money by using standards. – Mr Lister Oct 23 '12 at 05:44
  • 1
    Is there any hardware involved? Even if it is the same loading speed, rendering an image can take different amounts of cpu time based on the hardware present. This then translates to different battery life. –  Oct 23 '12 at 13:36

1 Answers1

2

This blog post describing the patent that Apple filed for the CgBI format implies that Apple thought there were some technical benefits from the conversion. Specifically:

  • If the file has the CgBI header, then CRCs can be ignored
  • The RGBA pixels are written in a different order (BGRA)
  • The data is pre-multiplied if there is an alpha channel

The first and last benefit are more likely to be of value, but I'm not a graphics expert.

With the post you displayed in your question, there is a subtle shift of attention in the results comparison.

The list 4 sets of images and their sizes.

  • Unoptimized (aka PNG) at 49.63MB
  • Xcode converted to CgBI at 26.46MB
  • ImageOptim optimization of the PNG images at 16.81MB
  • ImageAlpha + ImageOptim optimization at 9.37MB

And there are two additional things to note. First, the second two sets of images are the results of their compression routines. Second, they note that they ran repeated compressions (optimizations) of the images until they didn't get any additional benefit. Despite their wanting you to believe otherwise, those sets of numbers are not apples to apples comparisons.

Discussing load speed, they state: Although Xcode optimisation is assumed to improve decoding speed of PNG images, testing on an actual device disproves that. Xcode-optimized images were significantly slower to display.

And they provide three, not four, sets of results to review. They do not provide loading times for the unoptimized PNG images, they only provide results for the CgBI and ImageOptim optimized images. Not so surprisingly, their product's optimizations outperform what Xcode will provide.

They even go so far as to state that Decoding speed appears to be correlated to image file size more than anything else. Later in the article, they provide another link that confirms their observation regarding file size. Using a bit of logic we can safely conclude that if they had provided loading times for the unoptimized PNG images, then that would have been the slowest performing set since it was also the largest image set.

So the basis of your question is a bit off - Xcode's conversion to CgBI does provide performance enhancement because of the smaller image file size. We can tell by the image file sizes alone. While the ImageOptim folk were able to get to 1/3rd or 1/5th of the original file size with multiple passes, Xcode's conversion got to roughly 1/2th the original file size on a single pass.

So Xcode gives you "out-of-the-box" performance improvements by a factor of two from a single optimization path.
Add-on alternatives like ImageOptim exist to get greater improvements but at a cost of additional rounds of optimization.