¿Cuándo usar PNG o JPG en el desarrollo de iPhone?

Tengo una aplicación que mostrará un montón de imágenes en una presentación de diapositivas. Esas imágenes formarán parte del paquete, por lo que se distribuirán con la aplicación.

Todas las imágenes son fotografías o fotográficas, etc.

He leído que se prefiere usar PNG como formato de imagen, pero dado que la versión JPG será mucho más pequeña, preferiría usar eso.

¿Existe alguna pauta sobre qué formato utilizar y en qué caso?

Los PNG son píxeles perfectos (sin pérdida) y requieren muy poca energía adicional de CPU para mostrarse. Sin embargo, los PNG grandes pueden tardar más en leerse desde el almacenamiento que los formatos de imagen más comprimidos y, por lo tanto, su visualización es más lenta.

Los JPG son más pequeños de almacenar, pero tienen pérdidas (la cantidad depende del nivel de compresión), y mostrarlos requiere un algoritmo de decodificación mucho más complicado. Pero la compresión y la calidad de imagen típicas suelen ser suficientes para las fotos.

Use JPG para fotos y para cualquier cosa grande, y PNG para cualquier cosa pequeña y / o diseñada para mostrarse con "píxeles perfectos" (por ejemplo, iconos pequeños) o como parte de una superposición transparente compuesta, etc.

Apple optimiza las imágenes PNG que se incluyen en el paquete de aplicaciones de su iPhone. De hecho, el iPhone utiliza una codificación especial en la que los bytes de color están optimizados para el hardware. XCode maneja esta codificación especial por usted cuando construye su proyecto. Por lo tanto, ve beneficios adicionales al usar PNG en un iPhone además de su tamaño. Por esta razón, definitivamente se recomienda usar PNG para cualquier imagen que aparezca como parte de la interfaz (en una vista de tabla, etiquetas, etc.).

En cuanto a mostrar una imagen de pantalla completa, como una fotografía, aún puede obtener beneficios con los PNG, ya que no tienen pérdidas y la calidad visual debería ser mejor que un JPG, sin mencionar el uso de recursos con la decodificación de la imagen. Es posible que deba disminuir la calidad de sus JPG para ver un beneficio real en el tamaño del archivo, pero luego está mostrando imágenes no óptimas.

El tamaño del archivo es ciertamente un factor, pero también hay otras consideraciones en juego al elegir un formato de imagen.

Hay una cosa importante en la que pensar con los PNG. Si se incluye un PNG en su compilación de Xcode, se optimizará para iOS. Esto se llama aplastamiento PNG. Si su PNG se descarga en tiempo de ejecución, no se triturará. Los PNG triturados se ejecutan aproximadamente igual que los JPG al 100%. Los JPG de menor calidad se ejecutan mejor que los JPG de mayor calidad. Por lo tanto, desde el punto de vista del rendimiento, de más rápido a más lento, sería JPG de baja calidad, JPG de alta calidad, PNG triturado, PNG.

Si necesita descargar archivos PNG, debería considerar aplastar los archivos PNG en el servidor antes de la descarga.

http://www.cocoanetics.com/2011/10/avoiding-image-decompression-sickness/

El blog Cocoanetics publicó un buen punto de referencia de rendimiento de iOS de JPG en varios niveles de calidad y PNG, con y sin trituración.

De su conclusión:

Si absolutamente necesita un canal alfa o tiene que utilizar PNG, es recomendable instalar la herramienta pngcrush en su servidor web y hacer que procese todos sus PNG. En casi todos los demás casos, los archivos JPEG de alta calidad combinan tamaños de archivo más pequeños (es decir, una transmisión más rápida) con una compresión y procesamiento más rápidos.

Resulta que los archivos PNG son excelentes para imágenes pequeñas que usarías para elementos de la interfaz de usuario, pero no es razonable usarlos para aplicaciones de pantalla completa como catálogos o revistas. Allí querrá elegir una calidad de compresión entre 60 y 80% dependiendo de su material de origen.

En términos de hacer que se muestre todo, querrá quedarse con las instancias de UIImage de las que haya extraído una vez porque tienen una versión en caché sin comprimir del archivo. Y donde no haga una pausa visual para que aparezca una imagen grande en la pantalla, tendrá que forzar la descompresión de un par de imágenes por adelantado. Pero tenga en cuenta que estos requerirán una gran cantidad de RAM y, si se excede, podría hacer que se cancele la aplicación. NSCache es un gran lugar para colocar imágenes de uso frecuente porque automáticamente se encarga de expulsar las imágenes cuando la RAM escasea.

Es lamentable que no tengamos ninguna forma de saber si una imagen todavía necesita descomprimirse o no. Además, una imagen podría haber desalojado la versión sin comprimir sin informarnos sobre este efecto. Ese podría ser un buen radar para plantear en el sitio de informes de errores de Apple. Pero, afortunadamente, acceder a la imagen como se muestra arriba no lleva tiempo si la imagen ya está descomprimida. Así que podría hacer eso no solo "justo a tiempo" sino también "por si acaso".

Solo pensé en compartir un poco de datos de rendimiento de descompresión ...

Estoy haciendo un prototipo de un visor de 360 ​​grados: un carrusel donde el usuario puede girar a través de una serie de fotos tomadas desde diferentes ángulos, para dar la impresión de poder girar un objeto sin problemas.

He cargado los datos de la imagen en una matriz de NSData para eliminar la E / S de archivos de la ecuación, pero creo NSImage sobre la marcha. Probando a una velocidad de fotogramas cercana a la máxima (~ 25 fps) y viendo en Instruments, veo que la aplicación está claramente vinculada a la CPU y hay un aumento de aproximadamente un 10% en la carga de la CPU que muestra ~ 275 kb png frente a ~ 75 kb jpg.

No puedo decirlo con certeza, pero supongo que el límite de la CPU es solo por la ejecución general del programa y el movimiento de todos los datos en la memoria, pero la descompresión de la imagen se realiza en la GPU. De cualquier manera, el argumento de rendimiento JPG frente a PNG parece favorecer a JPG, especialmente cuando se toman en consideración los tamaños de archivo más pequeños (y por lo tanto, los tamaños más pequeños de los objetos en la memoria al menos en algunas partes de la cadena).

Por supuesto, cada situación es diferente, no hay sustituto para las pruebas ...

He encontrado enormes diferencias en el rendimiento de la animación al usar jpegs vs png. Por ejemplo, colocar tres jpegs del tamaño de una pantalla uno al lado del otro en un UIScrollView y desplazarse horizontalmente en un iPhone4 da como resultado un retraso y una animación espasmódica completamente desagradable. Con PNG no transparentes de las mismas dimensiones, el desplazamiento es suave. Nunca uso jpegs, incluso si la imagen es grande.

Creo que si quieres usar transparente, no tienes más remedio que PNG. Pero, si su fondo ya es opaco, entonces puede usar JPG. Esa es la única diferencia que puedo ver

'Use JPEG para fotos' como se menciona en las Pautas de interfaz humana en la sección Producir ilustraciones en el formato apropiado.