Kapan menggunakan PNG atau JPG dalam pengembangan iPhone?


98

Saya memiliki aplikasi yang akan menampilkan banyak gambar dalam tayangan slide. Gambar-gambar itu akan menjadi bagian dari bundel, sehingga didistribusikan dengan aplikasi.

Semua gambar adalah foto atau fotografi, dll.

Saya pernah membaca bahwa lebih suka menggunakan PNG sebagai format gambar, tetapi melihat bahwa versi JPG akan jauh lebih kecil, saya lebih suka menggunakannya.

Apakah ada pedoman format mana yang digunakan dan dalam kasus apa?


Saya ingin menambahkan bahwa semua gambar asli sudah dalam format JPG jika itu membuat perbedaan.
Maverick

Jawaban:


140

PNG adalah piksel sempurna (non-lossy), dan membutuhkan sedikit energi CPU ekstra untuk ditampilkan. Namun, PNG besar mungkin membutuhkan waktu lebih lama untuk dibaca dari penyimpanan daripada format gambar yang lebih terkompresi, dan karenanya lebih lambat untuk ditampilkan.

JPG lebih kecil untuk disimpan, tetapi lossy (jumlah tergantung pada tingkat kompresi), dan untuk menampilkannya membutuhkan algoritma decoding yang jauh lebih rumit. Tetapi kompresi tipikal dan kualitas gambar biasanya cukup memadai untuk foto.

Gunakan JPG untuk foto dan untuk apa pun yang besar, dan PNG untuk apa pun yang kecil dan / atau dirancang untuk ditampilkan "piksel sempurna" (mis. Ikon kecil) atau sebagai bagian dari hamparan transparan gabungan, dll.


1
Saya belum melihat data apa pun tentang kinerja dekode JPEG vs PNG vs iPNG. Terkadang format yang lebih dikompresi lebih baik karena diperlukan I / O yang lebih sedikit; Saya tidak yakin seberapa cepat flash drive iPhone. Dan saya pasti tidak akan mengatakan dekompresi PNG membutuhkan energi "sangat sedikit"; file Other.artwork tampaknya merupakan data bitmap mentah, mungkin karena overhead CPU / memori dekompresi PNG terlalu banyak untuk komponen UI yang umum digunakan.
tc.

2
Pada proyek saya saat ini, kami memiliki file png yang sangat besar karena persyaratan transparansi. IO disk jauh melebihi waktu yang dihabiskan untuk mendekode jpeg. Ingatlah bahwa PNG juga dikompresi, hanya menggunakan algoritme yang berbeda.
Yohanes

2
Figured, saya akan menambahkan satu tip tambahan bagi mereka yang mencoba memaksimalkan kinerja gambar. JIKA Anda memiliki JPG yang dikompresi dengan baik, Anda dapat memuat data JPG mentah ke dalam objek NSData terlebih dahulu (mungkin dalam array atau kamus), dan membuat JPG menggunakan UIImage: imageFromData saat Anda ingin menampilkannya. Data JPG bisa 10-100x lebih kecil dari data gambar bitmap, tetapi ini memungkinkan Anda untuk mendapatkan bagian IO (yang relatif lambat) lebih awal. Jelas berhati-hatilah tentang berapa banyak data yang Anda cache / preload dengan cara ini.
Nigel Flack

2
Saya telah menemukan beberapa data tentang waktu kompersi: cocoanetics.com/2012/09/… Tampaknya, menggunakan png tidak lebih cepat dari jpg;)
Maciej Kozieł

20

Apple mengoptimalkan gambar PNG yang disertakan dalam bundel aplikasi iPhone Anda. Faktanya, iPhone menggunakan pengkodean khusus di mana byte warna dioptimalkan untuk perangkat keras. XCode menangani pengkodean khusus ini untuk Anda ketika Anda membangun proyek Anda. Jadi, Anda memang melihat manfaat tambahan menggunakan PNG di iPhone selain pertimbangan ukurannya. Untuk alasan ini, sangat disarankan untuk menggunakan PNG untuk gambar apa pun yang muncul sebagai bagian dari antarmuka (dalam tampilan tabel, label, dll).

Sedangkan untuk menampilkan gambar layar penuh seperti foto, Anda mungkin masih mendapatkan keuntungan dengan PNG karena tidak merugikan dan kualitas visual harus lebih baik daripada JPG belum lagi penggunaan sumber daya dengan decoding gambar. Anda mungkin perlu menurunkan kualitas JPG Anda untuk melihat manfaat nyata dalam ukuran file tetapi kemudian Anda menampilkan gambar yang tidak optimal.

Ukuran file tentunya merupakan faktor tetapi ada pertimbangan lain yang berperan juga saat memilih format gambar.


5
Dalam pengoptimalan Xcode benchmark saya sebenarnya membuat file lebih lambat, kemungkinan karena disk I / O, bukan CPU yang menjadi penghambat.
Kornel

1
"Apple mengoptimalkan gambar PNG yang disertakan dalam paket aplikasi iPhone Anda" - Apakah ini berarti PNG yang diunduh secara dinamis tidak dioptimalkan?
Robert

1
Tidak, PNG yang diunduh secara dinamis tidak dioptimalkan. Pengoptimalan pada dasarnya hanya menukar urutan byte dari RGBA ke BGRA, yang digunakan oleh chip grafis iPhone secara internal. Info lebih lanjut di sini: graphicsoptimization.com/blog/?p=259
Nick Lockwood

11

Ada satu hal penting yang harus dipikirkan dengan PNG. Jika PNG disertakan dalam Xcode build Anda, itu akan dioptimalkan untuk iOS. Ini disebut naksir PNG. Jika PNG Anda diunduh pada saat dijalankan, itu tidak akan dihancurkan. PNG yang dihancurkan berjalan hampir sama dengan 100% JPG. JPG kualitas rendah berjalan lebih baik daripada JPG kualitas lebih tinggi. Jadi dari sudut pandang kinerja dari yang tercepat hingga yang paling lambat akan menghasilkan JPG berkualitas rendah, JPG berkualitas tinggi, PNG Hancur, PNG.

Jika Anda perlu mengunduh PNG, Anda harus mempertimbangkan untuk menghancurkan PNG di server sebelum mengunduh.

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


9

The Cocoanetics blog yang diterbitkan patokan kinerja iOS bagus dari JPG pada berbagai tingkat kualitas, dan PNG, dengan dan tanpa menghancurkan.

Dari kesimpulannya:

Jika Anda benar-benar membutuhkan saluran alfa atau harus menggunakan PNG, maka disarankan untuk menginstal alat pngcrush di server web Anda dan membuatnya memproses semua PNG Anda. Dalam hampir semua kasus lain, JPEG berkualitas tinggi menggabungkan ukuran file yang lebih kecil (yaitu transmisi lebih cepat) dengan kompresi dan rendering yang lebih cepat.

Ternyata PNG sangat bagus untuk gambar kecil yang akan Anda gunakan untuk elemen UI, tetapi tidak wajar digunakan untuk aplikasi layar penuh seperti katalog atau majalah. Di sana Anda akan ingin memilih kualitas kompresi antara 60 dan 80% tergantung pada bahan sumber Anda.

Dalam hal menampilkan semuanya, Anda akan ingin menggunakan instance UIImage yang telah Anda gambar sekali karena mereka memiliki versi file yang tidak terkompresi dalam cache di dalamnya. Dan jika Anda tidak melakukan jeda visual agar gambar besar muncul di layar, Anda harus memaksa dekompresi untuk beberapa gambar terlebih dahulu. Namun perlu diingat bahwa ini akan memakan banyak RAM dan jika Anda melakukannya secara berlebihan, hal itu dapat menyebabkan aplikasi Anda dihentikan. NSCache adalah tempat yang tepat untuk menempatkan gambar yang sering digunakan karena ini secara otomatis menangani pengusiran gambar saat RAM menjadi langka.

Sangat disayangkan kita tidak memiliki cara untuk mengetahui apakah suatu gambar masih perlu di-decompress atau tidak. Juga gambar mungkin telah mengeluarkan versi yang tidak dikompresi tanpa memberi tahu kami tentang efek ini. Itu mungkin Radar yang bagus untuk diangkat di situs pelaporan bug Apple. Tapi untungnya mengakses gambar seperti yang ditunjukkan di atas tidak membutuhkan waktu jika gambar sudah didekompresi. Jadi Anda bisa melakukannya tidak hanya "tepat waktu" tetapi juga "untuk berjaga-jaga".


Tepat, dan JPEGMini dan ImageOptim membuat jpeg sangat kecil!
electronix384128

7

Hanya berpikir saya akan membagikan sedikit data kinerja dekompresi ...

Saya melakukan beberapa prototipe penampil 360 derajat - korsel tempat pengguna dapat memutar melalui serangkaian foto yang diambil dari berbagai sudut, untuk memberikan kesan dapat memutar objek dengan mulus.

Saya telah memuat data gambar ke dalam array NSData untuk mengambil i / o file dari persamaan, tetapi membuat NSImage dengan cepat. Menguji pada frekuensi gambar mendekati maks (~ 25 fps) dan menonton di Instrumen Saya melihat aplikasi ini jelas terikat dengan CPU dan ada peningkatan sekitar 10% dalam beban CPU yang menunjukkan ~ 275 kb png vs ~ 75 kb jpg.

Saya tidak bisa mengatakan dengan pasti tetapi tebakan saya adalah batas CPU hanya dari eksekusi program umum dan memindahkan semua data di sekitar memori, tetapi dekompresi gambar itu dilakukan pada GPU. Either way dan argumen kinerja JPG vs. PNG tampaknya mendukung JPG, terutama ketika ukuran file yang lebih kecil (dan karena itu ukuran objek yang lebih kecil dalam memori setidaknya di beberapa bagian rantai) dipertimbangkan.

Tentu saja setiap situasi berbeda, tidak ada pengganti untuk pengujian ...


2
GPU tidak dapat mendekompresi PNG. Format deflate yang digunakan tidak sesuai untuk jenis paralelisasi yang diaktifkan GPU. Saya kira decoding JPG dapat dipercepat sebagian dengan GPU, karena ada konversi ruang warna yang terlibat.
Kornel

5

Saya menemukan perbedaan besar dalam performa animasi saat menggunakan jpegs vs png. Misalnya menempatkan tiga jpeg seukuran layar berdampingan dalam UIScrollView dan menggulir secara horizontal pada iPhone4 menghasilkan kelambatan dan animasi tersentak-sentak yang tidak menyenangkan. Dengan png non-transparan dengan dimensi yang sama, pengguliran menjadi mulus. Saya tidak pernah menggunakan jpegs, meskipun gambarnya besar.


1

Saya rasa jika Anda ingin menggunakan transparan, Anda tidak punya pilihan selain PNG. Tapi, jika background Anda sudah buram, maka Anda bisa menggunakan JPG. Itulah satu-satunya perbedaan yang bisa saya lihat


3
Ini tidak mengatasi pertimbangan kinerja apa pun dari JPG vs PNG.
daveMac

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.