J'ai une application qui affiche un tas d'images dans un diaporama. Ces images seront partie de l'ensemble, ainsi distribué avec l'application.
Toutes les images sont des photographies ou photographiques, etc.
J'ai lu qu'il est préférable d'utiliser PNG, le format de l'image, mais vu que le JPG version sera beaucoup plus petite, je préférerais être en utilisant.
Existe-il des lignes directrices de format à utiliser et dans quel cas?
PNG pixel sont parfait (sans perte), et nécessitent très peu de CPU en plus d'énergie pour l'affichage. Cependant, de grandes Png peut prendre plus de temps à lire à partir de stockage de plus compressé formats d'image, et donc d'être plus lent à afficher.
Les JPG sont plus petits pour stocker, mais avec perte (le montant varie selon le niveau de compression), et de les afficher nécessite beaucoup plus compliqué algorithme de décodage. Mais typiques de la compression et de la qualité de l'image est habituellement tout à fait suffisant pour des photos.
Utiliser les JPG pour les photos et pour quelque chose de grand, et le PNG pour les tout petits et/ou conçu pour être affiché "pixel perfect" (par ex. petites icônes) ou comme une partie d'un composite superposition transparente, etc.
Apple optimise les images PNG qui sont inclus dans votre application iPhone bundle. En fait, l'iPhone utilise un encodage dans lequel la couleur octets sont optimisés pour le matériel. XCode gère un codage spécial pour vous lorsque vous générez votre projet. Donc, vous voyez des avantages supplémentaires à l'aide de la PNG sur un iPhone autre que leur taille en considération. Pour cette raison, il est fortement recommandé d'utiliser le format PNG pour les images qui apparaissent dans le cadre de l'interface dans une vue de table, étiquettes, etc).
Comme pour l'affichage plein écran de l'image telle qu'une photographie, vous pouvez toujours profiter de tous les bienfaits avec PNG, car ils sont non-destructive et la qualité visuelle doit être mieux qu'un JPG pour ne pas mentionner l'utilisation des ressources avec le décodage de l'image. Vous devrez peut-être diminuer la qualité de votre JPG pour voir un réel avantage de la taille du fichier, mais alors vous êtes en affichage non-optimale des images.
La taille du fichier est certainement un facteur, mais il y a d'autres considérations qui entrent en jeu lors du choix d'un format d'image.
Il y a une chose importante à penser avec les Png. Si un PNG qui est inclus dans votre Xcode construire, sera optimisé pour iOS. Ceci est appelé PNG écraser. Si votre PNG est téléchargé au moment de l'exécution, il ne sera pas écrasé. Écrasé Png exécuter sur la même chose que 100% des Jpg. De qualité inférieure Jpg de mieux courir que plus de la qualité des Jpg. Donc, à partir d'un point de vue des performances du plus rapide au plus lent, il irait de faible qualité JPG, de haute qualité, JPG, PNG Écrasé, PNG.
Si vous avez besoin de télécharger le format Png vous devriez envisager l'écrasement de la Png sur le serveur avant de le télécharger.
http://www.cocoanetics.com/2011/10/avoiding-image-decompression-sickness/
Le Cocoanetics blog publié un joli iOS de référence du rendement des images Jpg à différents niveaux de qualité, et Png, avec et sans les écraser.
De sa conclusion:
Si vous avez absolument besoin d'un canal alpha ou aller avec les Png puis il est conseillé d'installer la pngcrush outil sur votre serveur web et avoir tous vos Png. Dans presque tous les autres cas de haute qualité Jpeg combiner des fichiers de taille plus petite (c'est à dire une transmission plus rapide) avec compression rapide et le rendu.
Il s'avère que les Png sont parfaits pour les petites images que vous pouvez utiliser pour les éléments de l'INTERFACE utilisateur, mais ils ne sont pas raisonnable de les utiliser pour n'importe quelle l'écran des applications comme des catalogues ou magazines. Là, vous voulez pour choisir une qualité de compression entre 60 et 80% selon votre le matériel source.
En termes de mise à l'écran, vous voulez accrocher sur UIImage instances à partir de laquelle vous avez dessiné une fois parce que ceux qui ont un cache version non compressée du fichier. Et où vous n'avez pas le visuel de pause pour une grande image à afficher sur l'écran, vous aurez à force de décompression pour un couple d'images à l'avance. Mais gardez à l' l'esprit que ces vont prendre de grandes quantités de mémoire vive et si vous êtes les excès qui pourraient causer à votre application d'être résilié. NSCache est un endroit idéal pour placer fréquemment utilisé des images parce que cela automatiquement prend soin de les expulser, les images lors de la RAM se fait rare.
Il est regrettable que nous n'avons pas de moyen de savoir si ou non un l'image a encore besoin de décompresser ou pas. Aussi une image peut avoir expulsés de la version non compressée sans nous en informer à ce effet. Cela pourrait être une bonne Radar de soulever à Apple de signalement de bug site. Mais heureusement accéder à l'image comme indiqué ci-dessus ne prend pas de temps si l'image est déjà décompressé. Si vous pouviez juste faire pas seulement "juste à temps", mais aussi "au cas où".
Juste pensé que je devais partager un peu de décompression des données de performance...
Je suis en train de faire quelques prototypage d'un 360 degré viewer - un carrousel où l'utilisateur peut tourner à travers une série de photos prises sous des angles différents, pour donner l'impression d'être en mesure de bien faire pivoter un objet.
J'ai chargé les données d'image dans un tableau de NSData pour prendre des e/s de fichier de l'équation, mais de créer NSImage sur la volée. Des tests à près de fréquence d'images maximale (~25 fps) et de regarder dans les Instruments, je vois que l'application est clairement lié au PROCESSEUR et il y a environ 10% d'augmentation de la charge CPU montrant ~275 kb png vs ~75 ko au format jpg.
Je ne peux pas dire pour sûr, mais ma conjecture est que le CPU limite est du programme général d'exécution et le transfert de toutes les données dans la mémoire, mais que l'image de la décompression se fait sur le GPU. De toute façon, et le JPG vs PNG performance argument ressemble à la faveur JPG, surtout quand la plus petite taille de fichier (et donc de plus petites tailles d'objets en mémoire, au moins dans certaines parties de la chaîne) est pris en considération.
Bien sûr, chaque situation est différente, il n'y a pas de substitut pour le test...
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
