Quand utiliser PNG ou JPG dans le développement iPhone?


98

J'ai une application qui affichera un tas d'images dans un diaporama. Ces images feront partie du bundle, ainsi distribué avec l'application.

Toutes les images sont des photographies ou des photographies, etc.

J'ai lu qu'il était préférable d'utiliser PNG comme format d'image, mais vu que la version JPG sera beaucoup plus petite, je préfère l'utiliser.

Existe-t-il des directives sur le format à utiliser et dans quel cas?


Je voulais ajouter que les images originales sont déjà toutes au format JPG si cela fait une différence.
Maverick

Réponses:


140

Les PNG sont parfaits au pixel près (sans perte) et nécessitent très peu d'énergie supplémentaire du processeur pour s'afficher. Cependant, les fichiers PNG volumineux peuvent prendre plus de temps à lire à partir du stockage que les formats d'image plus compressés, et donc être plus lents à afficher.

Les JPG sont plus petits à stocker, mais avec perte (la quantité dépend du niveau de compression), et leur affichage nécessite un algorithme de décodage beaucoup plus compliqué. Mais la compression et la qualité d'image typiques sont généralement tout à fait suffisantes pour les photos.

Utilisez les JPG pour les photos et pour tout ce qui est grand, et PNG pour tout ce qui est petit et / ou conçu pour être affiché "pixel perfect" (par exemple, de petites icônes) ou dans le cadre d'une superposition transparente composite, etc.


1
Je n'ai pas encore vu de données sur les performances de décodage JPEG vs PNG vs iPNG. Parfois, le format plus compressé est meilleur en raison de la réduction des E / S requises; Je ne sais pas à quelle vitesse le lecteur flash de l'iPhone est. Et je ne dirais certainement pas que la décompression PNG nécessite "très peu" d'énergie; le fichier Other.artwork semble être des données bitmap brutes, probablement parce que la surcharge CPU / mémoire de la décompression PNG est trop importante pour les composants d'interface utilisateur couramment utilisés.
tc.

2
Sur mon projet actuel, nous avons de très gros fichiers png en raison d'une exigence de transparence. Le disque IO dépasse largement le temps passé à décoder un jpeg. Gardez à l'esprit que les PNG sont également compressés, en utilisant simplement un algorithme différent.
John

2
Je pensais que j'ajouterais un conseil supplémentaire pour ceux qui essaient de maximiser les performances de l'image. Si vous avez des JPG bien compressés, vous pouvez charger les données JPG brutes dans des objets NSData à l'avance (peut-être dans un tableau ou un dictionnaire), et créer les JPG à l'aide de UIImage: imageFromData lorsque vous souhaitez les afficher. Les données JPG peuvent être 10 à 100 fois plus petites que les données d'image bitmap, mais cela vous permet de supprimer la partie IO (relativement lente) de manière précoce. Faites bien évidemment attention à la quantité de données que vous mettez en cache / préchargez de cette façon.
Nigel Flack

2
J'ai trouvé des données sur les temps de compression: cocoanetics.com/2012/09/ ... Il semble que l'utilisation de png ne soit pas plus rapide que de jpg;)
Maciej Kozieł

20

Apple optimise les images PNG qui sont incluses dans votre offre d'applications iPhone. En fait, l'iPhone utilise un encodage spécial dans lequel les octets de couleur sont optimisés pour le matériel. XCode gère cet encodage spécial pour vous lorsque vous créez votre projet. Ainsi, vous voyez des avantages supplémentaires à l'utilisation de PNG sur un iPhone autres que leur taille. Pour cette raison, il est définitivement recommandé d'utiliser des PNG pour toutes les images qui apparaissent dans le cadre de l'interface (dans une vue de tableau, des étiquettes, etc.).

En ce qui concerne l'affichage d'une image en plein écran telle qu'une photographie, vous pouvez toujours profiter des avantages des PNG car ils sont sans perte et la qualité visuelle devrait être meilleure qu'un JPG sans parler de l'utilisation des ressources avec le décodage de l'image. Vous devrez peut-être diminuer la qualité de vos JPG afin de voir un réel avantage en taille de fichier, mais alors vous affichez des images non optimales.

La taille du fichier est certainement un facteur, mais il y a également d'autres considérations en jeu lors du choix d'un format d'image.


5
Dans mon benchmark, l' optimisation Xcode a en fait ralenti les fichiers, probablement parce que les E / S disque, et non le processeur, sont le goulot d'étranglement.
Kornel

1
"Apple optimise les images PNG qui sont incluses dans votre bundle d'applications iPhone" - Cela signifie-t-il que les PNG téléchargés dynamiquement ne sont pas optimisés?
Robert

1
Non, les fichiers PNG téléchargés dynamiquement ne sont pas optimisés. L'optimisation consiste essentiellement à échanger l'ordre des octets de RGBA à BGRA, ce que la puce graphique de l'iPhone utilise en interne. Plus d'informations ici: graphicsoptimization.com/blog/?p=259
Nick Lockwood

11

Il y a une chose importante à penser avec les PNG. Si un PNG est inclus dans votre build Xcode, il sera optimisé pour iOS. C'est ce qu'on appelle l'écrasement PNG. Si votre PNG est téléchargé au moment de l'exécution, il ne sera pas écrasé. Les PNG écrasés fonctionnent à peu près de la même manière que les JPG à 100%. Les JPG de qualité inférieure fonctionnent mieux que les JPG de qualité supérieure. Donc, du point de vue des performances, du plus rapide au plus lent, cela irait au JPG de basse qualité, au JPG de haute qualité, au PNG écrasé, au PNG.

Si vous avez besoin de télécharger des PNG, vous devriez envisager d'écraser les PNG sur le serveur avant le téléchargement.

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


9

Le blog Cocoanetics a publié une belle référence de performance iOS des JPG à différents niveaux de qualité, et des PNG, avec et sans écrasement.

De sa conclusion:

Si vous avez absolument besoin d'un canal alpha ou que vous devez utiliser des PNG, il est conseillé d'installer l'outil pngcrush sur votre serveur Web et de le faire traiter tous vos PNG. Dans presque tous les autres cas, les fichiers JPEG de haute qualité combinent des tailles de fichier plus petites (c'est-à-dire une transmission plus rapide) avec une compression et un rendu plus rapides.

Il s'avère que les PNG sont parfaits pour les petites images que vous utiliseriez pour les éléments de l'interface utilisateur, mais ils ne sont pas raisonnables à utiliser pour des applications en plein écran telles que des catalogues ou des magazines. Là, vous voudrez choisir une qualité de compression entre 60 et 80% en fonction de votre matériel source.

En termes de tout afficher, vous voudrez vous accrocher aux instances UIImage à partir desquelles vous avez dessiné une fois, car elles contiennent une version non compressée du fichier en cache. Et si vous ne faites pas de pause visuelle pour qu'une grande image apparaisse à l'écran, vous devrez forcer la décompression pour quelques images à l'avance. Mais gardez à l'esprit que cela prendra de grandes quantités de RAM et que si vous en faites trop, cela pourrait entraîner l'arrêt de votre application. NSCache est un endroit idéal pour placer des images fréquemment utilisées, car cela prend automatiquement en charge l'expulsion des images lorsque la RAM devient rare.

Il est regrettable que nous n'ayons aucun moyen de savoir si une image doit encore être décompressée ou non. Une image peut également avoir expulsé la version non compressée sans nous informer de cet effet. Cela pourrait être un bon radar à signaler sur le site de rapport de bogues d'Apple. Mais heureusement, accéder à l'image comme indiqué ci-dessus ne prend pas de temps si l'image est déjà décompressée. Vous pouvez donc le faire non seulement «juste à temps» mais aussi «juste au cas où».


Exactement, et JPEGMini et ImageOptim rendent les jpeg vraiment petits!
electronix384128

7

Je pensais juste que je partagerais un peu de données sur les performances de décompression ...

Je fais du prototypage d'une visionneuse à 360 degrés - un carrousel où l'utilisateur peut faire défiler une série de photos prises sous différents angles, pour donner l'impression de pouvoir faire pivoter un objet en douceur.

J'ai chargé les données d'image dans un tableau de NSData pour retirer les entrées / sorties de fichiers de l'équation, mais créer des NSImage à la volée. Tester à une fréquence d'images presque maximale (~ 25 fps) et regarder dans Instruments Je vois que l'application est clairement liée au processeur et qu'il y a une augmentation d'environ 10% de la charge du processeur montrant ~ 275 kb png par rapport à ~ 75 kb jpg.

Je ne peux pas le dire avec certitude, mais je suppose que la limite du processeur provient uniquement de l'exécution générale du programme et du déplacement de toutes les données en mémoire, mais cette décompression d'image est effectuée sur le GPU. Quoi qu'il en soit, l'argument de performance JPG contre PNG semble favoriser JPG, en particulier lorsque les tailles de fichier plus petites (et donc les plus petites tailles d'objets en mémoire au moins dans certaines parties de la chaîne) sont prises en compte.

Bien sûr, chaque situation est différente, il n'y a pas de substitut aux tests ...


2
Le GPU ne peut pas décompresser les PNG. Le format de dégonflage qu'il utilise n'est pas adapté au type de parallélisation que le GPU permet. Je suppose que le décodage JPG peut être partiellement accéléré par GPU, car il y a une conversion d'espace colorimétrique.
Kornel

5

J'ai trouvé d'énormes différences dans les performances d'animation lors de l'utilisation de jpeg par rapport à png. Par exemple, placer trois jpeg de la taille d'un écran côte à côte dans un UIScrollView et faire défiler horizontalement sur un iPhone4 entraîne un décalage et une animation saccadée complètement désagréable. Avec des png non transparents de mêmes dimensions, le défilement est fluide. Je n'utilise jamais de jpeg, même si l'image est grande.


1

Je pense que si vous voulez utiliser transparent, vous n'avez pas d'autre choix que PNG. Mais, si votre arrière-plan est déjà opaque, vous pouvez utiliser JPG. C'est la seule différence que je peux voir


3
Cela ne tient pas compte des considérations de performances de JPG par rapport à PNG.
daveMac

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.