Quando utilizzare PNG o JPG nello sviluppo di iPhone?

Ho un'app che mostrerà un mucchio di immagini in una presentazione. Quelle immagini faranno parte del bundle, quindi distribuito con l'app.

Tutte le immagini sono fotografie o fotografiche, ecc.

Ho letto che è preferibile utilizzare PNG come formato immagine, ma visto che la versione JPG sarà molto più piccola, preferisco usarla.

Esistono linee guida su quale formato utilizzare e in quale caso?

I PNG sono pixel perfetti (senza perdite) e richiedono pochissima energia aggiuntiva della CPU per essere visualizzati. Tuttavia, i file PNG di grandi dimensioni potrebbero richiedere più tempo per la lettura dalla memoria rispetto a formati di immagine più compressi e quindi essere più lenti da visualizzare.

I JPG sono più piccoli da memorizzare, ma con perdita (la quantità dipende dal livello di compressione) e per visualizzarli richiede un algoritmo di decodifica molto più complicato. Ma la compressione tipica e la qualità dell'immagine di solito sono abbastanza sufficienti per le foto.

Usa JPG per le foto e per qualsiasi cosa grande e PNG per qualsiasi cosa piccola e / o progettata per essere visualizzata "pixel perfect" (ad es. Piccole icone) o come parte di una sovrapposizione trasparente composta, ecc.

Apple ottimizza le immagini PNG incluse nel pacchetto dell'app per iPhone. Infatti, l'iPhone utilizza una codifica speciale in cui i byte di colore sono ottimizzati per l'hardware. XCode gestisce questa codifica speciale per te quando crei il tuo progetto. Quindi, vedi ulteriori vantaggi nell'utilizzo di PNG su un iPhone oltre alla considerazione delle dimensioni. Per questo motivo si consiglia vivamente di utilizzare i PNG per tutte le immagini che appaiono come parte dell'interfaccia (in una vista tabella, etichette, ecc.).

Per quanto riguarda la visualizzazione di un'immagine a schermo intero come una fotografia, potresti comunque trarre vantaggio dai PNG poiché non sono con perdita di dati e la qualità visiva dovrebbe essere migliore di un JPG per non parlare dell'utilizzo delle risorse con la decodifica dell'immagine. Potrebbe essere necessario ridurre la qualità dei tuoi JPG per vedere un reale vantaggio nella dimensione del file, ma poi stai visualizzando immagini non ottimali.

La dimensione del file è sicuramente un fattore, ma ci sono anche altre considerazioni in gioco quando si sceglie un formato di immagine.

C'è una cosa importante a cui pensare con i PNG. Se un PNG è incluso nella tua build Xcode, sarà ottimizzato per iOS. Questo si chiama PNG crush. Se il tuo PNG viene scaricato in fase di esecuzione, non verrà schiacciato. I PNG schiacciati vengono eseguiti più o meno come i JPG al 100%. I JPG di qualità inferiore funzionano meglio di quelli di qualità superiore. Quindi, dal punto di vista delle prestazioni dal più veloce al più lento, andrebbe JPG di bassa qualità, JPG di alta qualità, PNG Crushed, PNG.

Se devi scaricare PNG, dovresti considerare di schiacciare i PNG sul server prima del download.

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

Il blog Cocoanetics ha pubblicato un bel benchmark delle prestazioni iOS di JPG a vari livelli di qualità e PNG, con e senza schiacciamento.

Dalla sua conclusione:

Se hai assolutamente bisogno di un canale alfa o devi utilizzare i PNG, è consigliabile installare lo strumento pngcrush sul tuo server web e fare in modo che elabori tutti i tuoi PNG. In quasi tutti gli altri casi i JPEG di alta qualità combinano file di dimensioni inferiori (cioè trasmissione più veloce) con compressione e rendering più veloci.

Si scopre che i PNG sono ottimi per piccole immagini che useresti per gli elementi dell'interfaccia utente, ma non sono ragionevoli da usare per applicazioni a schermo intero come cataloghi o riviste. Qui vorresti scegliere una qualità di compressione tra il 60 e l'80% a seconda del materiale di origine.

In termini di visualizzazione di tutto, ti consigliamo di aggrapparti alle istanze di UIImage da cui hai disegnato una volta perché quelle contengono una versione non compressa del file memorizzata nella cache. E dove non fai la pausa visiva per far apparire un'immagine grande sullo schermo, dovrai forzare la decompressione per un paio di immagini in anticipo. Ma tieni presente che questi richiederanno grandi quantità di RAM e se esageri ciò potrebbe causare la chiusura della tua app. NSCache è un ottimo posto per posizionare le immagini utilizzate di frequente perché questo si occupa automaticamente di sfrattare le immagini quando la RAM diventa scarsa.

È un peccato che non abbiamo modo di sapere se un'immagine deve ancora essere decompressa o meno. Inoltre un'immagine potrebbe aver rimosso la versione non compressa senza informarci in merito a questo effetto. Potrebbe essere un buon radar da raccogliere sul sito di segnalazione dei bug di Apple. Ma fortunatamente l'accesso all'immagine come mostrato sopra non richiede tempo se l'immagine è già decompressa. Quindi potresti farlo non solo "just in time" ma anche "just in case".

Ho solo pensato di condividere un po 'di dati sulle prestazioni di decompressione ...

Sto realizzando alcuni prototipi di un visore a 360 gradi, un carosello in cui l'utente può ruotare attraverso una serie di foto scattate da diverse angolazioni, per dare l'impressione di poter ruotare agevolmente un oggetto.

Ho caricato i dati dell'immagine in un array di NSData per estrarre i / o file dall'equazione, ma creare NSImage al volo. Testando a un frame rate vicino al massimo (~ 25 fps) e guardando in Instruments, vedo che l'app è chiaramente legata alla CPU e c'è un aumento di circa il 10% nel carico della CPU che mostra ~ 275 kb di png contro ~ 75 kb di jpg.

Non posso dirlo con certezza, ma la mia ipotesi è che il limite della CPU provenga solo dall'esecuzione generale del programma e dallo spostamento di tutti i dati in memoria, ma la decompressione dell'immagine viene eseguita sulla GPU. In entrambi i casi, l'argomento delle prestazioni JPG rispetto a PNG sembra favorire JPG, specialmente quando vengono prese in considerazione le dimensioni dei file più piccole (e quindi le dimensioni inferiori degli oggetti in memoria almeno in alcune parti della catena).

Ovviamente ogni situazione è diversa, non c'è sostituto per i test ...

Ho riscontrato enormi differenze nelle prestazioni dell'animazione quando si utilizzano jpeg rispetto a png. Ad esempio, posizionare tre jpeg delle dimensioni di uno schermo uno accanto all'altro in un UIScrollView e scorrere orizzontalmente su un iPhone4 si traduce in un ritardo e in un'animazione a scatti completamente spiacevole. Con png non trasparenti delle stesse dimensioni lo scorrimento è fluido. Non uso mai jpeg, anche se l'immagine è grande.

Penso che se vuoi usare trasparente, non hai altra scelta tranne PNG. Ma se il tuo sfondo è già opaco, puoi usare JPG. Questa è l'unica differenza che posso vedere

'Usa JPEG per le foto' come menzionato nelle Linee guida per l'interfaccia umana nella sezione Produrre grafica nel formato appropriato.