Użytkownik "Stefan Nawrocki" <o...@3...com.pl> napisał w wiadomości
news:hemlrc$2cbm$1@alfa.ceti.pl...
>

> O konwersji na HSB w kontekście kompresji jpg do tej pory nie słyszałem.
> Z tego, co wiem, to kompresja jpg przebiega w kilku krokach. Jednym z kroków
> (opcjonalnych) jest konwersja RGB na YCrCb. W tej przestrzeni mamy składową
> Y odpowiedzialną za luminancję i dwie składowe koloru.
Chyba faktycznie pokręciłem nazwy. Chodziło mi o jedną składową luminacji i dwie
kolorów.
Również w konwersji RGB->YCrCb->RGB nie zawsze wrócimy do tego samego koloru.

Pozdrawiam
Wojtek

do góry

Użytkownik "Wojtekk" <u...@w...pl> napisał w wiadomości
news:hempbf$kv0$1@srv.cyf-kr.edu.pl...
>
> Użytkownik "Stefan Nawrocki" <o...@3...com.pl> napisał w wiadomości
> news:hemlrc$2cbm$1@alfa.ceti.pl...
> >
>
> Również w konwersji RGB->YCrCb->RGB nie zawsze wrócimy do tego samego
koloru.

Konwersja RGB->YCrCb i YCrCb->RGB jest matematycznie jednoznaczna. Co
najwyżej mogą powstać błędy zaokragleń. Istota "stratności" kompresji jpg
polega na tym, że składowe Cr i Cb są celowo uśredniane dla określonego
bloku pikseli. Strata wynika z założonego działania, a nie z błędów
zaokragleń.


Pozdrawiam
Stefan Nawrocki

do góry

Użytkownik "Stefan Nawrocki" <o...@3...com.pl> napisał w wiadomości
news:hemqub$2g8j$1@alfa.ceti.pl...

> Konwersja RGB->YCrCb i YCrCb->RGB jest matematycznie jednoznaczna. Co
> najwyżej mogą powstać błędy zaokragleń.
Konwersja jest jednoznaczna w systemach analogowych. W systemach cyfrowych
kolory zapisywane są liczbami całkowitymi. Po zaokrągleniu wyników do liczb
całkowitych duża część kolorów zaczyna się dublować.
Z ciekawości policzyłem kolory po konwersji RGB->YCrCb: z 16777216 kolorów w RGB
zostaje 4007187 kolorów w YCrCb (standard JFIF-Y'CbCr 601).

Pozdrawiam
Wojtek

do góry