W poprzednim artykule testowałem finalne grafiki, które zostały już raz skompresowane przez witrynę – ImgZilla pozwoliła zaoszczędzić kolejne 46,8%. Tym razem przechodzimy na drugą skrajność: oryginalne zdjęcia wprost z aparatu / telefonu, nigdy nieprzetwarzane przez żadne narzędzie. Podobnie jak wcześniej, nie odwołuję się do żadnych statystyk branżowych – prezentuję wyniki jednego prawdziwego testu wraz z metodą porównania.
1. Obiekt testu: prawdziwe „oryginalne obrazy”
Próba z poprzedniego artykułu miała pewne założenie – te obrazy przeszły już jedną kompresję podczas wgrywania na witrynę, więc nie były to surowe zdjęcia. Tym razem rezygnuję z tego założenia i testuję JPEG-i eksportowane bezpośrednio z aparatu / telefonu, bez udziału narzędzi kompresujących, bez dodatkowego zapisu i bez ponownego kodowania.
Wielkość próbki: 32 188 JPEG-ów, znajdujących się w 16 podkatalogach (bucket), bez selekcji ani czyszczenia na potrzeby testu.
Całkowity rozmiar tych plików: 99,9 GB (ok. 93 GiB).
Parametry zdjęć też są typowe – wszystkie są w standardowych rozdzielczościach wyjściowych aparatów / telefonów:
| Rozdzielczość | Liczba zdjęć | Udział |
|---|---|---|
| 4000×3000 (12 MP) | 19 867 | 61,7% |
| 4032×3024 (12 MP, iPhone) | 3 529 | 11,0% |
| 3456×4608 (16 MP, pion) | 2 631 | 8,2% |
| Inne (3120×4208, 4608×3456, 2448×3264…) | 6 161 | 19,1% |
Średnio 11,5 megapiksela i 2,96 MB na zdjęcie; największe pojedyncze zdjęcie ma 18,3 MB i 30 megapikseli. To właśnie zdjęcia z telefonu lub aparatu, którymi nigdy się nie zajmowałeś.
Pytanie brzmi: ile z takiego „nietkniętego” przez nikogo oryginału jest w stanie wycisnąć specjalistyczne narzędzie do kompresji?
2. Wynik: oszczędność 76,8% – 99,9 GB zamienia się w 23,1 GB
Wszystkie 32 188 zdjęć zostało skompresowanych jedno po drugim „w miejscu” – nazwy plików, struktura katalogów i rozdzielczości pozostały bez zmian:
| Rozmiar | W porównaniu z oryginałem | |
|---|---|---|
| Oryginalne zdjęcia z aparatu | 99,9 GB | — |
| Po kompresji przez ImgZillę | 23,1 GB | -76,8% |
Jedna kompresja pozwala zaoszczędzić ok. 76,7 GB, a po kompresji zostaje mniej niż jedna czwarta pierwotnej objętości. Względne ścieżki, nazwy plików i hierarchia katalogów wszystkich 32 188 plików są identyczne przed i po kompresji – to można zweryfikować na podstawie rzeczywistych danych.
Porównanie z poprzednim artykułem:
| Partia testowa | Źródło obrazów | Stopień kompresji ImgZilli |
|---|---|---|
| Poprzedni artykuł (4624 zdjęcia) | Finalne grafiki po jednokrotnej kompresji na stronie | -46,8% |
| Ten artykuł (32 188 zdjęć) | Oryginalne zdjęcia prosto z aparatu / telefonu | -76,8% |
Wniosek jest prosty: im bardziej surowe i nieprzetworzone zdjęcia, tym większy potencjał kompresji. Kompresja podczas wgrywania do serwisu pochłonęła już część nadmiarowości, więc dla ImgZilli zostało 46,8% do odzyskania. W zdjęciach prosto z aparatu ta nadmiarowość nie została naruszona, więc ImgZilla jest w stanie za jednym razem usunąć 76,8%.
3. Dlaczego oryginalne zdjęcia z aparatu można skompresować tak bardzo?
Aparaty i telefony podczas eksportu JPEG stawiają na pierwszym miejscu zasadę „nie trać szczegółów”, a nie „plik możliwie najmniejszy”. Dlatego w JPEG-ach prosto z aparatu jest mnóstwo bajtów, które nie wnoszą nic do jakości obrazu:
- Konserwatywny poziom jakości: JPEG-i z aparatu zwykle używają tabel kwantyzacji odpowiadających jakości 90–98, przy której ludzkie oko już nie dostrzega różnic względem wyższej jakości, a liczba bajtów jest dużo większa.
- Uniwersalne, nieoptymalne kodowanie entropijne: kodowanie „na żywo” korzysta ze standardowych, stałych tablic Huffmana; nie jest optymalizowane dla każdego zdjęcia z osobna, nie stosuje się też kwantyzacji trellis ani optymalizacji skanowania progresywnego.
- Mnóstwo danych dodatkowych: EXIF, GPS, pola prywatne producenta, osadzona miniatura podglądu całego zdjęcia, profile kolorów – to wszystko potrafi zająć kilkadziesiąt do kilkuset kilobajtów.
ImgZilla wykonuje na JPEG-ach rekompresję wizualnie bezstratną: dzięki lepszej strategii kodowania poprawia kodowanie entropijne, ustawia parametry kwantyzacji na poziomie nierozróżnialnym dla ludzkiego oka i usuwa nadmiarowe dane dodatkowe. Na poziomie pikseli zmiany faktycznie występują, ale parametry są dobrane tak, by różnic praktycznie nie było widać, dlatego w przypadku materiałów o dużej redundancji, takich jak „oryginalne zdjęcia”, można za jednym razem usunąć trzy czwarte objętości.
Należy jasno rozróżnić dwa często mylone pojęcia: „wizualnie bezstratny” to nie to samo co „bezstratny”. Bezstratność (piksele bez żadnych zmian) dotyczy tylko PNG (oxipng) i SVG; JPEG, WebP, AVIF, HEIC i GIF to z założenia rekompresja stratna – po prostu parametry kompresji są ustawione w zakresie wizualnie bezstratnym. Nie musisz mi wierzyć na słowo: ImgZilla ma wbudowane okno porównawcze, z podziałem ekranu na przed i po oraz skalowaniem do rzeczywistych rozmiarów, więc możesz porównać piksel po pikselu i sam ocenić.
4. Analiza szczegółowa: stopień kompresji w podziale na pliki, rozmiar w pikselach, przypadki skrajne
Podane wcześniej 76,8% to porównanie całkowitych rozmiarów całej partii – 32 188 zdjęć. Po zejściu do poziomu pojedynczych plików widać jeszcze kilka konkretnych rzeczy.
Większość zdjęć jest mniejsza o 70–90%
Każde z 32 188 zdjęć zostało sparowane jako „bajty przed kompresją → bajty po kompresji”; pliki pogrupowano według odsetka oszczędności:
| Zakres oszczędności | Liczba zdjęć | Udział |
|---|---|---|
| 90%–100% | 866 | 2,7% |
| 80%–90% | 11 375 | 35,3% |
| 70%–80% | 15 244 | 47,4% |
| 60%–70% | 3 349 | 10,4% |
| 50%–60% | 398 | 1,2% |
| Poniżej 50% | 956 | 3,0% |
82,7% zdjęć dało oszczędność 70–90%. Średnia arytmetyczna oszczędności liczona dla pojedynczych plików wynosi 76,6%, co niemal idealnie pokrywa się z 76,8% uzyskanymi z porównania sumarycznej liczby bajtów – oznacza to, że w tej partii pliki o dużym i małym stopniu kompresji są dość równomiernie rozłożone pod względem udziału w objętości, a wynik nie jest zaburzony przez kilka wyjątkowo dużych plików.
Patrząc na kwantyle: ponad połowa zdjęć pozwala zaoszczędzić co najmniej 77%; nawet najsłabsze 10% zdjęć pod tym względem wciąż daje oszczędność około 68%; tylko około 1% zdjęć (p99) ma oszczędność poniżej 40%.
Rozmiar pikseli: ani jeden piksel bez zmian
Sprawdziłem zmiany rozdzielczości dla wszystkich 32 188 zdjęć: dimensions_changed jest równe false dla wszystkich plików – w 100% zachowano oryginalną rozdzielczość. ImgZilla nie skaluje ani nie przycina, więc zaoszczędzone 76,7 GB pochodzi wyłącznie z ponownego kodowania, a nie z pozbywania się pikseli. To ta część definicji „kompresji w miejscu”, o której łatwo zapomnieć: nie tylko nazwy plików i ścieżki pozostają bez zmian, ale także rozdzielczość.
Kilka przypadków skrajnych
| Typ | Oryginał | Po kompresji | Oszczędność |
|---|---|---|---|
| Najwyższy stopień kompresji | 3,55 MB (4000×3000) | 100 KB | 97,2% |
| Największa oszczędność na pojedynczym pliku | 17,90 MB (4000×3000) | 1,13 MB | 16,8 MB |
| Najsłabszy wynik | 70 KB (1242×1242) | 68,8 KB | 2,1% |
Pliki z najwyższym stopniem kompresji (oszczędność ponad 95%) to zwykle zdjęcia, w których aparat zastosował bardzo wysokie parametry jakości i zebrał pełne metadane; najsłabszy wynik dotyczy zdjęć, które już były małe i wcześniej przetworzone. Średnio każde zdjęcie zmniejszyło się o 2,38 MB.
5. Przeliczenie na miesięczny rachunek: ile warta jest oszczędność 76,8%?
Oszczędność miejsca nabiera realnego znaczenia dopiero wtedy, gdy spojrzy się na rachunek. Poniżej nie odwołuję się do żadnych statystyk w rodzaju „kompresja poprawia konwersję” – robię tylko jedno: mnożę zmierzone 76,8% przez aktualne publiczne cenniki kilku dostawców chmury, jako czysto arytmetyczne wyliczenie.
Oszczędność na przechowywaniu = zaoszczędzona objętość (GB) × cena jednostkowa (CNY lub USD / GB / miesiąc)
Oszczędność na transferze wychodzącym = zaoszczędzona objętość (GB) × liczba pobrań w miesiącu × cena jednostkowa (CNY lub USD / GB)
Koszty przechowywania
| Rozmiar biblioteki przed kompresją | Zaoszczędzona objętość | Alibaba Cloud OSS Standard ¥0,09/GB/mies. |
AWS S3 Standard $0,023/GB/mies. |
Google Cloud Storage $0,020/GB/mies. |
Cloudflare R2 $0,015/GB/mies. |
|---|---|---|---|---|---|
| 10 GB | 7,68 GB | ¥0,69/mies. | $0,18/mies. | $0,15/mies. | $0,12/mies. |
| 100 GB | 76,8 GB | ¥6,91/mies. | $1,77/mies. | $1,54/mies. | $1,15/mies. |
| 1 TB | 786 GB | ¥70,8/mies. | $18,1/mies. | $15,7/mies. | $11,8/mies. |
| Ta partia testowa (99,9 GB) | 76,7 GB | ¥6,90/mies. | $1,76/mies. | $1,53/mies. | $1,15/mies. |
To opłaty powtarzane co miesiąc. Kompresję wykonujesz raz, a od tej pory każdego miesiąca rozliczenie jest liczone od nowej, mniejszej objętości – jednorazowy nakład pracy i długoterminowe zyski.
Transfer: prawdziwy główny koszt
Opłata transferowa to iloczyn objętości × liczby pobrań. Im częściej zdjęcia są pobierane, tym większa korzyść z kompresji. Przykład: biblioteka o rozmiarze 100 GB generuje w miesiącu 500 GB ruchu wychodzącego przez CDN (co odpowiada mniej więcej 5 pełnym pobraniom całego archiwum), a transfer maleje o te same 76,8% co objętość:
| Stawka za transfer wychodzący CDN (pierwszy próg cenowy) | Miesięczny koszt przed kompresją | Po kompresji | Oszczędność miesięczna | Oszczędność roczna |
|---|---|---|---|---|
| Alibaba Cloud CDN Chiny (¥0,15/GB) | ¥75,0 | ¥17,4 | ¥57,6 | ¥691 |
| AWS CloudFront Azja Pacyficzna ($0,12/GB) | $60,0 | $13,9 | $46,1 | $553 |
| Google Cloud CDN Ameryka Północna/Europa ($0,08/GB) | $40,0 | $9,3 | $30,7 | $369 |
Podane zostały najniższe progi cenowe; w praktyce przy wyższych progach stawki są zazwyczaj większe, a im wyższy rachunek, tym bardziej odczuwalna bezwzględna oszczędność z kompresji. Cloudflare R2 jest wyjątkiem: sam transfer wychodzący kosztuje $0, więc niemal cała korzyść realizuje się w opłatach za przechowywanie.
Powyższe ceny jednostkowe pochodzą z publicznych cenników obowiązujących w 2026 r. Rzeczywiste ceny zależą od regionu, rabatu na koncie i progu taryfowego; sprawdź aktualne stawki na stronie danego dostawcy. Liczba pobrań to jedynie przykładowe założenie – zastąp ją wartościami z własnych rachunków.
6. Scenariusz lokalny: ile czasu zaoszczędzisz przy przenoszeniu tych danych?
Zmniejszenie objętości o 76,8% skraca czas transferu niemal w tej samej proporcji – to prawda niezależnie od rachunków w chmurze i od razu widać ją podczas kopiowania czy tworzenia kopii zapasowych.
- Przenośny dysk talerzowy USB 3: przyjęto stałą przepustowość 120 MB/s.
- Przenośny dysk SSD USB 3: przyjęto 450 MB/s.
- Przewodowa sieć gigabitowa: po odliczeniu narzutu protokołu przyjęto 105 MB/s.
| Scenariusz | Zaoszczędzona objętość | Dysk talerzowy USB 3 | Dysk SSD USB 3 | Sieć gigabitowa |
|---|---|---|---|---|
| Ta partia z testu | 76,7 GB | ok. 11 min | ok. 2,9 min | ok. 12,5 min |
| Biblioteka 10 GB | 7,68 GB | ok. 66 s | ok. 17 s | ok. 75 s |
| Biblioteka 100 GB | 76,8 GB | ok. 11 min | ok. 2,9 min | ok. 12,5 min |
| Biblioteka 1 TB | 786 GB | ok. 112 min | ok. 30 min | ok. 128 min |
Tak samo jak w przypadku kosztów przechowywania to jednorazowy koszt i przewlekłe korzyści: kopiowanie na dysk przenośny i z powrotem, synchronizacja NAS, backupy Time Machine, migracja na nowy komputer, przekazywanie plików współpracownikom – za każdym razem, gdy te dane są przenoszone, oszczędzasz czas w tym samym procencie.
7. Gdy kompresja następuje jeszcze przed przesłaniem przez użytkownika
Wcześniej wyliczałem koszty po zapisaniu obrazów. Jest też odcinek, który warto policzyć: czas od kliknięcia „prześlij” do końca paska postępu. Dane przesyłane są wtedy z wykorzystaniem łącza wysyłającego użytkownika, a upload prawie zawsze jest najwolniejszym elementem całej trasy. Oryginalne zdjęcie z aparatu waży kilka MB – o rząd wielkości więcej niż finalne grafiki „po kompresji przez serwis” (średnio 299 KB z poprzedniego testu), więc różnica w czasach jest znacznie bardziej dotkliwa.
Przy średniej wielkości pojedynczego zdjęcia z tej partii: oryginał ma średnio 2,96 MB, po kompresji ImgZillą – 0,69 MB, czyli każde zdjęcie pozwala zaoszczędzić ok. 2,27 MB.
| Przepustowość wysyłania (typowy zakres z publicznych testów prędkości, orientacyjnie) | Pojedyncze zdjęcie 2,96 MB → 0,69 MB |
Wgrywanie 50 zdjęć (album) ok. 148 MB → 34 MB |
Wgranie wszystkich 32 188 zdjęć z partii 99,9 GB → 23,1 GB |
|---|---|---|---|
| Sieć mobilna (4G/5G łącznie, przyjęto 30 Mb/s) | oszczędność ok. 0,6 s | ok. 30 s | ok. 5,7 godz. |
| Typowe domowe łącze (przyjęto 25 Mb/s) | ok. 0,7 s | ok. 36 s | ok. 6,8 godz. |
| Światłowód symetryczny gigabitowy (1000 Mb/s) | ok. 0,02 s | ok. 0,9 s | ok. 10 min |
Oszczędność 0,6 sekundy przy pojedynczym zdjęciu może nie robić wrażenia, ale przy przesyłaniu całego albumu albo masowym imporcie setek zdjęć z aparatu zaoszczędzone minuty są już wyraźnie odczuwalne – zwłaszcza dla użytkowników sieci mobilnych, które i tak mają wolniejszy upload.
Podane zakresy pochodzą z publicznych statystyk testów prędkości w kraju. Rzeczywista szybkość zależy bardzo od operatora, regionu, sprzętu i obciążenia sieci – traktuj je wyłącznie jako rząd wielkości.
8. Dane i metodyka testu
- Zakres próbki: dane w artykule pochodzą z testów tej konkretnej partii 32 188 JPEG-ów z aparatu / telefonu i opisują wyniki dla niej; nie oznaczają, że „ImgZilla średnio oszczędza 76,8%”. Różne aparaty i modele dadzą różne wyniki; grafiki, które były już wcześniej mocno optymalizowane, mają wyraźnie mniejszy potencjał kompresji.
- Dobór próbki: cała partia nie była filtrowana ani czyszczona; skompresowano ją jako całość w oryginalnych 16 podkatalogach, więc nie było mowy o wybieraniu korzystnych próbek.
- Porównywalność z poprzednim artykułem: poprzednio 46,8%, teraz 76,8% – różnica wynika niemal wyłącznie z tego, czy materiały były już wcześniej kompresowane. Większość bibliotek obrazów znajdzie się między tymi wartościami: pliki kompresowane podczas dodawania do serwisu będą bliżej 46,8%, a dziewicze zdjęcia wysyłane pierwszy raz – bliżej 76,8%.
- Metodyka obliczeń: 76,8% w artykule oznacza „suma zaoszczędzonych bajtów ÷ suma bajtów oryginalnych”; średnia arytmetyczna współczynnika kompresji liczona dla pojedynczych plików to 76,6%, mediana 77,3% – obie miary podano w tekście. Jednostki objętości przeliczone według 1 GB = 10⁹ bajtów.
- Parametry kompresji: parametry są stałe, w interfejsie nie ma suwaka jakości. To celowa decyzja projektowa – parametry każdego formatu zostały zestrojone do punktu równowagi w zakresie wizualnej bezstratności. Osoby przyzwyczajone do ręcznego dostrajania powinny o tym pamiętać.
- Środowisko działania: całość wykonano lokalnie; zdjęcia nie opuszczają tego Maca, a żadne połączenie sieciowe nie jest wymagane (z wyjątkiem weryfikacji zakupu w App Store).
Źródła cen (publiczne cenniki 2026 r.; ostateczne, aktualne ceny podają strony producentów): AWS S3 Pricing, Alibaba Cloud OSS – zasady opłat, Google Cloud Storage Pricing, Cloudflare R2 Pricing, Alibaba Cloud CDN – zasady opłat, AWS CloudFront Pricing, Google Cloud CDN Pricing.
Chcesz sprawdzić to sam? Pobierz ImgZillę bezpośrednio z Mac App Store, przetestuj na kilku obrazach z własnej witryny, które były już przetwarzane, a potem zdecyduj, czy kontynuować kompresję kolejnych plików.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Więcej informacji: https://imagetool.app/ImgZilla
Wymagania systemowe: macOS 12.3 lub nowszy.