RAWy zupełnie nie potrzebne.

[muflon]

z wykształcenia jestem również matematykiem

:-D

Tylko DNG to.... Open RAW albo Adobe RAW. Raczej to drugie i stąd zapewne wstrzemięźliwość w używaniu. Canon, Nikon i inni nie chcą się uzależnić od Adobe bo... to Adobe

Tak, ale w perspektywie długoterminowej archiwizacji (czytaj: dłuższej niż cykl życia Photoshopa, C1 czy innego Aperture... "długoterminowej" mniej więcej w takim sensie jak Odra z punktu widzenia 2007) DNG to przede wszystkim pewność że takie zdjęcia będzie można odczytać (w sensie interpretacji danych, nie fizycznego nośnika) i za 50 lat. Bo format jest, jawny, otwarty, opisany, nie ma zgadywania współczynników do WB itp. Jedyne co się może zmienić to lepsze algorytmy interpolacji. I ktoś ten soft napisze, a nawet jeśli nie (wątpię - dcraw już powoli dogania komercyjne konwertery pod względem jakości "pikselowej", tylko kolory ciągle kuleją) to za drobną opłatą będzie można taką usługę zamówić u zaprzyjaźnionego geeka.

Wrócę jeszcze do tej Odry bo to w sumie fajne porównanie: załóżmy, że ktoś kiedyś napisał na nią fajną bibliotekę matematyczną, z rewelacyjnymi algorytmami, we w miarę sensownym FORTRANie. Czy, gdyby już mieć przeniesione dane z papierowych tasiemek/kart, byłby jakiś problem z jej użyciem teraz? Nie sądzę. Właśnie dlatego, że został użyty otwarty, udokumentowany standard.

Natomiast co do kompresji... ja myślę, że to co pisze Bahrd może mieć sens. Kompresja w CR2 jest mimo wszystko dość prosta, podejrzewam że odpowiednio mocną analizą (m.in. we wspomniane sposoby - osobne traktowanie różnych kolorów itp) dałoby się jeszcze trochę wycisnąć. Choć i tak CR2 daje radę :-D

[Janusz Body]

.....
Natomiast co do kompresji... ja myślę, że to co pisze Bahrd może mieć sens. Kompresja w CR2 jest mimo wszystko dość prosta, podejrzewam że odpowiednio mocną analizą (m.in. we wspomniane sposoby - osobne traktowanie różnych kolorów itp) dałoby się jeszcze trochę wycisnąć. Choć i tak CR2 daje radę :-D

Może mieć... Tylko piszemy o JPEG 2000 - format/kompresja istniejąca i wcale nie tak efektywna jak wielu sądzi. Kompresja skomplikowana i paskudnie woooooolna.

Jakby tej samej analizie poddać czarno-biały RAW (CR2 czy DNG) to zapewne też dało by się coś wycisnąć. Całe piękno i prostota zapisu RAW to pomysł o wyrzuceniu informacji o kolorze.

Jakby poddać mocnej analizie zdjęcie samolotu to może dało by się zapisać w paru bajtach Wystarczy nazwa, model, oznakowanie, kąt widzenia i odległość - resztę wyliczy sobie komputer

Przykład z Odrą i FORTRANEM jest o tyle fajny, że sam używam własnych procedur napisanych 30 lat temu jedyne co musiałem zrobić to "upgrade'ować" je do C++. Kiedyś maszyny były wolne i programista miał obowiązek myśleć Optymalizacja kodu, wybór metody matematycznej, minimalizacja zużycia pamięci - sztuka trochę zapomniana dzisiaj. Program, który na Odrze liczył się parę godzin mój pecet wypluwa po kilku sekundach odtwarzając jednocześnie muzykę Niestety nie powoduje to, u mnie, wzrostu pewności, że DNG za 35 lat da się odczytać. Za dużo złych doświadczeń miałem po drodze.

[muflon]

Jakby tej samej analizie poddać czarno-biały RAW (CR2 czy DNG) to zapewne też dało by się coś wycisnąć. Całe piękno i prostota zapisu RAW to pomysł o wyrzuceniu informacji o kolorze.

Piękno "ideologiczne" - tak, natomiast nie "piękno" w sensie kompresowalności. Mi prawdę mówiąc przy analizie plików CRW wręcz rzuciło się w oczy, że oni tą bezstratną kompresją jadą po kolei po pikselach, zamiast osobno przetwarzać składowe (po "siatce"). W tej chwili nawet już nie pamiętam czy to było bardziej Huffmanowate czy LZW, ale w każdym przypadku można by naprawdę sporo zyskać.

O JPEG2k czy innych wynalazkach się nie wypowiadam... bo uważam je za stratę czasu z powodów zupełnie innych niż kompresja ;-)

A Twój przykład z samolotem dałoby się na upartego podpiąć pod kompresję fraktalną Ale to nie bezstratne

[Bahrd]

[...]

O JPEG2k czy innych wynalazkach się nie wypowiadam... bo uważam je za stratę czasu z powodów zupełnie innych niż kompresja ;-)

Oj, sąsiedzi z EPFL z Lozanny też nie byliby zadowoleni z takiego stawiania sprawy

[bebesky]

łooooooooooo

kurcze

a njlepsze to jest to że wy wiecie co piszecie
dobrze zę jestem humanista

[Bahrd]

łooooooooooo

kurcze

a njlepsze to jest to że wy wiecie co piszecie
[...]

Masz racje, widać, że tylko humanista umie dostrzec i docenić ludzki czynnik ...

[wiktoch]

Wracając do meritum wątku i postawionej przez Janusza tezy – (jako amator) nie przepadam za obróbką RAWów ale doceniam i dostrzegam potencjał tkwiący w tym formacie. Dla przykładu – na weekend majowy wybrałem się na tygodniowy pobyt do Paryża. Do zwiedzania masę miejsc – w sumie przywiozłem po tygodniu ponad 700 klatek. Obróbka była męcząca i przede wszystkim CZASOCHŁONNA ale uzyskane efekty w wielu przypadkach - bezcenne. Zwłaszcza, że zdjęcia robiłem od świtu do zmierzchu, przy świetle sztucznym, zastanym, neonach, latarniach, lampach błyskowych itp. Myślę że w około 200 przypadkach korekta WB uratowała moje zdjęcia.
Być może jeżeli lepiej ustawiłbym poszczególne elementy z poziomu aparatu podobny efekt osiągnąłbym za pomocą JPG. Nie mniej jednak, IMHO dla amatora RAW jest jak najbardziej pożądanym narzędziem – pytanie tylko czy w każdej sytuacji i okolicznościach z niego korzystać? Najlepiej z pewnością wybrać rozwiązanie „gdzieś pomiędzy” – czyli nie ograniczać się wyłącznie do RAW albo tylko do JPG.

Pozdr
Wik


BTW - nie czemu niektórzy forsują twierdzenia, jakoby duża ilość zrobionych zdjęć (typu 500 dziennie) oznaczała ich niską jakość techniczną czy estetyczną? Czemu ilość nie może iść w parze z jakością? Czy jeżeli z mojego tygodniowego wypadu do Paryża przywiózłbym 35 zdjęć byłyby one "majstersztykiem"? Nie sądzę. Ja jestem zadowolony z każdego z siedmiuset pstrykniętych....

[Bahrd]

Kilka postów wyżej Janusz przedstawił kilka liczb:
RAW z 5D to około 11-19MB.
TIFF z RAWa z 5D to zawsze 72.8MB.
J2K z TIFFa z RAWa z 5D to około 45.8MB.

Zaiste, każdy normalny człowiek przegoniłby J2K z jakimś cenzuralnym słowem na p... i stwierdził bez zastanowienia, że zapewne w grupie roboczej ISO/IEC 15444-x na łby się pozamieniali tworząc taki "standart"?
RAW (aka CR2, NEF, DNG) rulez i koniec!

Ale nie wszyscy są normalni... Pierwsze co niepokoi, to rozmiar TIFFa. Skąd on się taki wziął? Policzmy:
4368*2912*12bit = 19 079 424B - tylko tyle wychodzi z matrycy 5D.
4368*2912*16bit = 25 439 232B - tyle potrzeba na jedną składową RGB

Razem: 3*25 439 232 = 76 317 696B ~ 72.8MB!
Czy coś zyskaliśmy? Bo na pewno straciliśmy ~50MB na dysku.
Niestety nic. A na domiar złego konwersja z RAW do TIFF nie jest bezstratna - bo polega na jakimś tam sprytnym oszustwie (demosaicing - z formalnego punktu widzenia taka konwersja mogłaby być bezstratna jedynie przy nierealnych założeniach).
Idźmy dalej: dlaczego w ogóle 16 bitów na kolor (czyli 48 na piksel)? Przecież RAW wie o pikselu tylko 12 bitów (plus kolor filtra). Bierze się to z potrzeby/chęci zachowania zakresu dynamicznego na zapas. Zapas ten oczywiście znika, gdy dokonamy konwersji do TIFF z 8 bitami na kolor.
No więc co jest na pozostałych 4 bitach? Szum.
I ten szum powoduje, że kompresja bezstratna TIFFa za pomocą J2K jest tak słaba. Ten szum jest też obecny na ostatnich z 12 bitów RAWa (liczba bitów zależy oczywiście od ustawienia ISO).

Rozwiązaniem jest nowy RAW, w którym obraz z matrycy jest kompresowany bezstratne, np. za pomocą odpowiednio dopasowanego J2K. To daje się zrobić. Co więcej, pewne szacunki wskazują, że wykorzystanie informacji o położeniu filtrów Bayera może dodatkowo kompresję (bezstratną) poprawić (nawet do 50% RAWa przy małych ISO). Wynika to z faktu, że przykładowe piękne czyste niebo przepuszczone przez filtr Bayera wygląda jak kratka (bo ani zielony, a już na pewno nie czerwony (sic!), nie przepuszczą niebieskiego).
Ale już brane osobno piksele spod poszczególnych filtrów wyglądają jednoliciej.

Oczywiście teoria to jedno, praktyka drugie, a rzeczywistość trzecie. Istnienie standardu de jure, i to w wersji ISO/IEC powinno być gwarantem jakości, ale widać, że główni gracze na rynku wybrali własne drogi. Co nie wyklucza, że za parę lat i za parędziesiąt megapikseli na matrycy problem nie wróci...

[KuchateK]

O ile sie nie myle, to J2K nie powstal do kompresji takich danych jakie wychodza z matrycy, wiec troche moze byc ciezko naginac go do tego zastosowania.

Sprytne algorytmy oszczedzajace miejsce to jedno, ale w puszkach przede wszystkim chodzi o szybkie zrzucenie danych z matrycy na karte, i czasem brutalnie pare bajtow wiecej jest szybciej transferowac jak przeliczac pomiedzy aby oszczedzic miejsce na karcie.

Nosniki zwiekszaja pojemnosc a cala reszta przyspiesza tak szybko, ze jakies skomplikowane optymalizacje nie maja dzisiaj sensu. Pakowac specjalizowany uklad do kompresji dla oszczednosci paru/parunastu procent to imho glupota nie majaca kompletnie uzasadnienia ekonomicznego. Jak by to bylo 50% zawsze (a nie tylko w przypadku fotografowania pieknego czystego nieba) to mozemy rozmawiac. A zrobienie tego programowo z racji "szybkich" algorytmow j2k odpada. Karty juz teraz pozwalaja robic duze ilosci zdjec na miniaturowych i bardzo tanich nosnikach, nawet przy monstrualnych rawach z wielomegapixelowych puszek. Ktos kto kupuje sredni format z pewnoscia moze sobie pozwolic na pare szesnastogigowek.

[Bahrd]

O ile sie nie myle, to J2K nie powstal do kompresji takich danych jakie wychodza z matrycy, wiec troche moze byc ciezko naginac go do tego zastosowania.

A do jakich?!? Oczywiście, że powstał!
Przykładowo: możesz w nim zapisać, że jedna składowa zaczyna się od 0,0 (lewy górny róg), druga od 0,1, trzecia od 1,0, ponadto, że dwie ostatnie są 2x rzadsze niż pierwsza i już masz Bayera.

Sprytne algorytmy oszczedzajace miejsce to jedno, ale w puszkach przede wszystkim chodzi o szybkie zrzucenie danych z matrycy na karte, i czasem brutalnie pare bajtow wiecej jest szybciej transferowac jak przeliczac pomiedzy aby oszczedzic miejsce na karcie.

Spójrzmy na to tak: 1D MkIII - RAW - 30 klatek do zapchania bufora, JPEG - 100 klatek. Czyli mimo, że obrabiasz dane w torze JPG, masz nadal 10kl/s ale 3x więcej klatek w serii. Robiąc lepszego RAWa (dajmy już spokój samemu J2K - alergenny jakiś ten standard) dostałbyś - zaryzykuję - 60 klatek. Spytasz dlaczego tak nie robią? Do powodów podanych w poprzednich postach dodałbym jeszcze jeden - nie ma aż tylu chętnych, żeby opłaciło się wprowadzać dużym kosztem R&D baardzo nowy standard, skoro można, korzystając z ulepszanej wciąż technologii produkcji układów scalonych, pykać po dwie, trzy klatki więcej w każdym nowym Mkxx, a ludziska i tak będą z zachwytu piać. Tak zresztą piszesz sam poniżej:

Nosniki zwiekszaja pojemnosc a cala reszta przyspiesza tak szybko, ze jakies skomplikowane optymalizacje nie maja dzisiaj sensu. Pakowac specjalizowany uklad do kompresji dla oszczednosci paru/parunastu procent to imho glupota nie majaca kompletnie uzasadnienia ekonomicznego.

Gdzie byłeś jak wprowadzali JPG?! Na pewno by go nie było przy takim nastawieniu (ja mam coś i mi to wystarcza, i koniec).
Poza tym można mieć ciastko i je zjeść: mieć szybsze pamięci, procesory, karty i większe matryce, i jednocześnie jeszcze więcej zdjęć (zrobionych i zapamiętanych). Przecież nie napiszesz, że "imho bez sensu jest wprowadzać nowy Digic IV, czy Extreme V, tylko dlatego, że działają 10% szybciej", nie?

Jak by to bylo 50% zawsze (a nie tylko w przypadku fotografowania pieknego czystego nieba) to mozemy rozmawiac. A zrobienie tego programowo z racji "szybkich" algorytmow j2k odpada. Karty juz teraz pozwalaja robic duze ilosci zdjec na miniaturowych i bardzo tanich nosnikach, nawet przy monstrualnych rawach z wielomegapixelowych puszek. Ktos kto kupuje sredni format z pewnoscia moze sobie pozwolic na pare szesnastogigowek.

Oczywiście, że niebo kompresuje się lepiej niż - nie przymierzając - trawa na boisku albo drzewa na tle tegoż nieba; to był przykład na to, żeby nie kompresować jak leci, tylko wykorzystać to, że wiemy, gdzie i jak umieszczone są filtry. Tak jak JPG umiejętnie kompresuje YCC a nie RGB.
No i spójrz teraz na to jeszcze z punktu widzenia archiwisty... albo gości od HCS w astronomii, czy biologii...