Quando utilizzare PNG o JPG nello sviluppo di iPhone?


98

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?


Volevo aggiungere che le immagini originali sono già tutte in formato JPG se questo fa la differenza.
Maverick

Risposte:


140

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.


1
Devo ancora vedere dati sulle prestazioni di decodifica JPEG vs PNG vs iPNG. A volte il formato più compresso è migliore a causa del ridotto I / O richiesto; Non sono sicuro di quanto sia veloce l'unità flash dell'iPhone. E sicuramente non direi che la decompressione PNG richiede "pochissima" energia; il file Other.artwork sembra essere dati bitmap grezzi, presumibilmente perché l'overhead di CPU / memoria della decompressione PNG è troppo per i componenti dell'interfaccia utente di uso comune.
tc.

2
Nel mio progetto attuale, abbiamo file png molto grandi a causa di un requisito di trasparenza. L'IO del disco supera di gran lunga il tempo impiegato per decodificare un jpeg. Tieni presente che anche i PNG vengono compressi, utilizzando solo un algoritmo diverso.
John

2
Ho pensato di aggiungere un suggerimento supplementare per coloro che cercano di massimizzare le prestazioni dell'immagine. SE hai JPG ben compressi puoi caricare i dati JPG grezzi in oggetti NSData in anticipo (magari in un array o in un dizionario) e costruire i JPG usando UIImage: imageFromData quando vuoi visualizzare. I dati JPG possono essere 10-100 volte più piccoli dei dati dell'immagine bitmap, ma ti consente di rimuovere la parte IO (relativamente lenta) in anticipo. Ovviamente fai attenzione a quanti dati memorizzi / precarichi in questo modo.
Nigel Flack

2
Ho trovato alcuni dati sui tempi di compersione: cocoanetics.com/2012/09/… Sembra che l'uso di png non sia più veloce di jpg;)
Maciej Kozieł

20

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.


5
Nel mio benchmark l' ottimizzazione di Xcode ha effettivamente reso i file più lenti, probabilmente perché l'I / O del disco, non la CPU, è il collo di bottiglia.
Kornel

1
"Apple ottimizza le immagini PNG incluse nel tuo app bundle per iPhone" - Significa che i PNG scaricati dinamicamente non sono ottimizzati?
Robert

1
No, i PNG scaricati dinamicamente non sono ottimizzati. L'ottimizzazione è fondamentalmente solo lo scambio dell'ordine dei byte da RGBA a BGRA, che è ciò che il chip grafico dell'iPhone utilizza internamente. Maggiori informazioni qui: graphicsoptimization.com/blog/?p=259
Nick Lockwood

11

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/


9

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


Esatto, e JPEGMini e ImageOptim rendono i jpeg davvero piccoli!
electronix384128

7

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


2
La GPU non può decomprimere i PNG. Il formato deflate che utilizza non è adatto al tipo di parallelizzazione abilitato dalla GPU. Immagino che la decodifica JPG possa essere parzialmente accelerata dalla GPU, poiché è coinvolta la conversione dello spazio colore.
Kornel

5

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.


1

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


3
Questo non risolve le considerazioni sulle prestazioni di JPG e PNG.
daveMac

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.