İPhone geliştirmede PNG veya JPG ne zaman kullanılır?


98

Bir slayt gösterisinde bir grup resmi gösterecek bir uygulamam var. Bu resimler paketin bir parçası olacak ve böylece uygulama ile birlikte dağıtılacaktır.

Tüm görüntüler fotoğraf veya fotoğraf vb.

Görüntü formatı olarak PNG'nin kullanılmasının tercih edildiğini okudum, ancak JPG sürümünün çok daha küçük olacağını görünce, bunu kullanmayı tercih ederim.

Hangi formatta ve hangi durumda kullanılacağına dair herhangi bir kılavuz var mı?


Herhangi bir fark yaratıyorsa, orijinal resimlerin hepsinin zaten JPG formatında olduğunu eklemek istedim.
Maverick

Yanıtlar:


140

PNG'ler piksel mükemmeldir (kayıpsız) ve görüntülenmesi için çok az ekstra CPU enerjisi gerektirir. Ancak, büyük PNG'lerin depolamadan okunması daha sıkıştırılmış görüntü formatlarına göre daha uzun sürebilir ve bu nedenle görüntülenmesi daha yavaş olabilir.

JPG'lerin depolanması daha küçüktür, ancak kayıplıdır (miktarı sıkıştırma seviyesine bağlıdır) ve bunları görüntülemek için çok daha karmaşık bir kod çözme algoritması gerekir. Ancak tipik sıkıştırma ve görüntü kalitesi, fotoğraflar için genellikle oldukça yeterlidir.

Fotoğraflar ve büyük her şey için JPG'leri ve küçük ve / veya "piksel mükemmel" (örneğin küçük simgeler) veya birleşik şeffaf kaplamanın bir parçası olarak görüntülenmek üzere tasarlanmış herhangi bir şey için PNG kullanın.


1
Henüz JPEG, PNG ve iPNG kod çözme performansı ile ilgili herhangi bir veri görmedim. Bazen daha sıkıştırılmış format, daha az G / Ç gerektirdiği için daha iyidir; İPhone'un flash sürücüsünün ne kadar hızlı olduğundan emin değilim. Ve kesinlikle PNG dekompresyonunun "çok az" enerji gerektirdiğini söylemem; Other.artwork dosyası ham bitmap verisi gibi görünür, bunun nedeni muhtemelen PNG açmanın CPU / bellek yükünün yaygın olarak kullanılan UI bileşenleri için çok fazla olmasıdır.
tc.

2
Şu anki projemde, şeffaflık gereksinimi nedeniyle çok büyük png dosyalarımız var. Disk GÇ'si, bir jpeg kodunu çözmek için harcanan zamandan büyük ölçüde ağır basar. PNG'lerin de yalnızca farklı bir algoritma kullanılarak sıkıştırıldığını unutmayın.
John

2
Görüntü performansını en üst düzeye çıkarmaya çalışanlar için bir ek ipucu ekleyeceğimi düşündüm. İyi sıkıştırılmış JPG'leriniz varsa, ham JPG verilerini önceden NSData nesnelerine yükleyebilir (belki bir dizi veya sözlükte) ve görüntülemek istediğinizde UIImage: imageFromData'yı kullanarak JPG'ler oluşturabilirsiniz. JPG verileri, bitmap görüntü verilerinden 10-100x daha küçük olabilir, ancak (nispeten yavaş) GÇ bölümünü erken yoldan çekmenize olanak tanır. Açıkçası, bu şekilde ne kadar veriyi önbelleğe aldığınız / önceden yüklediğiniz konusunda dikkatli olun.
Nigel Flack

2
Derleme süreleri hakkında bazı veriler buldum: cocoanetics.com/2012/09/… Görünüşe göre png kullanmak jpg'den daha hızlı değil;)
Maciej Kozieł

20

Apple, iPhone uygulama paketinizde bulunan PNG görüntülerini optimize eder. Aslında iPhone, renk baytlarının donanım için optimize edildiği özel bir kodlama kullanıyor. XCode, projenizi oluşturduğunuzda bu özel kodlamayı sizin için yönetir. Dolayısıyla, PNG'leri bir iPhone'da kullanmanın, boyutlarının dikkate alınması dışında ek faydaları görüyorsunuz. Bu nedenle, arayüzün bir parçası olarak görünen tüm resimler için (tablo görünümünde, etiketlerde vb.) PNG'lerin kullanılması kesinlikle önerilir.

Fotoğraf gibi tam ekran bir görüntüyü göstermeye gelince, kayıpsız olduklarından ve görsel kalitenin görüntünün kodunu çözerken kaynak kullanımından bahsetmemek için JPG'den daha iyi olması gerektiğinden yine de PNG'lerden yararlanabilirsiniz. Dosya boyutunda gerçek bir fayda görmek için JPG'lerinizin kalitesini düşürmeniz gerekebilir, ancak bu durumda optimal olmayan görüntüleri görüntülüyorsunuz.

Dosya boyutu kesinlikle bir faktördür, ancak bir görüntü formatı seçerken oyunda başka hususlar da vardır.


5
Karşılaştırmalı değerlendirmemde, Xcode optimizasyonu aslında dosyaları daha yavaş hale getirdi, çünkü büyük olasılıkla CPU değil disk G / Ç darboğazdır.
Kornel

1
"Apple, iPhone uygulama paketinizde bulunan PNG görüntülerini optimize eder" - Bu, dinamik olarak indirilen PNG'nin optimize edilmediği anlamına mı geliyor?
Robert

1
Hayır, dinamik olarak indirilen PNG'ler optimize edilmez. Optimizasyon, temelde yalnızca bayt sırasını RGBA'dan BGRA'ya değiştirmektir, bu da iPhone grafik yongasının dahili olarak kullandığı şeydir. Daha fazla bilgi burada: graphicsoptimization.com/blog/?p=259
Nick Lockwood

11

PNG'lerle ilgili düşünülmesi gereken önemli bir şey var. Xcode derlemenize bir PNG dahil edilmişse, iOS için optimize edilecektir. Buna PNG parçalama denir. PNG'niz çalışma zamanında indirilirse ezilmeyecektir. Ezilmiş PNG'ler yaklaşık% 100 JPG'lerle aynı şekilde çalışır. Düşük kaliteli JPG'ler, yüksek kaliteli JPG'lerden daha iyi çalışır. Dolayısıyla, performans açısından en hızlıdan en yavaşa, düşük kaliteli JPG, yüksek kaliteli JPG, PNG Ezilmiş, PNG olur.

PNG'leri indirmeniz gerekiyorsa, indirmeden önce PNG'leri sunucuda ezmeyi düşünmelisiniz.

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


9

Cocoanetics güzel iOS performans kriter yayınlanan blog ile ve ezme olmadan çeşitli kalite seviyeleri ve PNG de JPG.

Sonuca göre:

Kesinlikle bir alfa kanalına ihtiyacınız varsa veya PNG'lerle gitmeniz gerekiyorsa, pngcrush aracını web sunucunuza yüklemeniz ve tüm PNG'lerinizi işlemesini sağlamanız önerilir. Hemen hemen tüm diğer durumlarda, yüksek kaliteli JPEG'ler daha küçük dosya boyutlarını (yani daha hızlı aktarım) daha hızlı sıkıştırma ve oluşturma ile birleştirir.

PNG'lerin kullanıcı arayüzü öğeleri için kullanacağınız küçük resimler için harika olduğu, ancak kataloglar veya dergiler gibi tam ekran uygulamalar için kullanımları makul olmadığı ortaya çıktı. Orada, kaynak materyalinize bağlı olarak% 60 ile 80 arasında bir sıkıştırma kalitesi seçmek istersiniz.

Hepsini gösterme açısından, bir kez çizdiğiniz UIImage örneklerine takılmak isteyeceksiniz çünkü bunların içinde dosyanın önbelleğe alınmış sıkıştırılmamış bir sürümü var. Ve ekranda büyük bir görüntünün görünmesi için görsel duraklama yapmadığınız yerlerde, önceden birkaç görüntü için açmayı zorlamanız gerekecektir. Ancak bunların büyük miktarda RAM alacağını ve aşırıya kaçıyorsanız, uygulamanızın sonlandırılmasına neden olabileceğini unutmayın. NSCache, sık kullanılan görüntüleri yerleştirmek için harika bir yerdir çünkü bu, RAM azaldığında görüntüleri otomatik olarak ortadan kaldırır.

Bir görüntünün hala sıkıştırmaya ihtiyacı olup olmadığını bilmenin hiçbir yolu olmaması talihsiz bir durumdur. Ayrıca bir görüntü, bize bu etkiyle ilgili bilgi vermeden sıkıştırılmamış sürümü çıkarmış olabilir. Bu, Apple'ın hata raporlama sitesinde yükseltmek için iyi bir Radar olabilir. Ancak neyse ki yukarıda gösterildiği gibi görüntüye erişmek, görüntü zaten açılmışsa hiç zaman almaz. Yani bunu sadece "tam zamanında" değil, aynı zamanda "her ihtimale karşı" da yapabilirsiniz.


Aynen, JPEGMini ve ImageOptim jpeg'leri gerçekten küçük yapar!
Electronix384128

7

Biraz dekompresyon performans verisi paylaşacağımı düşündüm ...

360 derecelik bir görüntüleyicinin bazı prototiplerini yapıyorum - kullanıcının bir nesneyi sorunsuz bir şekilde döndürebildiği izlenimini vermek için farklı açılardan çekilmiş bir dizi fotoğrafı döndürebildiği bir atlıkarınca.

Denklemden dosya i / o almak için görüntü verilerini bir NSData dizisine yükledim, ancak NSImage'leri anında oluşturdum. Maksimum kare hızında (~ 25 fps) test etme ve Enstrümanlar'da izleme Uygulamanın açıkça CPU'ya bağlı olduğunu görüyorum ve CPU yükünde ~ 275 kb png'ye karşılık ~ 75 kb jpg'leri gösteren yaklaşık% 10'luk bir artış var.

Kesin olarak söyleyemem, ancak benim tahminim CPU sınırının sadece genel program yürütmesinden ve tüm verilerin bellekte taşınmasından kaynaklandığı, ancak bu görüntü açma işlemi GPU'da yapıldı. Her iki durumda da JPG'ye karşı PNG performans argümanı, özellikle daha küçük dosya boyutları (ve dolayısıyla en azından zincirin bazı bölümlerinde bellekte daha küçük nesneler boyutları) dikkate alındığında JPG'yi tercih ediyor gibi görünüyor.

Elbette her durum farklıdır, testin yerini hiçbir şey tutamaz ...


2
GPU, PNG'leri açamaz. Kullandığı deflate biçimi, GPU'nun sağladığı paralelleştirme türü için uygun değildir. Renk alanı dönüşümü söz konusu olduğu için JPG kod çözme kısmen GPU hızlandırmalı olabilir.
Kornel

5

Jpegs ve png kullanırken animasyon performansında büyük farklar buldum. Örneğin, bir UIScrollView'da üç ekran boyutunda jpeg'i yan yana yerleştirmek ve bir iPhone4'te yatay olarak kaydırmak, gecikmeye ve tamamen rahatsız edici bir animasyona neden olur. Aynı boyutlardaki saydam olmayan pngs ile kaydırma düzgündür. Resim büyük olsa bile asla jpeg kullanmıyorum.


1

Şeffaf kullanmak istiyorsanız, PNG dışında seçeneğiniz olmadığını düşünüyorum. Ancak, arka planınız zaten opaksa, JPG kullanabilirsiniz. Görebildiğim tek fark bu


3
Bu, JPG'ye karşı PNG'nin herhangi bir performans konusunu ele almaz.
daveMac

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.