Kiedy używać PNG lub JPG w programowaniu iPhone'a?


98

Mam aplikację, która wyświetla kilka obrazów w formie pokazu slajdów. Te obrazy będą częścią pakietu, więc będą dystrybuowane wraz z aplikacją.

Wszystkie obrazy są fotograficzne lub fotograficzne itp.

Czytałem, że lepiej jest używać PNG jako formatu obrazu, ale widząc, że wersja JPG będzie znacznie mniejsza, wolałbym tego użyć.

Czy są jakieś wskazówki, jakiego formatu użyć iw jakim przypadku?


Chciałem dodać, że wszystkie oryginalne obrazy są już w formacie JPG, jeśli to ma znaczenie.
Maverick

Odpowiedzi:


140

Pliki PNG są doskonałe co do piksela (bez strat) i wymagają bardzo niewielkiej dodatkowej energii procesora do wyświetlania. Jednak odczytanie dużych plików PNG z pamięci może zająć więcej czasu niż bardziej skompresowanych formatów obrazów, a zatem ich wyświetlanie jest wolniejsze.

JPG są mniejsze do przechowywania, ale stratne (ilość zależy od poziomu kompresji), a ich wyświetlenie wymaga znacznie bardziej skomplikowanego algorytmu dekodowania. Ale typowa kompresja i jakość obrazu są zwykle wystarczające dla zdjęć.

Użyj JPG do zdjęć i do wszystkiego, co duże, a PNG do wszystkiego, co małe i / lub zaprojektowane do wyświetlania „w pikselach” (np. Małe ikony) lub jako część złożonej przezroczystej nakładki itp.


1
Nie widziałem jeszcze żadnych danych na temat wydajności dekodowania JPEG, PNG i iPNG. Czasami bardziej skompresowany format jest lepszy ze względu na mniejszą liczbę operacji we / wy; Nie jestem pewien, jak szybki jest dysk flash iPhone'a. I zdecydowanie nie powiedziałbym, że dekompresja PNG wymaga „bardzo mało” energii; plik Other.artwork wydaje się być nieprzetworzonymi danymi bitmapowymi, prawdopodobnie dlatego, że obciążenie procesora / pamięci związane z dekompresją PNG jest zbyt duże dla powszechnie używanych komponentów interfejsu użytkownika.
tc.

2
W moim obecnym projekcie mamy bardzo duże pliki png z powodu wymogu przejrzystości. We / wy dysku znacznie przewyższa czas spędzony na dekodowaniu jpeg. Pamiętaj, że pliki PNG są również kompresowane, po prostu przy użyciu innego algorytmu.
John,

2
Pomyślałem, że dodam dodatkową wskazówkę dla tych, którzy chcą zmaksymalizować wydajność obrazu. Jeśli masz dobrze skompresowane pliki JPG, możesz załadować surowe dane JPG do obiektów NSData z wyprzedzeniem (być może w tablicy lub słowniku) i zbudować pliki JPG za pomocą UIImage: imageFromData, gdy chcesz je wyświetlić. Dane JPG mogą być 10-100x mniejsze niż dane obrazu bitmapowego, ale pozwala to na wczesne usunięcie (stosunkowo powolnej) części IO. Oczywiście uważaj na to, ile danych buforujesz / wstępnie ładujesz w ten sposób.
Nigel Flack

2
Znalazłem dane na temat czasów kompilacji: cocoanetics.com/2012/09/… Wygląda na to, że używanie png nie jest szybsze niż jpg;)
Maciej Kozieł

20

Apple optymalizuje obrazy PNG zawarte w pakiecie aplikacji na iPhone'a. W rzeczywistości iPhone używa specjalnego kodowania, w którym bajty kolorów są zoptymalizowane pod kątem sprzętu. XCode obsługuje to specjalne kodowanie podczas tworzenia projektu. Widzisz więc dodatkowe korzyści z używania PNG na iPhonie, inne niż ich rozmiar. Z tego powodu zdecydowanie zaleca się używanie PNG do wszelkich obrazów, które pojawiają się jako część interfejsu (w widoku tabeli, etykietach itp.).

Jeśli chodzi o wyświetlanie obrazu pełnoekranowego, takiego jak fotografia, nadal możesz czerpać korzyści z plików PNG, ponieważ są one bezstratne, a jakość wizualna powinna być lepsza niż w przypadku JPG, nie wspominając o zużyciu zasobów podczas dekodowania obrazu. Może być konieczne obniżenie jakości plików JPG, aby uzyskać rzeczywistą korzyść w rozmiarze pliku, ale wtedy wyświetlasz nieoptymalne obrazy.

Rozmiar pliku z pewnością ma znaczenie, ale przy wyborze formatu obrazu należy wziąć pod uwagę również inne kwestie.


5
W moim benchmarku optymalizacja Xcode faktycznie spowolniła pliki, prawdopodobnie dlatego, że wąskim gardłem jest dysk we / wy, a nie procesor.
Kornel

1
„Apple optymalizuje obrazy PNG, które są zawarte w pakiecie aplikacji na iPhone'a” - czy to oznacza, że ​​pliki PNG pobierane dynamicznie nie są zoptymalizowane?
Robert

1
Nie, pliki PNG pobierane dynamicznie nie są optymalizowane. Optymalizacja polega w zasadzie na zamianie kolejności bajtów z RGBA na BGRA, z czego korzysta wewnętrznie układ graficzny iPhone'a. Więcej informacji tutaj: graphicsoptimization.com/blog/?p=259
Nick Lockwood

11

W przypadku plików PNG należy pomyśleć o jednej ważnej rzeczy. Jeśli plik PNG jest dołączony do kompilacji Xcode, zostanie zoptymalizowany dla systemu iOS. Nazywa się to zgniataniem PNG. Jeśli plik PNG zostanie pobrany w czasie wykonywania, nie zostanie zniszczony. Zniszczone pliki PNG działają mniej więcej tak samo, jak 100% plików JPG. Pliki JPG niższej jakości działają lepiej niż pliki JPG o wyższej jakości. Więc z punktu widzenia wydajności od najszybszego do najwolniejszego JPG będzie niskiej jakości, wysokiej jakości JPG, zmiażdżony PNG, PNG.

Jeśli chcesz pobrać pliki PNG, powinieneś rozważyć zmiażdżenie plików PNG na serwerze przed pobraniem.

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


9

W Cocoanetics blogu opublikował piękny wzorzec wydajności iOS z JPG na różnych poziomach jakości i PNG, zi bez kruszenia.

Z jego wniosku:

Jeśli absolutnie potrzebujesz kanału alfa lub musisz korzystać z plików PNG, zaleca się zainstalowanie narzędzia pngcrush na serwerze WWW i przetworzenie wszystkich plików PNG. W prawie wszystkich innych przypadkach wysokiej jakości pliki JPEG łączą mniejsze rozmiary plików (tj. Szybszą transmisję) z szybszą kompresją i renderowaniem.

Okazuje się, że pliki PNG świetnie nadają się do małych obrazów, których używałbyś do elementów interfejsu użytkownika, ale nie są rozsądne w przypadku jakichkolwiek aplikacji pełnoekranowych, takich jak katalogi lub czasopisma. Tam chciałbyś wybrać jakość kompresji między 60 a 80% w zależności od materiału źródłowego.

Jeśli chodzi o wyświetlenie tego wszystkiego, będziesz chciał zawiesić się na instancjach UIImage, z których raz narysowałeś, ponieważ mają one buforowaną nieskompresowaną wersję pliku w nich. A jeśli nie masz wizualnej przerwy na pojawienie się dużego obrazu na ekranie, będziesz musiał wcześniej wymusić dekompresję dla kilku obrazów. Pamiętaj jednak, że będą one wymagały dużej ilości pamięci RAM, a jeśli przesadzisz, może to spowodować zamknięcie aplikacji. NSCache to świetne miejsce do umieszczania często używanych obrazów, ponieważ automatycznie usuwa obrazy, gdy brakuje pamięci RAM.

Szkoda, że ​​nie mamy żadnego sposobu, aby dowiedzieć się, czy obraz nadal wymaga dekompresji, czy nie. Obraz mógł również usunąć nieskompresowaną wersję bez informowania nas o tym. To może być dobry radar do zebrania w witrynie zgłaszania błędów firmy Apple. Ale na szczęście dostęp do obrazu, jak pokazano powyżej, nie zajmuje czasu, jeśli obraz jest już zdekompresowany. Możesz więc zrobić to nie tylko „na czas”, ale także „na wszelki wypadek”.


Dokładnie, a JPEGMini i ImageOptim sprawiają, że jpeg jest naprawdę mały!
electronix384128

7

Pomyślałem, że udostępnię trochę danych dotyczących wydajności dekompresji ...

Robię prototypy przeglądarki 360 stopni - karuzeli, w której użytkownik może przeglądać serię zdjęć wykonanych pod różnymi kątami, aby sprawiać wrażenie, jakby mógł płynnie obracać obiekt.

Załadowałem dane obrazu do tablicy NSData, aby wyjąć plik I / O z równania, ale utworzyć NSImage w locie. Testowanie przy niemal maksymalnej liczbie klatek na sekundę (~ 25 fps) i oglądanie w Instrumentach Widzę, że aplikacja jest wyraźnie związana z procesorem i występuje około 10% wzrost obciążenia procesora, pokazując ~ 275 kb png w porównaniu z ~ 75 kb jpg.

Nie mogę powiedzieć na pewno, ale przypuszczam, że limit procesora wynika tylko z ogólnego wykonywania programu i przenoszenia wszystkich danych w pamięci, ale dekompresja obrazu odbywa się na GPU. Tak czy inaczej, argument wydajności JPG vs. PNG wydaje się faworyzować JPG, zwłaszcza gdy brane są pod uwagę mniejsze rozmiary plików (a zatem mniejsze rozmiary obiektów w pamięci przynajmniej w niektórych częściach łańcucha).

Oczywiście każda sytuacja jest inna, nic nie zastąpi testów ...


2
GPU nie może dekompresować plików PNG. Format deflate, którego używa, nie jest odpowiedni dla rodzaju równoległości, jaką umożliwia GPU. Wydaje mi się, że dekodowanie JPG może być częściowo przyspieszane przez GPU, ponieważ wiąże się to z konwersją przestrzeni kolorów.
Kornel

5

Znalazłem ogromne różnice w wydajności animacji podczas korzystania z plików JPEG i PNG. Na przykład umieszczenie trzech plików JPEG wielkości ekranu obok siebie w UIScrollView i przewijanie w poziomie na telefonie iPhone4 powoduje opóźnienie i nieprzyjemną, gwałtowną animację. W przypadku nieprzezroczystych plików PNG o tych samych wymiarach przewijanie jest płynne. Nigdy nie używam jpegów, nawet jeśli obraz jest duży.


1

Myślę, że jeśli chcesz użyć przezroczystości, nie masz wyboru poza PNG. Ale jeśli twoje tło jest już nieprzezroczyste, możesz użyć JPG. To jedyna różnica, jaką widzę


3
Nie dotyczy to kwestii wydajności JPG i PNG.
daveMac

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.