"Marek Dyjor" i540tr$it0$...@n...onet.pl

> A teraz napisz mi co jest w pliku RAW, a potem napisz mi czemu tyle mocy
obliczeniowej potrzeba aby z tego RAWa zrobić normalny
> plik graficzny, skoro RAWA nie trzeba przetwarzać.

0. Specyfikację CR2 można znaleźć w internecie.
(inna sprawa, że CR2 nie jest zawsze takim samym CR2)

1. Każdy RAW ma swój własny zapis -- nie jest to
format uniwersalny, choć i JPG, BMP, TIFF, PNG
itp. bitmapy nie do końca są zunifikowane.

2. Ile tej mocy potrzeba? Chyba tylko do odszumienia
jest potrzebna jakakolwiek wielka moc obliczeniowa.
Niektóre przeglądarki graficzne radzą sobie z CR2
bez trudu -- nie z JPG umieszczonymi w CR2, ale
z samymi RAWkami. Aparat wprawdzie traci bardzo
dużo czasu na zapisanie JPG, ale dlatego, że ma
między innymi odszumianie i kompresowanie do JPG.
Sama zamiana CR2 w JPG, TIFF czy jakikolwiek prosty
format zapisu bitmapy nie pochłania wielkich mocy
obliczeniowych, co łatwo zobaczyć choćby oprogramowaniem
Canona pokazującym zawartość CR2 bez odszumiania.
Odszumianie jest czasochłonne -- wymaga analizowania
zapisu, nie jest prostą konwersją z formatu na format.
Podobnie rzecz się ma z kompresją stratną do JPG, gdzie
też trzeba analizować całe zdjęcie.

Bywa tak, że rozkompresowanie (konieczne do wyświetlenia na
ekranie) cwanie skompresowanego JPG zajmuje kilka razy więcej
czasu niż wyświetlenie zawartości nieodszumianego CR2. Oczywiście
odszumianie CR2 nie dokonuje się raz na zawsze, ale za każdym razem
(przy każdym wyświetlaniu) trzeba je ponawiać. W JPG po prostu zapisuje
się odszumiony obraz -- ponowne odszumianie nie jest więc potrzebne, ale
i powrót do sytuacji sprzed odszumienia nie jest już możliwy. I nie dlatego,
że JPG to stratna kompresja, czasami bardzo cwana, ale z innego powodu -- BMP
bez kompresji też nie pozwala na powrót do sytuacji sprzed odszumienia.



Proponuję sprawdzenie -- ile czasu zajmuje wyświetlenie:

-- odszumionego CR2
-- tego samego, ale nieodszumionego CR2

-- BMP
-- JPG powstałego z tegoż BMP

Widać wyraźnie, że żadne piekielne moce obliczeniowe nie są potrzebne
do wyświetlenia BMP (piksel przechodzi na piksel niemal bez przeliczeń)
ale już wyświetlenie JPG jest czasochłonne. O wiele bardziej czasochłonne
jest kompresowanie BMP do JPG niż dekompresowanie JPG do widzialnej postaci,
gdyż dekompresja może postępować jedyną, zapisaną w pliku JPG drogą, zaś
kompresować można na wiele sposobów, czyli przed kompresją należy podjąć
decyzję co do wyboru metody optymalnej przy narzuconych założeniach.

Widać też, że jakikolwiek zapis do JPG trwa znacznie dłużej niż do BMP,
choć sam plik wynikowy jest znacznie mniejszy w JPG, czyli i czas
potrzebny na samo zapisanie na dysku jest krótszy w JPG niż w BMP.
Dłuższy zapis bierze się właśnie z konieczności kompresowania.


I widać też, że wyświetlenie CR2 nieodszumionego (suwaczki odszumiania
na zero) trwa niepomiernie krócej niż odszumionego, i że każde ponowne
wyświetlenie (poza sytuacjami, gdy coś brane jest z keszów procesora
czy dysku) odszumionego CR2 trwa dokładnie tyle samo, czyli za każdym
razem odszumianie jest dokonywane od początku.

-=-

Odszumianie BMP, zmiana w nim kolorów, na przykład zmiana balansu bieli
itp. czynności trwają także długo -- nie tylko odszumianie CR2 zajmuje
czas. Problem w tym, że w CR2 każde wyświetlenie powoduje odszumianie,
podczas gdy JPG wymaga odszumienia tylko raz. Wyświetlenie mocno i cwanie
skompresowanego JPG także pochłania moce obliczeniowe, może nawet czasami
większe niż wyświetlanie CR2 -- każde wyświetlenie JPG wymaga dekompresji.

--
.`'.-. ._. .-.
.'O`-' ., ; o.' eneuel@@gmail.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....