Quand utiliser PNG ou JPG dans le développement d'un iPhone?
J'ai une application qui va afficher un tas d'images dans un diaporama. Ces images feront partie du lot, et seront donc distribuées avec l'application.
Toutes les images sont des photographies ou photographiques, etc.
J'ai lu qu'il était préférable d'utiliser le format d'image PNG, mais comme la version JPG sera beaucoup plus petite, je préférerais l'utiliser.
Existe-t-il des directives sur le format à utiliser et dans quel cas?
Les PNG sont parfaits en pixels (sans perte) et nécessitent très peu d’énergie supplémentaire pour l’affichage. Cependant, les fichiers PNG volumineux peuvent prendre plus de temps à lire à partir du stockage que davantage de formats d'image compressés, et donc être plus lents à s'afficher.
Les fichiers JPG sont plus petits à stocker, mais avec des pertes (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 suffisantes pour les photos.
Utilisez des JPG pour les photos et tout ce qui est grand, et les PNG pour tout ce qui est petit et/ou conçu pour être affiché "pixel parfait" (par exemple, de petites icônes) ou en tant que partie d'un calque transparent composé, etc.
Apple optimise les images PNG incluses dans l'ensemble d'applications de votre 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 construisez votre projet. Ainsi, vous voyez des avantages supplémentaires à utiliser des PNG sur un iPhone autres que leur taille. Pour cette raison, il est définitivement recommandé d'utiliser des fichiers PNG pour toutes les images qui apparaissent dans l'interface (dans un tableau, des étiquettes, etc.).
En ce qui concerne l'affichage d'une image plein écran telle qu'une photographie, vous pouvez toujours tirer parti des PNG, car ils ne causent pas de pertes et que la qualité visuelle devrait être supérieure à celle d'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 fichiers JPG afin de voir un réel avantage en termes de taille de fichier, mais vous afficherez alors des images non optimales.
La taille du fichier est certes un facteur à prendre en compte, mais il faut également tenir compte d'autres considérations lors du choix d'un format d'image.
Il y a une chose importante à considérer avec les PNG. Si un fichier PNG est inclus dans votre compilation Xcode, il sera optimisé pour iOS. Ceci s'appelle PNG crush. 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. Ainsi, du point de vue des performances, du plus rapide au plus lent, il s'agirait de JPG de qualité inférieure, JPG de haute qualité, PNG Crushed, PNG.
Si vous devez télécharger des fichiers PNG, vous devez envisager de les écraser sur le serveur avant le téléchargement.
http://www.cocoanetics.com/2011/10/avoiding-image-decompression-sickness/
Le blog Cocoanetics a publié un benchmark de performances Nice iOS de fichiers JPG de différents niveaux de qualité et de fichiers PNG, avec et sans écrasement.
De sa conclusion:
Si vous avez absolument besoin d'un canal alpha ou si vous devez utiliser des fichiers PNG, alors Il est conseillé d'installer l'outil pngcrush sur votre serveur web et faites-le traiter tous vos fichiers PNG. Dans presque tous les autres cas, haute qualité Les fichiers JPEG associent des fichiers plus petits (transmission plus rapide) à compression et 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 d'utiliser pour tout applications d’écran telles que catalogues ou magazines. Là vous voudriez choisir une qualité de compression entre 60 et 80% en fonction de votre matériel source.
Pour tout afficher, vous voudrez vous en tenir à Les instances UIImage dont vous avez tiré une fois parce que celles-ci ont un mis en cache la version non compressée du fichier qu’ils contiennent. Et là où vous ne le faites pas la pause visuelle pour qu'une grande image apparaisse à l'écran, vous aurez forcer la décompression de quelques images à l’avance. Mais tenez compte sachez que cela prendra une grande quantité de RAM et si vous êtes en faire trop, ce qui pourrait entraîner la fermeture de votre application. NSCache est un excellent endroit pour placer des images fréquemment utilisées parce que cela automatiquement s’occupe de l’expulsion des images lorsque RAM devient rare.
Il est regrettable que nous n’ayons aucun moyen de savoir si un .__ ou non. l'image doit encore être décompressée ou non. Une image peut aussi avoir expulsé la version non compressée sans nous informer à ce sujet effet. Cela pourrait être un bon radar à signaler aux rapports de bogues d’Apple site. Mais heureusement, accéder à l'image comme indiqué ci-dessus ne prend pas de temps si l'image est déjà décompressée. Donc, vous pouvez simplement le faire non seulement «juste à temps» mais aussi «juste au cas où».
Je pensais juste partager un peu de données de performance de décompression ...
Je fais un peu le prototypage d'un spectateur à 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 extraire les entrées/sorties de fichiers de l'équation, mais créer NSImage à la volée. Tester à une cadence maximale (~ 25 i/s) et regarder dans Instruments Je vois que l'application est clairement liée au processeur et que la charge du processeur a augmenté d'environ 10%, ce qui correspond à environ 275 kb png et environ 75 kb.
Je ne peux pas dire avec certitude, mais je suppose que la limite du processeur réside uniquement dans l'exécution générale du programme et le déplacement de toutes les données en mémoire, mais cette décompression d'image est effectuée sur le GPU. De toute façon, l'argument de performance JPG vs. PNG semble favoriser JPG, en particulier lorsque les tailles de fichier plus petites (et donc les objets plus petits en mémoire au moins dans certaines parties de la chaîne) sont prises en compte.
Bien sûr, chaque situation est différente, rien ne remplace les tests ...
J'ai trouvé des différences énormes dans les performances d'animation lors de l'utilisation de jpeg vs 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 un décalage et une animation saccadée désagréable. Avec des pngs non transparents de mêmes dimensions, le défilement est lisse. Je n'utilise jamais de fichiers JPEG, même si l'image est grande.
Je pense que si vous voulez utiliser transparent, vous n’avez pas le choix, sauf 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
"Utiliser JPEG pour les photos" comme indiqué dans Guide de l'interface humaine dans la section Produire une illustration dans le format approprié.