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


98

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?


Quería agregar que las imágenes originales ya están en formato JPG si eso hace alguna diferencia.
Maverick

Respuestas:


140

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.


1
Todavía no he visto datos sobre el rendimiento de decodificación de JPEG vs PNG vs iPNG. A veces, el formato más comprimido es mejor debido a la reducción de E / S requerida; No estoy seguro de qué tan rápido es la unidad flash del iPhone. Y definitivamente no diría que la descompresión de PNG requiere "muy poca" energía; el archivo Other.artwork parece ser datos de mapa de bits sin procesar, presumiblemente porque la sobrecarga de CPU / memoria de la descompresión PNG es demasiado para los componentes de IU de uso común.
tc.

2
En mi proyecto actual, tenemos archivos png muy grandes debido a un requisito de transparencia. El disco IO supera con creces el tiempo dedicado a decodificar un jpeg. Tenga en cuenta que los archivos PNG también se comprimen, solo que utilizan un algoritmo diferente.
John

2
Pensé que agregaría un consejo adicional para aquellos que intentan maximizar el rendimiento de la imagen. SI tiene archivos JPG bien comprimidos, puede cargar los datos JPG sin procesar en objetos NSData de antemano (tal vez en una matriz o diccionario) y crear los JPG utilizando UIImage: imageFromData cuando desee mostrarlos. Los datos JPG pueden ser entre 10 y 100 veces más pequeños que los datos de la imagen de mapa de bits, pero le permite eliminar la parte IO (relativamente lenta) antes de tiempo. Obviamente, tenga cuidado con la cantidad de datos que almacena en caché / precarga de esta manera.
Nigel Flack

2
Encontré algunos datos sobre los tiempos de competencia : cocoanetics.com/2012/09/… Parece que usar png no es más rápido que jpg;)
Maciej Kozieł

20

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.


5
En mi punto de referencia, la optimización de Xcode en realidad hizo que los archivos fueran más lentos, probablemente porque la E / S del disco, no la CPU, es el cuello de botella.
Kornel

1
"Apple optimiza las imágenes PNG que se incluyen en el paquete de aplicaciones de su iPhone": ¿esto significa que los PNG que se descargan dinámicamente no están optimizados?
Robert

1
No, los PNG descargados dinámicamente no están optimizados. La optimización consiste básicamente en cambiar el orden de bytes de RGBA a BGRA, que es lo que utiliza internamente el chip gráfico del iPhone. Más información aquí: graphicsoptimization.com/blog/?p=259
Nick Lockwood

11

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/


9

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".


Exactamente, y JPEGMini e ImageOptim hacen que los archivos JPEG sean realmente pequeños.
electronix384128

7

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 ...


2
La GPU no puede descomprimir PNG. El formato de desinflado que utiliza no es adecuado para el tipo de paralelización que permite la GPU. Supongo que la decodificación JPG puede ser parcialmente acelerada por GPU, ya que hay una conversión de espacio de color involucrada.
Kornel

5

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.


1

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


3
Esto no aborda ninguna consideración de rendimiento de JPG vs PNG.
daveMac

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.