warto byłoby chyba jeszcze dodać, że standard ma również do zaoferowania możliwość bezstratnej kompresji (choć nie mogę znaleźć informacji na temat tego, czy wtedy algorytm kompresji zapewnia równie dobre wyniki) oraz wsparcie dla kanału przezroczystości.

Świetny format, jedno zdjęcie trzeba kompresować przez kilka minut na czterowątkowym procesorze. PNG/TIFF/JPEG (o RAW nie wspominam) pozostają niezagrożone.

@Canonex

mógłbyś się podzielić źródłem tej informacji?

Doświadczenia własne, przy użyciu konwertera ze strony autora.

link

creologic | 2014-12-17 14:51:15

"warto byłoby chyba jeszcze dodać, że standard ma również do zaoferowania możliwość bezstratnej kompresji (choć nie mogę znaleźć informacji na temat tego, czy wtedy algorytm kompresji zapewnia równie dobre wyniki) oraz wsparcie dla kanału przezroczystości."

Nie tylko nie zapewnia, ale nie może zapewnić. Przy bezstratnej kompresji, każdy przypadkowy bit pochodzący od szumu (czy to śrutowego, czy termicznego) musi być zachowany niejako z definicji. A wiadomo, że szum się kompresuje źle.

Tyle teoria, ale praktyka ją potwierdza na przykładzie doświadczeń z JPEG 2000 w trybie bezstratnym: pliki JP2 kompresowane np. w Kakadu z opcją "-Reversible" mają rozmiary porównywalne z CR2.

@Canonex

chyba jednak nie masz racji :)

link

enkoder pobrany ze strony autora, nawet nie chce mi się sprawdzać to za laptop, który mam właśnie pod ręką ale na pewno nie 4 rdzenie (co innego rdzenie, co innego wątki btw.)

W skrócie - kompresja trwa zauważalny kawałek czasu, ale na pewno nie kilka minut.

@Bahrd

nie rozumiem Twojej wypowiedzi. Co ma szum do bezstratności kompresji? inna sprawa, że szum zazwyczaj zwiększa rozmiar pliku (w JPEG każda nagła zmiana koloru powoduje znaczący wzrost pliku), ale bezstratność kompresji jest tu pojęciem ortogonalnym. Co więcej, enkoder ma przełącznik /loseless, a skoro autor deklaruje że taki sposób kompresji jest wspierany nie mam podstaw by mu nie wierzyć

Teoretycznie fajne, ale dopóki każda licząca się przeglądarka/system operacyjny/inne oprogramowanie nie będzie tego formatu obsługiwać, to skończy on tak samo jak wszyscy inni pretendenci do tronu jpeg. Póki co w przypadku publikacji w sieci trzeba korzystać z javascriptowego dekodera, więc nie jest to rozwiązanie tak wygodne jak zwykły jpeg. A że stary poczciwy jpeg jest "wystarczająco dobry", to nieprędko zostanie wyparty. A dla tych co chcą czegoś nowocześniejszego, to jest googlowy WebP, który cieszy się dość szerokim wsparciem po stronie oprogramowania (większość przeglądarek go wspiera).

IMHO ciekawostką jest to, że bazuje na standardzie kompresji wideo, więc potencjalnie kodowanie/dekodowanie może być w dużej mierze sprzętowe.

Ale póki co to raczej ciekawostka do użytku prywatnego.

creologic,

Szum do bezstratności ma tylko tyle, że jej efektywność drastycznie maleje w jego obecności, a zatem "nie zapewnia równie dobrych wyników".

Na zdjęciu z piłkarzami, drobny wzór na zielonym pasie na piersi lewego gracza znika bezpowrotnie po zastosowaniu nowego kodeka. Jedyny format który pozostawia jakiś ślad tego wzoru to JP2K-Kakadu, i to przy porównywalnej wielkości plików: 84.1 KB przy BPG x-265 Large oraz 85 KB przy zastosowaniu JP2K-Kakadu. Szkoda że JPEG 2000 jest tak niepopularny.
Na razie Handbrake na Maca zaczął wspierać H.265.

@Bahrd,

teraz rozumiem co chcesz przekazać. Mylisz pojęcia - bezstratność nie może maleć - jest albo nie ma. Zależy to od algorytmu. Bezstratny algorytm kompresji to taki, który przedstawia informację na mniejszej ilości bitów, lecz zapewnia przy tym możliwość odtworzenia z postaci skompresowanej do identycznej postaci pierwotnej (oferuje ja np. format TIFF). Co innego kompresja stratna, stosowana np. w JPEG - tam współczynnik kompresji idzie w parze z degradacją sygnału źródłowego, nie da się zatem odtworzyć informacji w pierwotnej postaci.

Ciekawą sprawą jest także efekt, który opisałeś - zastanawiałeś się kiedyś dlaczego szum powoduje, ze skompresowane za pomocą JPEG zdjęcia zajmują więcej? W skrócie - fragmenty obrazu są dzielone na małe kwadraty (8x8 pikseli), informację o kolorze i jaskrawości w takiej porcji danych opisuje się za pomocą składowych harmonicznych otrzymanych w wyniku szybkiej transformaty Fouriera. Mocno upraszczając - im więcej kolorów jest do opisania, tym więcej składowych jest potrzebnych do złożenia sygnału, który będzie aproksymował oryginalny przebieg funkcji opisującej kolor i jaskrawość w pojedynczym obszarze. Im więcej składowych, tym więcej współczynników szeregu Fouriera do zapamiętania i tym mniej skuteczny algorytm kompresji. Od razu nasuwa się wniosek, że taka kompresja najlepiej sobie radzi z płynnymi przejściami między kolorami i jasnością obrazu. Łatwo to zaobserwować robiąc prosty eksperyment: bitmapę z gradientem kolorów (np. od jasnoniebieskiego po niebieski) zapisujemy jako jpg, po czym na tej bitmapie rysujemy czerwoną krechę i ponownie zapisujemy jako jpg. Jak porównamy rozmiary plików okaże się, że ten drugi jest zauważalnie większy. Ten sam efekt powoduje szum, o którym wspomniałeś.

Czy ktoś zna przeglądarkę graficzną która obsługuje tego typu pliki ?

Z jpg 7,7 MB zrobił się bpg 0,5 MB ;-) ale nie ma go czym wyświetlić ...

Tak, to był skrót niezręczny myślowy - "efektywność bezstratności" w miejsce "efektywność kompresji bezstratnej".

Współczynnik kompresji bezstratnej zależy od kształtu funkcji gęstości prawdopodobieństwa sygnału, którą szacujemy za pomocą histogramu.
Jeżeli histogram jest płaski, to współczynnik kompresji bezstratnej jest mały.
Jeżeli histogram jest skoncentrowany (w kształcie piku), to współczynnik kompresji bezstratnej jest duży.

Jeżeli funkcja autokorelacji sygnału jest impulsowa (jak w przypadku szumu), to współczynnik kompresji bezstratnej jest mały.

Zainteresowanych jak konwertować zdjęcia BPG do JPG zapraszam do tutoriala z przykładowymi ustawieniami kompresji:
link