Jakie czynniki powodują lub zapobiegają „utracie pokoleń”, gdy pliki JPEG są wielokrotnie kompresowane?


29

Przez lata wierzyłem, że wielokrotne kompresowanie plików JPEG stopniowo pogorszy jego jakość, dopóki nie staną się nierozpoznawalnym bałaganem, tak jak robi to kserokopie kserokopii. To intuicyjnie ma sens, ponieważ JPEG jest formatem stratnym. Istnieją również inne pytania i odpowiedzi, które twierdzą, że tak jest:

Jednak przeczytałem również, że ponowne skompresowanie plików JPEG na tym samym poziomie jakości nie pogorszy jakości obrazu. Jest to sprzeczne ze stopniową degradacją opisaną w innym miejscu.

Co technicznie dzieje się po ponownej kompresji JPEG?  Co ginie i jak? Czy obraz naprawdę zmieni się w śnieżny bałagan, który pojawiał się w telewizji? Co z filmami pokazującymi obrazy, które rozpadają się po wielokrotnym skompresowaniu?

(Proszę nie tylko falować ręką i odwoływać się do ogólnej koncepcji stratności).

(To pytanie oraz dotychczasowe odpowiedzi skupiają się na czynnikach technicznych (określone ustawienia i manipulacje obrazem), które powodują lub zapobiegają degradacji obrazu, gdy plik JPEG jest wielokrotnie kompresowany .)





2
@MonkeyZeus Niektóre (małe) ilości danych obrazu są tracone przez błąd zaokrąglania przy jakości 100. Ponowna kompresja przy tym samym ustawieniu (np. 80) nie powoduje stopniowej utraty danych. Jest to „powszechna wiedza”, do której ma odpowiedzieć niniejsze pytanie.
xiota

1
@MonkeyZeus Wartości takie jak „100” i „80” (lub „10, 11, 12” w Photoshopie) są dowolne - 100% nie jest bezstratne.
mattdm

Odpowiedzi:


32

Prawie wszystkie straty jakości obrazu występują przy pierwszej kompresji obrazu jako JPEG. Bez względu na to, ile razy JPEG jest ponownie kompresowany przy tych samych ustawieniach , straty pokoleniowe są ograniczone do błędu zaokrąglenia.

  • Granice MCU pozostają nienaruszone (bloki 8x8).

  • Podpróbkowanie kolorów jest wyłączone.

  • Stały DQT (to samo ustawienie jakości).

Jednak błędy zaokrąglania mogą być duże dla każdej iteracji, w której powyższe kryteria nie są spełnione, i rozsądne jest przechowywanie kopii zapasowych wszystkich oryginalnych plików.


Algorytm kompresji JPEG

  1. Konwertuj przestrzeń kolorów. W razie potrzeby zmniejsz informacje o kolorze (podpróbkowanie kolorów) (Lossy) . Jeśli próbkowanie nie zostanie zmniejszone, utrata informacji jest wynikiem błędu zaokrąglania .

  2. Segmentacja. Podziel każdy kanał na bloki 8x8 (MCU = Minimalna jednostka kodująca). (Bezstratny)

    Uwaga: Jeśli włączone jest podpróbkowanie barwy, MCU mogą efektywnie mieć wymiary 16 x 8, 8 x 16 lub 16 x 16, jeśli chodzi o oryginalny obraz. Jednak MCU to nadal wszystkie bloki 8x8.

  3. Dyskretna transformacja kosinusowa (DCT) na każdym MCU. Utrata informacji jest wynikiem błędu zaokrąglania .

  4. Kwantyzacja.  Wartość w każdej komórce MCU jest podzielona przez liczbę określoną w tabeli kwantyzacji (DQT). Wartości są zaokrąglane w dół, z których wiele stanie się zero. Jest to pierwotna stratna część algorytmu.

  5. Skanowanie Zig-Zag. Zmień kolejność wartości w każdym MCU na sekwencję liczb zgodną ze wzorem zygzakowatym. Zera występujące podczas kwantyzacji zostaną zgrupowane razem. (Bezstratny)

  6. DPCM = Różnicowa modulacja impulsów. Przekształć sekwencje liczb w formę łatwiejszą do kompresji. (Bezstratny)

  7. RLE = Kodowanie długości przebiegu. Kolejne zera są kompresowane. (Bezstratny)

  8. Kodowanie Entropii / Huffmana. (Bezstratny)

Ponowna kompresja plików JPEG

Pamiętaj, że próbkowanie w dół kanałów kolorów i kwantyzacja są jedynymi celowo stratnymi krokami . Pomijając błąd zaokrąglania na razie, wszystkie pozostałe kroki są bezstratne. Po wystąpieniu kwantyzacji odwrócenie i powtórzenie kroku daje identyczne wyniki. Innymi słowy, ponowna kwantyzacja (przy tym samym DQT) jest bezstratna .

Zasadniczo możliwe jest utworzenie algorytmu ponownego próbkowania, który po pierwszym przejściu będzie bezstratny. Jednak dzięki implementacji w ImageMagick kolory mogą drastycznie przesuwać się przed osiągnięciem stanu ustalonego, jak widać na zdjęciu.

Biorąc pod uwagę optymalne warunki, ponowne skompresowanie pliku JPEG przy tych samych ustawieniach jakości skutkowałoby dokładnie tym samym plikiem JPEG. Innymi słowy, ponowna kompresja plików JPEG jest potencjalnie bezstratna . W praktyce ponowne kompresowanie plików JPEG nie jest bezstratne, ale podlega i jest ograniczone błędem zaokrąglania. Chociaż błędy zaokrąglania często w końcu zbiegają się do zera , tak że odtworzony zostaje dokładnie ten sam obraz, podpróbkowanie kolorów może spowodować znaczące zmiany kolorów.

Demonstracja (to samo ustawienie jakości)

Napisałem następujący bashskrypt, który używa ImageMagick do wielokrotnej kompresji pliku JPEG przy danym ustawieniu jakości:

#!/usr/bin/env bash
n=10001; q1=90
convert original.png -sampling-factor 4:4:4 -quality ${q1} ${n}.jpg

while true ; do
   q2=${q1}            # for variants, such as adding randomness
   convert ${n}.jpg -quality ${q2} $((n+1)).jpg
   #\rm $((n-5)).jpg   # uncomment to avoid running out of space
   n=$((n+1))

   echo -n "$q2  "
   md5sum ${n}.jpg
done

Po kilkuset iteracjach uruchomiłem md5sumwyniki:

d9c0d55ee5c8b5408f7e50f8ebc1010e  original.jpg

880db8f146db87d293def674c6845007  10316.jpg
880db8f146db87d293def674c6845007  10317.jpg
880db8f146db87d293def674c6845007  10318.jpg
880db8f146db87d293def674c6845007  10319.jpg
880db8f146db87d293def674c6845007  10320.jpg

Widzimy, że w rzeczywistości błąd zaokrąglenia zbliżył się do zera, a ten sam obraz jest odtwarzany w kółko .

Powtórzyłem to wiele razy z różnymi ustawieniami zdjęć i jakości. Zwykle osiągany jest stan ustalony, a dokładnie ten sam obraz jest odtwarzany w kółko.

Co z wynikami @ mattdm ?

Próbowałem zreplikować wyniki mattdm przy użyciu Imagemagick na Ubuntu 18.04. Oryginał był surową konwersją do TIFF w Rawtherapee, ale wydaje się, że nie jest już dostępny. Zamiast tego wziąłem powiększoną wersję i zmniejszyłem ją do pierwotnego rozmiaru (256x256). Następnie wielokrotnie kompresowałem w 75, aż do uzyskania konwergencji. Oto wynik (oryginał, 1, n, różnica):

próba replikacji mattdm

Moje wyniki są różne. Bez prawdziwego oryginału nie można ustalić przyczyny różnicy.

Co z montażem @ ths ?

Ponownie skompresowałem obraz od lewego górnego rogu montażu do zbieżności na 90. Oto wynik (oryginał, 1, n, różnica):

próba replikacji tego montażu

Po włączeniu podpróbkowania barwy kolory zmieniają się do momentu osiągnięcia stanu ustalonego.

zmiana koloru

Przełączanie między niewielką liczbą ustawień

Zmieniając zmienną q2, ustawienie jakości można ograniczyć do zestawu równomiernie rozłożonych wartości.

q2=$(( (RANDOM % 3)*5  + 70 ))

W przypadku niewielkiej liczby wyborów ustawień równowaga może ostatecznie zostać osiągnięta , co widać, gdy wartości md5 zaczynają się powtarzać. Wydaje się, że im większy zestaw, tym dłużej to trwa i tym gorszy staje się obraz, zanim można osiągnąć równowagę.

W równowadze wydaje się, że współczynnik DCT przed kwantyzacją musi być podzielny na wszystkie (lub większość) wartości kwantowych. Na przykład, jeśli przełączasz się między dwoma DQT, w których współczynnik DCT jest dzielony naprzemiennie przez 3 i 5, równowaga zostanie osiągnięta, gdy współczynnik DCT jest podzielny przez 15. To wyjaśnia, dlaczego spadek jakości jest znacznie większy niż różnica między oryginalnymi ustawieniami.

Zmiana spośród większej liczby ustawień

Kłapouchy nie jest szczęśliwy, kiedy q2jest zmieniany w taki sposób:

q2=$(( (RANDOM % 9)  + 90 ))

Aby zrobić wideo, użyj ffmpeg:

rename 's@1@@' 1*.jpg
ffmpeg -r 30 -i %04d.jpg -c:v libx264 -crf 1 -vf fps=25 -pix_fmt yuv420p output.mp4

Oglądanie pierwszych 9999 iteracji jest prawie jak oglądanie wrzenia wody. Może chcesz podwoić prędkość odtwarzania. Oto Kłapouchy po iteracjach 11999:

11999 iteracji, losowe DQT

Co się stanie, jeśli zmienią się granice MCU?

Jeśli zmiany wystąpią ograniczoną liczbę razy, wielokrotne ponowne kompresowanie prawdopodobnie osiągnie stan ustalony. Jeśli zmiany wystąpią przy każdej iteracji, obraz prawdopodobnie ulegnie degradacji w sposób podobny do zmian DQT.

  • Tak dzieje się w przypadku filmów obracających obraz o wymiarach, których nie można podzielić przez 8.

Co z edycją?

Efekt ponownej kompresji po edycji zależy od konkretnej wykonanej edycji. Na przykład zapisanie tego samego ustawienia jakości po zmniejszeniu artefaktów JPEG przywróciłoby te same artefakty. Jednak zastosowanie zlokalizowanej zmiany, takiej jak pędzel korygujący, nie wpłynie na obszary, które nie zostały dotknięte.

Największy spadek jakości obrazu występuje przy pierwszej kompresji pliku przy danym ustawieniu jakości. Następnie ponowne skompresowanie z tym samym ustawieniem nie powinno wprowadzać żadnych zmian większych niż błąd zaokrąglania. Spodziewałbym się więc, że cykle edycji-ponownego zapisywania przy danym ustawieniu jakości będą wyglądały jak każdy inny obraz zapisany z tym samym ustawieniem jakości (o ile granice MCU pozostaną nienaruszone, a podpróbkowanie barwy jest wyłączone ).

Co z tymi filmami?

Czy mogę nadpisywać oryginały przy pomocy skompresowanych plików JPEG?

Rozsądne jest przechowywanie kopii zapasowych wszystkich oryginalnych plików, ale jeśli przypadkowo nadpiszesz jeden, uszkodzenie jest prawdopodobnie ograniczone. Byłoby również dobrze pracować w formacie JPEG z wyłączonym podpróbkowaniem barwy.

JPEG nie może być używany w przypadku obrazów, które używają więcej niż 8 bitów na kolor.


5
obraz jest jednak zupełnie inny w przypadku pętli load- edit -save. w takim przypadku powtarzana kwantyzacja spowoduje degradację.
tys

2
właśnie wykonałem test przy użyciu tego samego skryptu, co w odpowiedzi. oto montaż co 20 obrazu do tp 100: i.stack.imgur.com/xtob6.jpg, który jest znaczący.
tys

2
ah. znalazłem problem z moim obrazem. jeśli masz włączone podpróbkowanie barwy, prowadzi to do postępującej degradacji.
tys

2
Też to znalazłem. Włączenie podpróbkowania barwy znacząco zmienia kolor obrazu przed osiągnięciem stanu ustalonego.
xiota

2
Powtarzające się ładowanie i zapisywanie przy użyciu dokładnie tych samych parametrów prawdopodobnie nie spowodowałoby nieograniczonej utraty jakości, ponieważ większość plików wejściowych można załadować i zapisać ponownie bez wprowadzania dodatkowego błędu zaokrąglania, a pliki, na które wystąpiłyby błędy zaokrąglania, prawdopodobnie zostałyby przekształcone w pliki, które nie. Z drugiej strony powtarzające się cykle ładowania / zapisywania na przemian między parametrami kompresji, które są podobne, ale nie identyczne, mogą powodować błędy zaokrąglania w każdym cyklu.
supercat

20

Utrata rekompresji jest realna, szczególnie podczas pracy z wyższymi poziomami kompresji JPEG.

Teoretycznie, jeśli ponownie zapiszesz pliki JPEG o dokładnie takich samych parametrach i dopasujesz przycięcie do bloków 8 × 8, degradacja powinna być minimalna. Jeśli jednak używasz wysokiego poziomu kompresji, zobaczysz dalszą utratę, ponieważ artefakty wprowadzone przez kompresję początkową są trwałymi zmianami obrazu i również zostaną ponownie skompresowane, powodując więcej artefaktów.

Jeśli ponownie zapiszesz z niskim poziomem kompresji (wysoka jakość, np. „100” w Gimpie lub 11 lub 12 w Photoshopie), wszelkie nowo dodane artefakty będą trudne do zauważenia. To nie sprawi, że obraz dowolnego lepiej , ale nie znacznie gorzej. Jednak to będzie wprowadzić zmiany w całym obrazie.

Jako szybki test użyłem ImageMagick do ponownej kompresji obrazu JPEG w 75%. Poniższe próbki są przesyłane jako pliki PNG, aby uniknąć dalszej ponownej kompresji, i zostały podwojone, gdy przekonwertowałem na PNG, aby efekt był bardziej widoczny. (Oryginały użyte w teście nie zostały podwojone.) Okazuje się, że po ośmiu próbkach efekt zbiegał się w idealnie stabilny wynik, przy czym ponowna kompresja skutkuje identycznym plikiem bit po bicie.

Oto nieskompresowany oryginał:

oryginalny, bez kompresji JPEG

Oto wynik przejścia na 75% JPEG:

pierwszy JPEG

A oto, co uratowało:

drugie przejście

Ten jednosekundowy zapis powoduje znaczną dodatkową degradację!

A oto ostatni zbiegły się obraz (8. przejście):

konwergentny JPEG

Ponownie, kolory są zdecydowanie bardziej ubogie, w tym niektóre fałszywe wzory kolorów, a blokowe artefakty wyskakują jeszcze bardziej. Algorytm jest zbieżny, ale do wersji znacznie zdegradowanej. Więc nie rób tego.

Ale to samo z poziomem jakości 99%, po 9 przejściach (punkt, w którym zbiega się, aby kolejne przejścia były identyczne):

99% 9 razy

Tutaj różnica ledwo się rejestruje. (Mam na myśli to dosłownie; porównaj je piksel po pikselu z wersją nieskompresowaną, a odchylenie to tylko niewielki losowy szum). A co, jeśli wrócę do tego pierwszego obrazu 75%, a następnie ponownie zapisz na 99%? Cóż, to (po raz pierwszy):

75% raz, a następnie 99% raz

Zapisywanie w wysokiej jakości jest zdecydowanie wyraźnie lepiej niż resaving z tymi samymi parametrami, niby do mojego zaskoczenia. Ale widoczna jest nowa degradacja różowego wykończenia i oczu. W przypadku przetworzonych wersji tych samych ustawień artefakty JPEG są wyolbrzymione przy każdej rekompresji. Przy niskiej rozdzielczości i niskiej jakości, które wybrałem, okazuje się to gorsze niż kompresowanie wszystkiego inaczej.

Na tych filmach: znalazłem ten jako najlepszy hit Google. Zauważ, że w opisie jest napisane:

Dzieje się tak, jeśli wielokrotnie kodujesz obraz JPEG przy losowych ustawieniach wysokiej jakości (85 lub więcej).

Podkreślenie dodane - wyjaśnia, dlaczego nie ma żadnej zbieżności, ponieważ zamiast oszczędzania z tymi samymi ustawieniami lub oszczędzania w super wysokiej jakości, za każdym razem stosuje się losowe ustawienia .

Drugi film znalazłem mówi:

Obraz JPEG został skopiowany i obrócił pełny obrót dla każdego obrazu. [...] (596 czynności „obracaj zgodnie z ruchem wskazówek zegara”)

I znowu zrobiono coś, aby błędy się kumulowały.

W każdym razie, w celu praktycznej edycji zdjęć , warto wspomnieć, że oszczędność 75% jednorazowo jest znacznie gorsza niż oszczędność 99% milion razy . W moim przykładzie artefakty w 75% są tak oczywiste, że dalsza degradacja jest jak zrzucanie wody do oceanu. Jeśli zapiszesz na wystarczająco wysokim poziomie, że te artefakty nie są tak naprawdę widoczne, dobrym pomysłem jest ponowne zapisanie ustawień oryginalnych. Oczywiście, jeśli możesz pozostać przy pracy z nieskompresowanymi oryginałami, to lepiej.

Jeśli z jakiegoś powodu musisz (lub zdecydowanie wolisz) po prostu pracować z JPEG, ustaw aparat tak, aby zapisywał najwyższą możliwą jakość , nawet jeśli nie zauważysz różnicy w początkowych plikach. Zobacz Czy warto korzystać z ustawienia jakości Premium JPEG Pentaxa? więcej na ten temat - niekoniecznie tak naprawdę specyficzny dla Pentaxa.


(1) Oszczędzasz 75%. Przy tym ustawieniu oczekiwana jest utrata jakości obrazu. (2) Ten obraz został wybrany i zmieniony w celu wyolbrzymiania artefaktów kompresji JPEG. (3) Obraz jest zbieżny po 8 rundach ponownej kompresji, po których nie nastąpi dalsze obniżenie jakości obrazu. (4) W filmie tego obrazu pokazującego „utratę generacji” po pierwszej 1/4 sekundy nic się nie wydarzy.
xiota

5
(1) Tak. (2) „Wybrane” jako typowe zdjęcie, na którym można dbać o tego rodzaju rzeczy. „Zmieniono” tylko w celu powiększenia. Pamiętaj, że jest to tylko do wyświetlania tutaj - nie podwoiłem wielkości obrazu, z którym pracowałem. (3) Tak, ale w praktyce do edycji jest to kilka pierwszych rund, które mogą Cię zainteresować. (4) To prawda, ale nie oznacza to, że zbliżenie się do najgorszego przypadku i pozostanie tam jest przydatne w jakikolwiek sposób.
mattdm

Aby powielić, zrób pierwszy obraz i zmień rozmiar na 256 × 256 bez ponownego próbkowania lub interpolacji.
mattdm

Nie widzę dużej różnicy między wyświetlanymi obrazami. Ale jeśli wezmę różnicę pojedynczo skompresowanego i mutliply-skompresowanego obrazu i wzmocnię go, aby był widoczny, otrzymam ten (o wiele bardziej przekonujący) wynik: i.stack.imgur.com/57uaY.png (zobacz moje usunięte odpowiedź na to, co zostało zrobione dokładnie) Jest to bardziej przekonujące, ponieważ ludzie nie muszą wpatrywać się w obraz, aby wykryć drobne różnice.
Szabolcs

Różnice są dość małe. Jeśli masz duży ekran LCD, inna „gamma” wynikająca z nieco różnych kątów widzenia może sprawić, że artefakty będą bardziej widoczne.
xiota

5

Rekompresja ma mierzalny wpływ na jakość obrazu i efekt ten jest znacznie wyraźniejszy przy zmianie współczynników kompresji.

Jako szybkie sprawdzenie tutaj, ponieważ niektóre wartości SSIM dla operacji wykonywanych na obrazie testowym zawierającym kombinację cech liniowych i ciągłych. Wybrałem JPG95, ponieważ tego właśnie nauczono mnie używać w szkole Ad-photo i JPG83, ponieważ jest to powszechne wśród dostawców treści cyfrowych.

  • Zapisz obraz Tiff jako JPG95 - .9989
  • Zapisz obraz Tiff jako JPG83 - .9929
  • Ponownie zapisz obraz JPG95 jako JPG95 10 razy - .9998
  • Ponownie zapisz obraz JPG83 jako JPG83 10 razy - .9993
  • Ponownie zapisz JPG95 jako JPG83, a następnie ponownie zapisz jako JPG95 - .9929
  • Ponownie zapisz JPG95 jako JPG83, następnie JP83 do JP92, a następnie JPG92 do JPG86 - .9914

Tak więc ilość podobieństwa strukturalnego utraconego przy ponownym zapisywaniu przy tej samej kompresji 10 razy jest 1/10 tej utraconej jako oszczędzanie przy jakości z tiff. Jednak utrata jakości po zmianie kompresji JPG nawet raz jest taka sama, jak w przypadku utraty tego obrazu z Tiff do JPG.

Uruchomię ten test na kilka innych sposobów i zaktualizuję.

Metodologia : W ImageJ:

  1. Konwertuj Tiff RGB na 8-bitową skalę szarości
  2. Zapisz JPG95 i JPG83 z Tiff Original
  3. Przeprowadź dalsze operacje ponownego zapisywania zgodnie z opisem
  4. Załaduj obrazy porównawcze i użyj wtyczki SSIM Index

UWAGA: wiele osób patrząc na wartości SSIM po raz pierwszy odczytuje je jako wartości procentowe i zakłada, że ​​różnica jest niewielka. To niekoniecznie jest prawdą. Wartości SSIM powinny być porównywane względem siebie, a nie traktowane jako wariancja od 1.


@xiota, używam wtyczki SSIM dla ImageJ. Jest to jedna z niewielu implementacji SSIM, która umożliwia dostosowanie parametrów (ustawiłem szerokość filtra na 8, aby bardziej prawdopodobne było wykrycie zmian w blokach JPEG 16px.) Wolę SSIM, ponieważ jest bardziej wrażliwy na różnice w energii redystrybucja. Obraz różnicy może wprowadzać w błąd, jeśli różnice się znoszą lub różnice są skoncentrowane na małym obszarze.
PhotoScientist

I na drugie pytanie, które mówi, że różnica między JPG95 a JPG83 do JPG95 jest taka sama jak przejście z Tiff na JPG83. Jeśli chcesz Tiff-JPG95-JPG83-JPG95, czyli .9923
PhotoScientist

Dodano próbę z czterema różnymi kompresjami. Strata jest jeszcze większa, ale jasne jest, że „konwergencja” obserwowana w kilku generacjach tej samej kompresji występuje również podczas próby wielu różnych kompresji. Nadal chciałbym wypróbować to w pracy zorientowanej na aplikacje, ale wymaga to nieco więcej pracy nóg.
PhotoScientist

Innym problemem jest to, że nie ma standardowego mapowania ustawień „jakości” na progi SSIM, ani nie ma sposobu na określenie, jakie ustawienie jakości byłoby potrzebne, aby uniknąć znacznej utraty informacji. Jeśli ktoś załaduje plik JPEG i zapisze go na wystarczająco wysokim poziomie, można uniknąć dodatkowej utraty jakości, ale plik prawdopodobnie będzie się powiększał. Jeśli nie wiadomo, jakie ustawienie zastosowano podczas tworzenia pliku, może być trudno określić, które ustawienie należy zastosować podczas jego ponownego zapisywania.
supercat

4

Nie ma to jak eksperymentowanie. Poniższy skrypt bash (napisany w systemie Linux, może działać w systemie OSX, jeśli masz ImageMagick ):

  • zaczynając od pierwszego obrazu (o nazwie step000.jpg)
  • pobiera plik JPEG, dodaje białą kropkę (aby udowodnić, że jest to nowy obraz) i zapisuje go jako (bezstratny PNG)
  • pobiera PNG i ponownie kompresuje go jako JPEG (więc nigdy nie kompresujemy JPEG-do-JPEG i nie możemy postawić hipotezy, że oprogramowanie kopiuje tylko zakodowane bloki)
  • tworzy obraz pokazujący różne piksele między dwoma plikami JPEG
  • opłukać i powtórzyć, używając wyjściowego JPG z poprzedniego kroku

Rezultat jest taki, że:

  1. przy wysokiej jakości JPG nie ma dużych strat
  2. błędy zaokrągleń ostatecznie ustąpiły, po kilku pokoleniach rzeczy już się nie degradują.

Oczywiście wszystko to zakłada, że ​​JPEG jest zapisywany przez to samo oprogramowanie z tymi samymi parametrami za każdym razem.

#! /bin/bash
# Runs successive JPEG saves on an image to evaluate JPEG losses

# convert & compare command from imagemagick
# if you use a recent version of IM, set these variables to:
# compare="magick compare"
# convert="magick convert"
convert=convert
compare=compare

dotradius=2
defaultsteps=10
defaultquality=90 # default quality for "convert"

function usage {
        echo "Usage: $0 [quality [steps]]"
        echo ""
        echo "Where:"
        echo "       - 'quality' is the quality factor of the JPEG compression "
        echo "          (1-100, 100 is best, default is $defaultquality)"
        echo "       - 'steps' is the number of successive steps to perform"
        echo "         (default is $defaultsteps)"
        echo ""
        echo "Produces:"
        echo "   - successive saves of a JPEG image to test JPEG-induced losses."
        echo "   - compare images with the original file and the 1st JPEG save."
        echo ""
        echo "Starts from a 'step000.jpg' file in the current directory."
        exit 1
}

[[ -n "$3" ]] && { usage ; exit 1 ; }
steps=${1:-$defaultsteps}
quality=${2:-$defaultquality}    
dotcolor="white" # change this if the top of the image is too clear

echo "Running with $steps steps with quality $quality"

for step in $(seq $steps)
do 
    echo "Step $step of $steps"
    src=$(printf step%03d $(( $step - 1 )) ) 
    dst=$(printf step%03d $(( $step )) )
    dif=$(printf diff%03d $(( $step )) )
    # dot coordinates
    let cxc="2 * $dotradius * $step"
    let cxr="$cxc + $dotradius"
    let cyc="$dotradius * 2"
    let cyr="$dotsradius * 2"

    $convert $src.jpg -fill white -draw "circle $cxc,$cyc,$cxr,$cyr" $dst.png
    $convert $dst.png -quality $quality $dst.jpg
    rm $dst.png
    $compare $src.jpg $dst.jpg $dif.jpg
done

Na razie nie będę pokazywał wyników, wolę pozwolić ci eksperymentować z własnymi zdjęciami. Przy wystarczającej liczbie komentarzy dodam próbkę.


1
Byłem ciekawy innego oprogramowania. Próbowałem zapisać 7x z 7 różnych programów. Różnica była dość duża, więc zepsułem ją, aby sprawdzić, czy każda aplikacja ma tę samą stratę. Jedna z aplikacji była odpowiedzialna za całą odmianę. Kiedy usunąłem czerwonego śledzia, 6x zapisy z 6x programów było takie samo jak 6x zapisów z ImageJ
PhotoScientist

Prawdopodobnie jest źle zaprogramowane oprogramowanie. Możliwe jest również, że mieszanie algorytmów z różnych aplikacji zapobiegnie również usuwaniu błędów zaokrągleń.
ksenoid

@xiota, to był dziwny mały program o nazwie FLEMinimizer. Nie pamiętam nawet, dlaczego to miałem. Pozostałe to ImageJ, Matlab, Photoshop, FastStone Image Viewer, Ifranview i CameraRaw. Pomiędzy tymi sześcioma nie było prawie żadnych różnic.
PhotoScientist
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.