| Forum: / Fotografia cyfrowa 2008 / PEF -> RAW |
| << . 1 . 2 . |
| Autor | Wiadomość |
| Radio Erewan
|
Posted: 24 Lip 2008 14:11:23 W specyfikacji formatu DNG pewnie jest opisana metoda
kompresji danych grafcznych ale moze programisci Pentax-a nie zaimplementowali jej. Jaka by nie by?a owa metoda, pewnie niezgodna z tym, co potrafi dedykowany uk?ad kompresuj?cy Pentaxa. Pozdrawiam |
| M
|
Posted: 24 Lip 2008 15:52:35 Na CS nie zainstaluje ACR, który otwiera PEFy (uda si? tylko na CS3).
Jedyna metoda przy starym PS to to co poda? Titus. Wiem o DNG konwerterze, ale mam w?tpliwo?ci co do s?ów "bezstratnie". Znajomy mi kiedy? opowiada? jak to cudowny ten program jest, bo na ka?dym rawie z A700 oszcz?dza po kilka mega. Co? wi?c traci? po drodze trzeba, skoro wynik jest mniejszy od i tak ju? skompresowanych rawów z A700. A prefka w tym A700 jest jaka? Mo?e oszcz?dza na wielko?ci JPG-a wgl?dówki w ?rodku. Poza tym aparat mo?e mie? inny algorytm kompresji, wymagaj?cy mniej zasobów aparatu ale za to mniej skuteczny ni? DNG. M. |
| JoannElle
|
Posted: 24 Lip 2008 18:58:54 Dzi?ki za pomoc w kombinowaniu, wkurzy?am si? i ju? mam CS3. Tak wi?c problemy z otwieraniem PEF-ów nale?? do przesz?o?ci :) Pozdrawiam i dzi?ki jeszcze raz, JoannElle |
| gietrzy
|
Posted: 24 Lip 2008 19:30:39 Dzi?ki za pomoc w kombinowaniu, wkurzy?am si? i ju? mam CS3. Tak wi?c
problemy z otwieraniem PEF-ów nale?? do przesz?o?ci :) Ja bym wola? jakiego? Limiteda ;) pozdrawiam, gietrzy ps. Czy przypadkiem CS4 nie jest za rogiem? |
| JoannElle
|
Posted: 24 Lip 2008 19:55:16 Dzi?ki za pomoc w kombinowaniu, wkurzy?am si? i ju? mam CS3. Tak wi?c
problemy z otwieraniem PEF-ów nale?? do przesz?o?ci :) Ja bym wola? jakiego? Limiteda ;) pozdrawiam, gietrzy ps. Czy przypadkiem CS4 nie jest za rogiem? Wrrrr... ;) |
| Radio Erewan
|
Posted: 24 Lip 2008 19:58:25 Ja bym wola? jakiego? Limiteda ;)
pozdrawiam, gietrzy ps. Czy przypadkiem CS4 nie jest za rogiem? Jeszcze kilka miesi?cy. Stawiam na stycze? 2009, cho? mo?e b?dzie wczesniej (na ?wi?ta?). Ch?opaki zw?aszcza na Maca maj? problemy ze zmian? polityki Apple. CS4 nie b?dzie wspiera? dla makówki 64 bitów. S? nawet w?tpliwo?ci, czy uda si? to w CS5. Pozdrawiam |
| Ninik
|
Posted: 24 Lip 2008 20:10:46 Póki co interesuje mnie porównanie 10mpix sonego z 10Mpix olka - tak ?e
dok?adnie - jakie wielko?ci plików RAW osi?ga olek w swoich 10Mpix? Jak znasz wielko?ci to prosz? te? o parametry 10Mpix nikona (patrzy?em szybko w specyfikacji na dpreview i niestety nie by?o). To sobie popatrz na E3 albo E510 na raw.fotosite.pl Np. tu: http://raw.fotosite.pl/index-Olympus_E-510_and_Almost_All_Lenses_part3_by_RadioErewan.htm http://raw.fotosite.pl/index-Sony_A100_different_lenses_aperture_4-5.6-8.htm Co do A100 to doskonale zdaj? sobie spraw? z wielko?ci plików, tak w?a?ciwie to mnie zlinkowa?e? i mój widok z okna ;) No i oczywi?cie siebie je?li chodzi o olka. Ciekawie w ?wietle wydajno?ci kompresji wygl?daj? wyniki A700.
http://raw.fotosite.pl/index-Sony_A700_Sigma_30_f1.4_by_gen0typ.htm A700 te? mam, wi?c te? doskonale zdaj? sobie spraw? z wielko?ci plików jakie produkuje. Najmniejszy (zwyk?y) RAW jaki uda?o mi si? uzyska? mia? 6MB, najwi?kszy natomiast mia? 24MB. Wszystko zale?y od sceny. bo z aparatu mo?e p?yn?? wi?cej informacji, producent wie dok?adnie
jakich i w jakim formacie, mo?e wi?c optymalniej zaplanowa? sobie swoje pliki. Taki w?a?nie stworzyli. To jest koperta, wewn?trz której mo?esz umie?ci? du?e spektrum informacji. Nic wielce odkrywczego.. Ale mowa o tym, ?e z wszechmiar jest o wiele lepiej. innymi s?owy czy je?li przekonwertuj? przyk?adowo ARW-DNG i potem
DNG-ARW to czy otrzymam dok?adnie ten sam plik z tymi samymi informacjami. Nie przekonwertujesz z DNG do ARW, chyba ?e dopniesz do DNG orygina?. Je?li mamy do czynienia z bezstratn? konwersj? to takie co? musi by? mo?liwe, ale przy tym co piszesz to w takim wypadku nie zajmuje o wiele mniej miejsca. I wtedy DNG b?dzie mniejszy? ..bo troch? w?tpi?..
Przypominam ?e rozmawiamy o bezstratnej konwersji (nie kompresji). Dodatkowo rzuci?e? tez?, ?e ARW w sonym s? kompresowane gorszym algorytmem ni? DNG i ró?nice s? spore. Oczywi?cie, ?e nie. To jest opcja dla niedowiarków. Czyli? Jeszcze raz zapytam - czy DNG zajmuje wtedy mniej ni? orygina? raw?
Po co mi DNG, je?li ma jeszcze bardziej opakowywa? rawy i jeszcze puchn?? w rozmiar? http://raw.fotosite.pl/index-Sony_A700_Sigma_30_f1.4_by_gen0typ.htm Pierwsze zdj?cie: 19 123 456 - 11 738 756 i z tego katalogu pierwsze http://raw.fotosite.pl/index-Sony_A100_KM24-105_3%2C5-4%2C5_wnt.htm 8 546 088 - 8 120 520 Czy mo?esz poda? dok?adne dane dotycz?ce konwersji? Ile wybra?e? bitów, jakie miniaturki itd? W przypadku sonego masz teraz do wyboru RAW i cRAW. Pierwszy zapisuje 12bitów i to kompresuje bezstratnie. Czyli przychodzi z matrycy 12bitów i zostaje tymi dwunastoma bitami. Natomiast cRAW dzia?a troch? inaczej - podobnie jak w JPG obraz jest dzielony na celki, zapisywane jest to co najja?niejsze i najciemniejsze, a potem reszta jako ró?nica wobec tych pikseli. Dzi?ki temu w przypadku scen z ma?? dynamik? obraz nie ró?ni si? czymkolwiek od normalnych rawów. W przypadku du?ej dynamiki cz??? informacji jest gubiona, bo ró?nice s? zapisywane na 8bitów (z 12bitów). Ró?nica w jako?ci nie jest tak znów wielka, wi?kszo?? jej nie zauwa?y, nawet w bezpo?rednim porównaniu, do tego trzeba te? mie? odpowiednie zdj?cie by widzie?. Cudów jednak wielkich nie ma. Je?li DNG ma podobny zapis danych do pierwszego, to o wiele lepiej te? nie b?dzie potrafi? skompresowa? sobie danych ni? to co w sonym, je?li ma podobn? reprezentacj? do drugiego i koduje na 12bitach (?eby by?o bezstratnie), to b?dzie musia? by? wi?kszy. Z tego co przeczyta?em to wykorzystywana jest kompresja huffmana, czyli taka która wymaga s?ownika (lub jego wygenerowania). W przypadku testów jakie kiedy? zrobi?em (po w?asnym zaimplementowaniu sobie algorytmu w najbardziej ogólnej postaci) wychodzi?o, ?e jest gorzej w stosunku do LZH (czyli takiego jak w zipie, ale testowa?em rzecz jasna te? sobie pisany program). Z tego co czyta?em w przypadku zdj?? sytuacja jest odwrotna. LZH ma za to wielk? zalet? - nie wymaga konstruowania s?ownika, wi?c pewnie ?atwiej zrobi? go sprz?towo (nie trzeba analizowa? danych przed kompresj?). St?d DNG mo?e rzeczywi?cie by? co?tam lepsze. Nie s? to jednak ró?nice bardzo du?e, je?li to co pisa?em jest prawd? i czego? nie przeoczy?em. Ty za to przeoczy?e? wa?n? spraw? - sony zaszywa kilka podgl?dów w pliki. W przypadku A100, jest to conajwy?ej na ekran aparatu (0,02Mpix - 160x120) i telewizora (co? 0,3Mpix - nie pami?tam ju? ile to jest). Dodatek jest wi?c ma?y i nieistotny. W przypadku A700 zaszyte masz jednak ca?kiem spore zdj?cie w fullHD czyli co? 1660x1080 a to ju? troch? wa?y, do tego mianiaturki do wszystkich szybkich podgl?dów w aparacie (czyli conajmniej 5-6 rozmiarów) i pewnie co? jeszcze. Móg?by? wi?c trafi? na zdj?cie które ma np 18MB w RAW, 11MB w cRaw i 10MB w DNG, tyle, ?e ten ostatni nie zawiera tych dodatkowych danych i jakby je wyci?? to mog?oby si? okaza?, ?e cRAW jest mniejszy. Napisz mi prosz? dok?adne dane dotycz?ce skonwertowanych DNG - ile bitów wykorzystuje (te które konwertowa?e?), czy i co do??czy?e?. Wtedy bedzie mo?na to mo?e jako? bardziej rzetelnie porówna? je?li chodzi o rozmiar. Osobi?cie mimo wszystkich rewelacji wol? zwyk?e rawy. karty pami?ci dzisiaj tanie :) Sony oczywi?cie twierdzi, ?e cRAW daje bezstratnie obraz, ale po lekturze ?róde? dcraw nie bardzo mi si? tak wydaje i chocia? ró?nicy wielkiej w porównaniu do RAW nie widz? to jak wspomina?em - kart nie oszcz?dzam. |
| Ninik
|
Posted: 24 Lip 2008 20:26:03 A prefka w tym A700 jest jaka? Mo?e oszcz?dza na wielko?ci JPG-a
wgl?dówki w ?rodku. Jest ich conajmniej kilka - najwi?ksza jest pod fullHD czyli do 1920x1050, do tego jeszcze mniejsze do szybkiego podgl?du i takie tam. Poza tym aparat mo?e mie? inny algorytm kompresji, wymagaj?cy mniej
zasobów aparatu ale za to mniej skuteczny ni? DNG. Oczywi?cie, ?e mo?e mie? gorsze, ale ile? Stosuj?c najprostsze algorytmy kompresji i tak zysk nie b?dzie tak znów wielki, no chyba ?e gdzie? po drodze zaczn? si? straty, których "w 99% przypadków nie wida?" ;) |
| Dariusz W.
|
Posted: 24 Lip 2008 20:43:27 Witaj ! Wypada tez czytac post, na ktory sie odpowiada. I nie udzielac nieprecyzyjnych podpowiedzi. TA A mozesz mi wyjasnic ta moja nieprecyzyjnosc i skad mam wiedziec jaka wersje PSHOPA ma pytajacy ? |
| Radio Erewan
|
Posted: 24 Lip 2008 20:59:59 A mozesz mi wyjasnic ta moja nieprecyzyjnosc i skad mam wiedziec
jaka wersje PSHOPA ma pytajacy ? Pozdrawiam |
| Dariusz W.
|
Posted: 24 Lip 2008 21:16:28 Witaj ! Cudów jednak wielkich nie ma. Jesli DNG ma podobny zapis danych do
pierwszego, to o wiele lepiej tez nie bedzie potrafil skompresowac sobie danych niz to co w sonym, jesli ma podobna reprezentacje do drugiego i koduje na 12bitach (zeby bylo bezstratnie), to bedzie musial byc wiekszy. Z tego co przeczytalem to wykorzystywana jest kompresja huffmana, czyli taka która wymaga slownika (lub jego wygenerowania). W przypadku testów jakie kiedys zrobilem (po wlasnym zaimplementowaniu sobie algorytmu w najbardziej ogólnej postaci) wychodzilo, ze jest gorzej w stosunku do LZH (czyli takiego jak w zipie, ale testowalem rzecz jasna tez sobie pisany program). Z tego co czytalem w przypadku zdjec sytuacja jest odwrotna. LZH ma za to wielka zalete - nie wymaga konstruowania slownika, wiec pewnie latwiej zrobic go sprzetowo (nie trzeba analizowac danych przed kompresja). Stad DNG moze rzeczywiscie byc costam lepsze. Mysle, ze niekoniecznie lepszy. Kompresja graficzna danych z aparatu to specyficzne dane o odpowiedniej rozpietosci tonalnej. Algorytmy uzywane w aparacie sa zazwyczaj bardziej wydajne niz pakowanie niespakowanego pliku RAW archiwizerem RAR czy jakis inny pakierem danych. Jak w kompresji uwzglednic budowe sensora i specyfiki jego pracy okazuje sie, ze sensor widzi... monochromatycznie a specyfika obrazu jest mniej doskonala niz sie moze wydawac co stanowi dobry kasek dla latwiejszego upakowania danych graficznych. Mozna uwzgledniac wczesniej przygotowane wzorce tablice kompresji w algorytmach okreslajace strefy wystepowania jasnych i ciemnych obszarow. Zazwyczaj mamy powtarzajace sie elementy nieba i cieni w dolnych obszarach zdjecia. Idac ta droga ambitny programista wycisnie z obrazu z matrycy max... mozliwosci do zapisania nieco krocej to co inne kompresory DO WSZYSTKIEGO poradza sobie dobrze ale nie do konca ;) |
| Dariusz W.
|
Posted: 24 Lip 2008 21:35:55 Witaj ! Przy okazji odpowiem Ninikowi, ze od E400 RAWy w Olkach sa kompresowane.
Gorzej jak w Canonie (mniej skutecznie), ale to niewielka róznica. Canon daje nieco... bardziej miekki obraz w RAW-ach co sprzyja lepszej kompresji. W Olku E-410 sa kompresowalne RAW-y a algorytm liczacy wolne miejsce na karcie pamieci jest UWALONY bo wolne miejsce liczy dla nieskompresowanego RAW-a a zapisuje spakowane dane znacznie krotsze. Blad... wychodzi bliski 50% czyli... wielka obliczeniowa lipa zaserwowana przez specow od Olka ;) Zglosilem ten problem na forum Olympusa ale nie spotkalem sie ze zrozumieniem bo wyszlo na to ze sie czepiam... ;) A do dzisiaj nadal nie poprawili tego choc juz minelo troche czasu ;) |
| Ninik
|
Posted: 24 Lip 2008 22:25:36 odwrotna. LZH ma za to wielka zalete - nie wymaga konstruowania
slownika, wiec pewnie latwiej zrobic go sprzetowo (nie trzeba analizowac danych przed kompresja). Stad DNG moze rzeczywiscie byc costam lepsze. Mysle, ze niekoniecznie lepszy. Nigdy nie ma z?otego grala i jedynego s?usznego algorytmu. Chocia?by proste sortowanie - wymy?lono tego tyle, ?e ci??ko pozna? wszystkie metody. Najgorsz? ksi??kowo jest sortowanie b?belkowe, najlepszy jest niby quicksort. Ten drugi ma jednak jedn? z wielkich pi?t achillesowych - nie znosi sortowa? danych ju? posortowanych - w takim wypadku z?o?ono?? obliczeniowa jest AFAIR nielepsza od tych nieszcz?snych b?belków. S?k w tym, ?e do?? cz?sto mamy dane bardzo zbli?one do zupe?nie posortowanych, wi?c paradoksalnie aby quick sort dzia?a? w miar? szybko bez zb?dnego ryzyka wystarczy mu na start troch? losowo poprzestawia? dane dzi?ki czemu nie trafi si? nam nieszcz?sny przypadek w którym oka?e si?, ?e sortowanie trwa i trwa... Tutaj mo?e by? tylko podobnie - mamy dane, mamy jakie? algorytmy, nawet je?li uwzgl?dnimy absolutnie wszystko, to si? oka?e, ?e b?dzie przypadek, który po spakowaniu na z?o?? jeszcze przybierze w rozmiar. Mo?e niecz?ste to b?dzie ale te? jest mo?liwe. Kompresja graficzna danych z aparatu to specyficzne dane
o odpowiedniej rozpietosci tonalnej. Algorytmy uzywane w aparacie sa zazwyczaj bardziej wydajne niz pakowanie niespakowanego pliku RAW archiwizerem RAR czy jakis inny pakierem danych. Je?li tylko rzeczywi?cie zapisujesz jakie? losowe dane bez wyra?nej ukrytej gdzie? regularno?ci której nie wychwyci taki program (jak np ?e zapisujesz plik + odwrócony plik co mo?na ?atwo skróci? do po?owy) to te algorytmy bardzo fajnie sobie poradz? z nim. S? wyszkolone w tym by wykrywa? wszelkie powtórzenia i zapisywa? je mo?liwie najkrócej. Je?li tylko twórcy nie pope?nili jakiego? powa?nego b??du zapisuj?c niepotrzebne dane które ?atwo mo?na odci?? to nie wierz? w tak spor? ró?nic? przy przepakowaniu do DNG i bezstratnie. To jak sony t?umaczy cRAW jako absolutnie bezstratny. I takim jest w 95% przypadków rzeczywi?cie, w pozosta?ych 4% strata jest niewielka a w 1% jedynie zauwa?alna, ale mimo wszystko jest to STRATNY FORMAT DANYCH. ps. a spakowanie rarem czy zipem rawa daje czasem mniejszy plik. Czasem wi?kszy ;) Jak w kompresji uwzglednic budowe sensora i specyfiki jego
pracy okazuje sie, ze sensor widzi... monochromatycznie a specyfika obrazu jest mniej doskonala niz sie moze wydawac co stanowi dobry kasek dla latwiejszego upakowania danych graficznych. Musia?by? pope?ni? powa?ny b??d zapisuj?c nadmiar danych w rawie, a o to nie pos?dzam kogokolwiek. Mozna uwzgledniac wczesniej przygotowane wzorce tablice kompresji w
algorytmach okreslajace strefy wystepowania jasnych i ciemnych obszarow. Zazwyczaj mamy powtarzajace sie elementy nieba i cieni w dolnych obszarach zdjecia. A potem jak trafisz zdj?cie z czym? innym to albo Ci je popsuje, albo wyjdzie conajmniej wi?ksze ni? bez takich udziwnie?. Jedynego s?usznego i rozs?dnego rozwi?zania nie ma. Co wi?cej wiele algorytmów ma jakie? parametry i przy ró?nych danych wychodz? ró?nie wielkie pliki. Przyk?adowo w?a?nie w algorytmie huffmana trzeba zapisa? s?ownik, w tym wybra? sobie ile bitów ma mie? i takie tam. Przy ró?nych warto?ciach wychodzi lepiej lub gorzej, ale by si? przekona? ile dla konkretnego obrazka musia?by? przeliczy? plik kilka razy. Zysk b?dzie niewielki w stosunku do nak?adu mocy obliczeniowej. Z tego co dzi? wyczyta?em ogólnie sam algorytm lepiej nadaje si? do grafiki (dlatego jest w DNG, ale np w tekstach sprawdza? si? gorzej od LZH). Nie sa to jednak z pewno?ci? ró?nice si?gaj?ce 100%. Idac ta droga ambitny programista wycisnie z obrazu z
matrycy max... mozliwosci do zapisania nieco krocej to co inne kompresory DO WSZYSTKIEGO poradza sobie dobrze ale nie do konca ;) Przy sprz?towej kompresji jest kilka ogranicze?, przyk?adowo niewskazane s? raczej sprawy typu analizujemy dane, potem kompresujemy, dlatego w?a?nie nie stosuje si? pewnie tej kompresji co w DNG (która takiego ograniczenia nie musi mie?, bo procesora jest pod dostatkiem). W wyciskanie resztek z obrazu wierz?, ale im bardziej wymagaj?cy b?dzie algorytm dla procesora, tym trudniej b?dzie go zrobi? sprz?towo, do tego zapis trwa? b?dzie znacznie d?u?ej, a sko?czywszy na tym, ?e trafi si? przypadek taki, ?e mimo, ?e mia?o by? o wiele lepiej wysz?o co? znacznie wi?kszego ;) |
| << . 1 . 2 . |
|
Aparaty cyfrowe - cyfrówki, w ostatnich latach szturmem podbiły nasze strzechy. W zalewie modeli, nowych technologii i oznaczeń, jak ciężko wybrać wymarzony aparat, wie nie jeden.
Dyskusja o aparatach, jakie wybrać a z jakich zrezygnować. Co zrobić by zdjęcia można było nazwać perełkami, co zrobić gdy coś nie wychodzi a powinno..
Na te inne pytania na pewno znajdziesz tutaj odpowiedź, wystarczy poszukać... Czas ładowania strony (sek.): 0.652 miniBB.net © 2001-2008 |Polityka Prywatności °infobi °multilan °virtuti militari °ogłoszenia
|