kompresja jpg + straty

Obrazki jpg są chyba z 10 razy mniejsze od oryginału,
a straty są tam przecież nieduże - niemal niezauważalne.

Zatem aż 90% zyskujemy, a tych strat ile jest?

Jeśli tego prawie nie widać to podejrzewam że tam przekłamanie
koloru jest chyba z 5 z 255.
Niech będzie 16 = 4 bity, ale tam niewiele jest przekłamane,
głównie krawędzie, obrzeża, więc pewnie poniżej 1/8.

z tego otrzymamy że te straty stanowią tyle:
4/8 * 1/8 = 4/64 = 1/16 z oryginału.

Te straty to 3 bitowy obraz i taki prawie czarny - głównie zera.
Pakujemy... metodą bezstratną, ,
i można to spokojnie dodać do pliku i będzie nadal dobra kompresja - i bezstratna!

Jest z tym jakiś problem?

Może tam wychodzi większy błąd - 8 bitów na błąd +/- 127 ?

8/8 1 / 8 = 1/8
nadal byłoby nieźle, no ale to przecież bzdura - obrazy byłby nieczytelne.

Pewnie tych błędów nie można zapakować.
Co z tego że 4 bity i tylko 1/8 pikseli, ale losowe - w dowolnym miejscu obrazu.
Obraz błędów 4 bity na piksel, czyli 1/2 zamiast 1/16 całego obrazu.

Po skompresowaniu pewnie z 1/4... też nie najgorzej.

1. Odstaw amfeatmine bo nie wiem czy ktoś nadąży za twoim rozumowaniem...
2. Wiesz że możesz po prostu przeczytać jak działa ten algorytm zamiast próbować to sobie wymyślić? o_O

Ciężko zrozumieć o co chodzi, ale JPEG stosuje kompresję stratną (regulowaną: niektóre programy pozwalają ustawiać jakość) oraz bezstratną następnie na okrojonych danych.
Dlatego raczej powinieneś porównywać rozmiar nie JPG - BMP ale JPG - PNG na przykład.

Azarien napisał(a):

Ciężko zrozumieć o co chodzi, ale JPEG stosuje kompresję stratną (regulowaną: niektóre programy pozwalają ustawiać jakość) oraz bezstratną następnie na okrojonych danych.

Weź obrazek, powiedzmy 1024x1024 x 24 bity = 3 MB,
teraz ustaw sobie jakość kompresji jpg tak żeby kompresja wynosiła z 80% - 90%,
i zapisz to pod inną nazwą.

Teraz odczytaj oba i wykonaj różnicę: = orginał - jpg.
I co tu wyjdzie?

Azarien napisał(a):

Dlatego raczej powinieneś porównywać rozmiar nie JPG - BMP ale JPG - PNG na przykład.

Kompresujemy tę różnicę metodą bezstratną i porównujemy rozmiar: jpg + ten różnicowy,
z tym png, który zwykle ma z 50% oryginału.

I co będzie mniejsze?

JPEG nie działa na pojedynczych pikselach. W skrócie:

• zamienia RBG na YCbCr,
• opcjonalne: skaluje Cb i Cr w dół (np 2x mniejsza wysokość i szerokość),
• dzieli każdy płat na bloczki 8x8,
• zamienia z postaci "time domain" na "frequency domain" za pomocą transformaty DCT (Discrete Cosine Transform),
• przeskalowanie i zaokrąglenie powstałych współczynników, czyli efektywanie coś podobnego do wyzerowania najniższych bitów; największe przeskalowania są w komórkach odpowiedzialnych za największe częstotliwości,
• następnie transformata zig-zag (takie zmodyfikowane RLE tylko nie liniami poziomymi a po skosie),
• na koniec kompresja Huffmana,

JPEG działa najlepiej gdy w komórkach odpowiedzialnych za najwyższe częstotliwości są małe wartości - wtedy utrata tych informacji nie powoduje dużej straty jakości. W większości fotografii taka sytuacja ma miejsce. Natomiast np przy kompresji pewnych rodzajów sztucznie wygenerowanych obrazów, np zrzut ekranu wypełnionego tekstem, JPEG działa kiepsko, bo nie działa założenie z poprzedniego zdania. W przypadku PNG jest wręcz przeciwnie - fotografie kompresuje słabo, ale za to zrzuty ekranu wypełnione tekstem kompresuje bardzo dobrze.

To ja wiem, bo kiedyś robiłem dekompresera jpg, i tam były te różne iDCT,
w wersjajch na float i int, plus jazda po bitach Huffmana, przeliczanie kolorów: cmyk, rgb, mono, i te ycbcr.

Było tam też takie szybkie skalowanie podczas samej dekompresji,
czyli w zasadzie interpolacja trygonometryczna, ale tylko: 1/2, 1/4, i 1/8 chyba.

Skalowania w górę nie było.
To chyba byłoby tu proste: pozostałe - brakujące częstości są zerowe.
Zatem dla powiększenia obrazu 2 razy należałoby tworzyć bloczki 16x16 z tych 8x8,
wypełniając zerami brakujące - 3/4 całości, i jedziemy normalne iDCT.

Ten zygzak robi się już na samym początku, znaczy linearyzujemy tak te klocki 8x8 na prosty ciąg 64 sztuki.

Można było przepisać zwyczajnie - linia po linii,
no ale ktoś sobie kiedyś ubzdurał, że ten slalom coś pomoże w kompresji, no i tak pozostało do dziś.

Być niekiedy pomaga - dla jakichś bliżej nieokreślonych 'typowych obrazów', ale w innych za to przeszkadza.

No, ale chodziło mi o te straty, różnice, a nie o opisy samego jpg.

Cała zabawa z tymi transformatami jest właśnie dlatego, że ludzkie oko czy ucho (+ mózg który przetwarza sygnały) są wrażliwe na pewne aspekty obrazu i dźwięku. I te transformaty pozwalają właśnie na zachowanie tych aspektów, a wycięcie znacznej części informacji, którą nasz mózg pomija. Wprost kwantyzacja pojedynczych próbek sygnału jest totalnie niezgodna z nawet najprostszymi modelami psychowizualnymi lub psychoakustycznymi.

W ogóle jest wiele metod kompresji stratnej i one różnie efektywnie działają (w sensie jakość / stopień kompresji) głównie dlatego, że jedne są bardziej zgodne z ludzkim postrzeganiem obrazu i dźwięku, a inne mniej. Twoja metoda kompresji jest totalnie debilna i dlatego działa totalnie źle. Koniec kropka.

Ponadto, jak już wspomniałem, JPEG nie nadaje się do wszystkich rodzajów obrazów. Zrób sobie zrzut ekranu z Worda wypełnionego drobnym tekstem i spróbuj kompresji JPEG i PNG.

Jaka moja metoda jest debilna?
Mówię tylko o obliczeniu wagi tych strat z jpg.

Jest bezstratna kompresja jpg, albo przynajmniej była.

W bezstratnej w końcowym etapie stosowano arithmetic coding, zamiast Huffmana z tym obcinaniem.

Te straty powstają tu tylko z dzielenia wyliczonych częstości przez stałą,
a że to są liczby całkowite, więc zaokrąglamy i tracimy najniższe bity.

Np. masz f1 = 56655, f2 = 3333, zmienne 16 bitów.
Chcemy to zmniejszyć, więc dzielimy przez powiedzmy 100 i masz wtedy:
567, 33, czyli już jest mniej bitów, co pakujemy i gotowe.

Potem przy dekompresji odtwarzamy:

56700, 3300, czyli różnica w stosunku do oryginału: 45 i 33.
ogólnie do 0.5%, dla dzielenia przez 100.

W bezstratnej w końcowym etapie stosowano arithmetic coding, zamiast Huffmana z tym obcinaniem.

Błąd. Bardzo duży błąd. Zarówno kompresja Huffmana jak i kodowanie arytmetyczne może być użyte w obu trybach: stratnym i bezstratnym.

Jest bezstratna kompresja jpg, albo przynajmniej była.

Jest i działa na zupełnie innej zasadzie niż ta stratna: http://en.wikipedia.org/wiki/Lossless_JPEG

Co ty w ogóle chcesz zrobić? Kompresję bezstratną bazującą na stratnej? To będzie kiepsko działać. Wybierz sobie jakiś kodek z góry tej listy: http://www.squeezechart.com/bitmap.html i będzie on działać lepiej niż te twoje koślawe metody.

Wibowit napisał(a):

Błąd. Bardzo duży błąd. Zarówno kompresja Huffmana jak i kodowanie arytmetyczne może być użyte w obu trybach: stratnym i bezstratnym.

Żaden błąd.
Kodowanie arytmetyczna jest trochę lepsze od Huffmana, więc stosowali to do bezstratnej;
a przynajmniej chcieli stosować, ale ja nigdy nawet nie widziałem jpg z arithmetic coding.

Metoda arytmetyczna była wtedy obwarowany patentami, więc programistom nie wolno było stosować bez pozwolenia.
http://en.wikipedia.org/wiki/Arithmetic_coding

Tamte bezstratne są chyba słabe - porównywalne z png, czy innymi,
dlatego pewnie można to robić lepiej.

Podobnie było z ogólną kompresją danych:
rządziły jakieś te zipy i arj-ty, a potem jakiś rosyjski 'amator' zrobił rar i okazało się że można znacznie lepiej.

Żaden błąd.
Kodowanie arytmetyczna jest trochę lepsze od Huffmana, więc stosowali to do bezstratnej;
a przynajmniej chcieli stosować, ale ja nigdy nawet nie widziałem jpg z arithmetic coding.

Jedyne JPEGi jakie widziałem to stratne z kompresją Huffmana, ale to nie znaczy, że do stratnej tylko Huffmana przewidzieli. Tak jak napisałem: zarówno w trybie stratnym jak i bezstratnym można stosować kodowanie arytmetyczne. Kodowanie arytmetyczne nie ma nic wspólnego z tym czy algorytm jest stratny czy nie - kodowanie arytmetyczne jest zawsze bezstratne, tak samo jak kodowanie Huffmana. Straty są na wcześniejszych etapach - głównie kwantyzacja, ale także, w mniejszym stopniu, błędy zaokrągleń.

Podobnie było z ogólną kompresją danych:
rządziły jakieś te zipy i arj-ty, a potem jakiś rosyjski 'amator' zrobił rar i okazało się że można znacznie lepiej.

RAR kompresuje lepiej głównie dlatego, że ma specjalne filtry (np dla plików wykonywalnych) i umożliwia zastosowanie większego okna w kompresji LZ (np 4 MiB w RAR 2.0 zamiast 32 KiB w standardowym Deflate). Przy wyłączonych filtrach i oknie o takim samym rozmiarze jak w Deflate, RAR kompresuje praktycznie tak samo. LZMA bez filtrów w 7zipie kompresuje lepiej niż RAR bez filtrów przy takim samym oknie - to dlatego, że stosuje kodowanie arytmetyczne i ekstra sztuczki z modelowaniem symboli.

Tak, w moim starym kodzie są takie kombinacje:

 case M_SOF3:		// Lossless, Huffman
 case M_SOF5:		// Differential sequential, Huffman
 case M_SOF6:		// Differential progressive, Huffman
 case M_SOF7:		// Differential lossless, Huffman
 case M_JPG:		// Reserved for JPEG extensions
 case M_SOF11:		// Lossless, arithmetic
 case M_SOF13:		// Differential sequential, arithmetic
 case M_SOF14:		// Differential progressive, arithmetic
 case M_SOF15:		// Differential lossless, arithmetic

Nie wiem ile rar ramu potrzebuje, ale lepiej kompresuje nawet niewielkie pliki tekstowe,
a wtedy wielkość okna 4MB chyba wiele nie pomoże - za mało danych.

Mam taki pliczek 1.5 MB różnych słówek i opisów,
i pod zip wychodzi z tego 650 KB, a rar 420 KB.

Tak, w moim starym kodzie są takie kombinacje:

A więc są wszystkie kombinacje tak jak mówiłem.

Nie wiem ile rar ramu potrzebuje, ale lepiej kompresuje nawet niewielkie pliki tekstowe,
a wtedy wielkość okna 4MB chyba wiele nie pomoże - za mało danych.

Mam taki pliczek 1.5 MB różnych słówek i opisów,
i pod zip wychodzi z tego 650 KB, a rar 420 KB.

Wystarczy, że plik ma więcej niż okno Deflate, czyli więcej niż 32 KiB. Do tego dochodzi jeszcze np:

• możliwość kompresji ciągłej - ZIP kompresuje każdy plik oddzielnie, RAR ma opcję klejenia wszystkiego w jeden strumień danych,
• RAR 3.x dla plików tekstowych korzysta z metody kompresji PPMD, której to implementacja jest na licencji Public Domain; algorytm ten działa znacznie lepiej na danych tekstowych niż LZ, a porównywalnie na binarkach - z tym, że jest symetryczny (kompresja trwa tyle samo co dekompresja i wymaga też tyle samo pamięci) i z tego względu został wyrzucony z formatu RAR 4.0.

Ale nie ma tam mojej kombinacji:
kompresja stratna + różnica z kompresją bezstratną = bezstratna.

Na pewno wyjdzie lepiej od bezpośredniej bezstratnej.

Na pewno wyjdzie lepiej od bezpośredniej bezstratnej.

Skoro jesteś pewien to spróbuj i podaj swoje wyniki np na próbkach ze wspomnianej strony: http://www.squeezechart.com/bitmap.html

Bardziej pewne jest to, że dziesiątkom ludzi, którzy zajmują się tworzeniem algorytmów bezstratnej kompresji obrazów zaświtał w głowie taki sam pomysł jak twój i go wypróbowali. A po wypróbowaniu wyrzucili w niebyt, sądząc po opublikowanych kodekach (tzn braku takich reprezentujących twój pomysł) - zapewne bezstratne kodeki oparte na stratnej kompresji + kodowaniu straty są tak słabe, że nikt nie chce się ośmieszać.

Miałem nadzieję że ktoś inny to sprawdzi, no ale jak widać stara prawda jest niezniszczalna...
gdy zaczniesz liczyć na innych wtedy twoje losy zawisną na włosku.

To że inni nie zrobili czegoś nie znaczy, że jesteśmy już doskonali.
Oj! Wiele przeróżnych dogmatów znałem za młodu, a teraz ostał mi się jeno jeden:
prawdy poprzez domniemanie, autorytety, albo zaniechanie to tylko populistyczne bzdury malutkich, nieudolnych i ciemnych.

W domu wszyscy zdrowi? Co to za problem sprawdzić? Weź sobie obrazek wejściowy, zakoduj w JPEGu, różnicę możesz obliczyć trywialnie za pomocą GIMPa, a potem możesz tą różnicę skompresować np 7zipem. W czym problem?

Jak mi dobrze zapłacisz za godzinę to mogę zakodować te twoje pomysły, ale jak na razie to po prostu popisujesz się niewiedzą, a na dodatek w ostatnim poście dałeś popis schorzenia umysłowego.

Masz za bardzo schorzony umysł, dlatego nie zlecę, hihi!