MP: dcraw je v podstatě standard pro dekódování RAW, je možné, že tam je nějaká chyba (jako ve všech programech), ale nevěřím, že by ji Dave Coffin obratem neopravil. Já si také raději většinu věcí naprogramuji sám, ale proč, když dcraw jde velmi snadno použít pro získání surových dat? Není nutné ho nijak "míchat" s jiným programem - jen se zavolá a vrátí všechny metadata a/nebo surová data. Přijde mi škoda věnovat úsilí na to, co již (a velmi dobře) vyřešil někdo jiný a dal volně k dispozici.
Psion: to si úplně nerozumíme, já přece netvrdím, že mraw je zbytečný, když je tu dcraw. Dovoluji si nesouhlasit, že jsem něco přehlédl Já přece vůbec nezpochybňuji dávkové zpracování, to dcraw nedělá a nikdy nebude. Ano neumí převod do CR2 nebo BW TIFF, ale umí PGM a to by mělo stačit. A co se týká těch hotpixelů atd - jasně, pokročilejší zpracovaní surových dat nedělá, ale to přece zvládneme sami
TomasN: To jsem nepsal, že bys takovou věc tvrdil (zbytečnost mraw) ale jde spíš o to, zda dcraw funguje úplně korektně a zda není méně práce něco udělat znovu, než zdlouhavě studovat něčí kód (tak jako stavět nový dům, místo renovace nového).
PGM formát jsem nikdy nepoužíval a ani nevím zda astronomické programy s tímto formátem pracují. Navíc je vidět, že i Honza Špulák raději použil svůj SubRaw, než by používal něčí kód. Mimochodem jsem psal autorovi Nebulosity, že tento program neumí korektně aplikovat Fled field i když on tvrdí, že umí a nic opravovat asi nehodlá. Markův mraw to umí perfektně a v tom je ten rozdíl, proč si to někdo napíše raději sám.
To jsem nepsal, že bys takovou věc tvrdil (zbytečnost mraw) omlouvám se, to jsem špatně pochopil.
Myslím si, že dcraw funguje dobře. Používá ho přes 50 různých softwarů (třeba DeepSkyStacker) pokud tam nějaká chyba je, není problém Davidu Coffinovi napsat (sám jsem s ním něco řešil).
Jak jsem psal, dcraw se nemusí studovat. Je to připravené pro použití a - to je nejdůležitější - umí to načíst prakticky všechny RAW formáty. Ten PGM jsou jen binárně data, která slouží "pro přenos". Já nechci Markovi nic nutit, jen mi opravdu přijde škoda, aby se věnoval dekódování všech možných RAW, místo samotného zpracování dat - teď ho bude každý žádat o "svůj RAW" a s každým novým foťákem o další. A mluvím z vlastní zkušenosti, také jsem si napsal vlastní program na kalibraci, sám jsem si CRW nastudoval ... a teď používám dcraw, jsou to prakticky dva řádky v kódu.
Není nutné ho nijak "míchat" s jiným programem - jen se zavolá a vrátí všechny metadata a/nebo surová data.Vis, problem je v tom, ze dcraw Ti ta "surova" data neda. Tedy puvodni CFA mapu i s maskovanymi okraji pro histogram rozlozeni urovne cerne apod. Vystupem je uz "temer hotovy" obrazek, ktery je nam k nicemu, protoze nez ho z CFA dat vytvorime, musime na nej aplikovat DF a FF, ktere uz v tom CFA formatu zprumerujeme apod. Jinak by SubRAW ani MRAW nemely smysl, jejich kouzlo je prave v tom, ze kalibruji uz surova data pred jakymkoliv prevodem do cehokoliv.
Takze bych z dcrawu musel "vykuchat" jen to cteni souboru. A to je tam udelane dost komplikovane - jak uz jsem psal, je zavisle na typu fotaku, ktery zjistuje podle ruznych udaju z RAWu a pro kazdy tam ma nejake "speciality" natvrdo zakodovane, zatimco by se ty informace daly z RAWu zjistit primo, univerzalne, nezavisle na fotaku.
Priklad : EOS50D a asi i 5DMkII a 7D pouzivaji v LJPEG kompresi 4 "pseudoslozky", jako by byl obraz 4barevny, prestoze je to samozrejme CFA. Trochu se tim zlepsi komprese. Starsi Canony pouzivaji jen 2 slozky. Pro kodovani tech 4 slozek fotaky pouzivaji jen 2 Huffmanovy tabulky, kazda slouzi pro 2 slozky. A prirazeni tech tabulek je samozrejme zapsane v tom LJPEG streamu za SOS markerem. Jenze dcraw to nepouzije, ale priradi tabulky podle typu fotaku, to prirazeni je tam pro kazdy fotak natvrdo zakodovane. A v nekterych pripadech chybne. EOS50 si ovsem zjednodusuje situaci tim, ze ma obe tabulky stejne, takze to "nahodou" funguje. Ale zkratka zpusob, jakym dcraw dekoduje vstupni soubory, je hrozne tezkopadny a zavisly na fotaku, kdyz se objevi novy fotak, musi David Coffin pripsat novy kus dcrawu, zatimco MRAW bez uprav cte data zatim ze vsech fotaku s CR2 vystupem, co jsme tu zkouseli (pocatecni problem s EOS40 byl zpusoben mou programatorskou chybou).
Takze je opravdu slozite prevzit cteni souboru z dcrawu a navic bych riskoval, ze to budu muset stale menit (spolecne s D.Coffinem) pro kazdy novy fotak.
Abych nezapomnel, panove, dekuji za RAWy z EOS 300D i 1000D. Vsechno jsem stahnul, muzete to smazat. S EOS 1000D to podle ocekavani funguje, CRW bude samozrejme chtit jeste trochu programovani, vecer se na to vrhnu.
Vis, problem je v tom, ze dcraw Ti ta "surova" data neda. Tedy puvodni CFA mapu i s maskovanymi okraji pro histogram rozlozeni urovne cerne apod. Vystupem je uz "temer hotovy" obrazek, ktery je nam k nicemu, ...No to je to, co jsem se pokoušel říct - ta surová data dcraw dává. Vím to proto, že to používám a předpokládám, že ostatní programy taky. Samozřejmě uznávám, že můžeš mít nějaké důvody udělat to jinak.
No to je to, co jsem se pokoušel říct - ta surová data dcraw dává. Vím to proto, že to používám a předpokládám, že ostatní programy taky. Samozřejmě uznávám, že můžeš mít nějaké důvody udělat to jinak.
Citace z prispevku od MP
Takze bych z dcrawu musel "vykuchat" jen to cteni souboru. A to je tam udelane dost komplikovane - jak uz jsem psal, je zavisle na typu fotaku, ktery zjistuje podle ruznych udaju z RAWu a pro kazdy tam ma nejake "speciality" natvrdo zakodovane, zatimco by se ty informace daly z RAWu zjistit primo, univerzalne, nezavisle na fotaku.
Priklad : EOS50D a asi i 5DMkII a 7D pouzivaji v LJPEG kompresi 4 "pseudoslozky", jako by byl obraz 4barevny, prestoze je to samozrejme CFA. Trochu se tim zlepsi komprese. Starsi Canony pouzivaji jen 2 slozky. Pro kodovani tech 4 slozek fotaky pouzivaji jen 2 Huffmanovy tabulky, kazda slouzi pro 2 slozky. A prirazeni tech tabulek je samozrejme zapsane v tom LJPEG streamu za SOS markerem. Jenze dcraw to nepouzije, ale priradi tabulky podle typu fotaku, to prirazeni je tam pro kazdy fotak natvrdo zakodovane. A v nekterych pripadech chybne. EOS50 si ovsem zjednodusuje situaci tim, ze ma obe tabulky stejne, takze to "nahodou" funguje. Ale zkratka zpusob, jakym dcraw dekoduje vstupni soubory, je hrozne tezkopadny a zavisly na fotaku, kdyz se objevi novy fotak, musi David Coffin pripsat novy kus dcrawu, zatimco MRAW bez uprav cte data zatim ze vsech fotaku s CR2 vystupem, co jsme tu zkouseli (pocatecni problem s EOS40 byl zpusoben mou programatorskou chybou).
SW NWT 200/1000, HEQ5 SS, SW ref. 70/500
Tr. 8x30,10x50,20x50
Praktica Super TL, Sigma SD10, chlazený mod. Canon 350D s amp-off, EOS IX, FujiFilm S3Pro, upravená chlaz. TV kamera, Watec 902H3 Ultimate, obj. 10-300mm
Vím to proto, že to používám a předpokládám, že ostatní programy takyOstatni programy pouzivaji vetsinou "algoritmy dcrawu", tedy ty "vykuchane" casti. Vcetne CameraRaw - Adobe prevzalo casti kodu, ale treba tu chybu s prirazenim Huffmanovych tabulek tam maji opravenou a jdou na to jinak (logicteji). Na druhou stranu dcraw pouziva nektera data a algoritmy z SDK pro DNG konvertor. Takze proste vyvojari Adobe a David Coffin maji podobny pristup k dekodovani RAW souboru a tak je pro ne jednodussi pouzivat casti kodu jeden od druheho. Mne tento pristup nepripada nejstastnejsi a od zacatku jsem vstupni cast MRAWu koncipoval jinak, takze pro pouziti vstupni casti dcrawu bych to musel cele predelat.
No to je to, co jsem se pokoušel říct - ta surová data dcraw dává. Vím to proto, že to používám a předpokládám, že ostatní programy taky. Samozřejmě uznávám, že můžeš mít nějaké důvody udělat to jinak.
Tak už je večer.
Už to funguje?Smiley Smiley Smiley
;D
Psal jsem, ze se na to vrhnu a ne, ze to bude fungovat. Neco uz funguje. Ale nez to dam z ruky, musim to trochu dodelat a odladit.
