Nie wiem skąd wziąłeś tak wielkie liczby. U mnie na przykładzie:
http://raw.fotosite.pl/download-Cano...r/IMG_7511.CR2
RAW i J2K mają odpowiednio 16 i 17 MB. ta ostatnia liczba jest miarodajna tylko w tym sensie, że nie jest to podane przez Ciebie 46MB.
Dlaczego tylko w tym?
RAW przechowuje - jak wiadomo - kolejne piksle z dokładnością przetwornika A/D matrycy - w przypadku 5D jest to 12bit. Ja niestety nie poddałem kompresji zawartości matrycy, bo nie zrobię tego na cito z kilku powodów
- musiałbym pogrzebać w kodzie, żeby wyłuskać z CR2 gołe piksele i...
- teraz dopiero zaczyna się zabawa - wspomniana przez Ciebie niżej czysta matematyka, rzeczywiście mniej się przyda, ale za to matematyka stosowana już bardziej - otóż da się pokazać, że jeśli przed kompresją LZW/Hufmana/arytmetyczną odpowiednio przekształci się (bezstratnie) dane wejściowe, to efektywność kompresji będzie większa, niż gdyby operować danymi surowymi. I jedno z takich przekształceń stosuje się w J2K.
- I teraz można, ale nie trzeba, wykorzystać wiedzę o tym, że dane pochodzą z Bayera do tego, żeby osobno kompresować piksele pod zielonymi/czerwonymi/niebieskimi filtrami. Można też z tej wiedzy nie korzystać i kompresować punkty bez rozróżniania kolorów nałożonych na nie filtrów - to należałoby sprawdzić. Dlaczego o tym piszę - otóż ja - z braku wspomnianego konwertera przerobiłem CR2 do TIFFa (38MB) i dopiero do J2K.
- W ten sposób nie wykorzystałem (1) wspomnianej wyżej możliwości osobnej kompresji składowych, ale także faktu, że (2) przed matrycą jest filtr dolnoprzepustowy, który z definicji poprawia efektywność algorytmów kompresji z transformacją danych.
Oczywiście - kolory to był - przyznaję - mój niefortunny skrót myślowy.
Ja też uważam, że każdy bajt gra rolę - i cieszę się, że doświadczeńsi w fotografii również.
Użyłem słowa "wspaniałych"? Niedobrze - to świadczy o moim zatraceniu dystansu do problemu...A poważnie(j): jest wiele innych przyczyn, które - jak się wydaje - miały decydujący wpływ:
- złożoność algorytmu - w sensie wzorów i długości opisu standardu: JPG przy J2K to temat na zajęcia w przedszkolu o profilu mat-fiz.
- złożoność obliczeniowa - szacuje się, że implementacje programowe są ok. 5x wolniejsze. Ze sprzętowymi lepiej (szybkość porównywalna kosztem obszaru na płytce), ale patrz uwaga wyżej.
- A z mniej oficjalnych przyczyn: sprawa patentów - ponoć wielcy odpuścili sobie J2K, bo ma status 'royalty free' a nie 'patent free' - nie znam żadnego produktu, który byłby sprzedawany masowo z J2K - tak więc J2K nie jest martwy, bo w gruncie rzeczy - nawet się nie narodził... Kolejna - można rzec - śmieszna - przyczyna, to taka, że ISO konstruując standard "zapomniało" rozważać jako kryterium skutki implementacyjne - stąd owa złożoność i brak wzorcowych implementacji sprzętowych.
Tu jestem optymistą - tzn. w sprawie lepszej kompresji, bo Nobla za obrazki to raczej szacowne grono sawantów nie będzie w stanie przyznać.
PS
Cieszę się, że ten wątek został podjęty, i cieszę się, że uzyskałem dzięki niemu nieco inny punkt widzenia na sprawę. Nie zamykając ze swej strony dyskusji - dziękuję.
Dodane:
Dopatrzyłem się, że linkowany przez mnie RAW ma mniejszą rozdzielczość niż 12.8MB - nie zwróciłem na to uwagi, bo miał "przepisowe" 16MB...
Ale sprawdziłem na CR2 z 350D mój plik miał 9MB i prawie tyle samo w J2K.
Jeśli ktoś zechciałby podzielić plikami CR2 w 5D w pełnej rozdzielczości, to proszę o kontakt. Nie omieszkam przedstawić wyników.
!!! Łączenie podwójnego wpisu !!!
http://www.rytterfalk.com/sd14/atira...icturepack.zip
tu - odpowiednio (dla IMG_9541.cr2):
12303KB - RAW
11562KB - J2K
przy niedoskonałej metodologii podanej w powyżej.