Hromadný převod RAW snímku do JPG s rekurzí (diskuse)

[Konqui]

Dost velká prasárna Očividně dotyčný přečetl o Pythonu pouze nějaký tutoriál...

[Luboš Doležel (Doli)]

OMG, v Bashi by to bylo stokrát snazší

[paralaX]

V bashi by to bylo super! V tom se docela vyznám (rozuměj, že nemám problém chápat o co tam jde) a rád se v něm vrtám. Ale když jsem googlil "recursive directory traverse" (nebo tak nějak), tak jsem netušil, jak to aplikovat.

[johniez]

Stačilo by to asi dát jako -exec batch bla bla {} \; k tomu find . -name.

[Dreit]

+1

[pavlix]

Tak stokrát asi ne, to bys to musel napsat jedním půlslovem :), ale ono je to i mnohem jednodušší v tom Pythonu.

[w4rr10r]

Nemáš tam rozbité odsazování?

[xkucf03]

Chybí tam závorky.

[paralaX]

Mají takové komentáře smysl?
Sám bych si s tím nikdy neporadil, ten člověk byl tak ochotný, že to dal dohromady a dělá to přesně co má.

Pokud víte, jak to udělat ještě líp se o to prosím podělte a udělejte ten script co možná nejlepším (na internetu se mi žádný jiný rekurzivní script najít nepodařilo).

[otula]

Hm, a nestačilo by něco takového?

for i in *.CR2; do dcraw -w -c $i | convert -quality 97 - `basename $i .CR2`.jpg; done

[paralaX]

Tam není ta rekurze. Mám fotky asi takto: 2010 > 05 > 14 > snímky. Chci spustit script ve vrchním adresáři a nechat ho udělat všechnu práci za mě.

[paralaX]

Jinak ale funguje dobře - snad jen kdyby ještě říkal, co zrovna dělá.

[otula]

Stačí tam přihodit něco jako echo "Převádím snímek $i" či jiné informace. Ideálně samozřejmě uložit jako skript do adresáře, který je v PATH.

[rajcze]

to spis neco takovyho

find . -name *.CR2 -print0 | xargs -0 ufraw --wb=camera --exposure=auto --out-type=jpeg --shrink=3 --compression=90

protoze ten "python" skript to prochazi rekurzivne od . dolu

[otula]

Jo, pravda, nějak jsem zazdil, že rekurze byla v prvotním požadavku. Osobně pro ni nějak nenacházím využití, protože člověk odněkud dojde/dojede, fotky nahraje do adresáře pro tu konkrétní akci/výlet a může v tom adresáři spustit daný skript. Ale to už je věc každého jedince, jak si organizuje fotky na disku.

[paralaX]

Hlavní důvod je, že mám několik let RAWů bez náhledů. A rekurze se hodí každopádně - i kdyby jen velice vzácně.

[otula]

OK

[otula]

A ještě něco:

Sice se s novým prostředím (co se fotografie týká) stále sžívám, ale workflow Rapid Photo Downloader > tenhle script > RawTherapee > (případně) GIMP mi vyhovuje v určitých aspektech dokonce více než Lightroom.

Upravovat v RT jpg fotky namísto raw fotek mi přijde jako docela drsná prasárna. Spíš to vidím na cestu:

1. stáhnout fotky > skript > slideshow pro nedočkavou manželku.
2. vybrat fotky, které za něco stojí a pohrát si s nimi (z originálního raw) v Darktable či jiném raw editoru > smazat původní převedené skriptem > nahrát nově vybrané a upravené fotky

[paralaX]

Neboj v RT jpg opravdu neupravuji :D

Psal jsem tam, že ten script používám pro archivaci. Jinak řečeno Stáhnu forky > spustím script > rychle mrknu co sem vyfotil > až je čas sednu k RawTherapee.

Je pohodlnější rychle proskákat jpg snímky a v budoucnu se můžu rychle zorientovat co sem to tehdy fotil.

[Marián Kyral]

Já si už kdysi hodně dávno udělal skriptík, který mi nejprve připojí kartu (pokud není), najde si fotky, vytáhne z první fotky datum, zeptá se na jméno adresáře, pak adresář založí a fotky tam přesune. Následně přes dcraw vyextrahuji náhledy a rovnou se otevře gwenview.

Projedu náhledy, nepovedené smažu. Následně spustím další skriptík, který smaže raw soubory které nemají náhled. Následuje Rawtherapee, kde fotky převedu do jpegu. U převedených fotek smažu náhledy, nechám jen RAW + vyvolané fotky. Panoramata poskládám v Huginu, průběžně dělám zálohy na NAS pomocí Unison.

Po dokončení zpracování se vyvolané jpegy nahrají na flickr. Jednak jako záloha, ale taky si fotky zařadím do setů, otaguji a ty povedené pak zpřístupním ostatním (hlavně rodině a známým).

[Heron]

Běží ti RawTherapee bez problémů? Já narazil na kernel panic chybu, RT mi spolehlivě shodí systém. Bohužel.

UFRAW mi přišel takový ... na hromadný převod snímků pro rychlou prohlídku je to ok a snadno se přidá do skriptů jako je tenhle tvůj, ale ten výstup se mi příliš nelíbí (z přepalů mám fialovou), denoise to strašně rozmaže apod. Hlavně barvy mi přijdou dost mimo mísu. Pokud se ale jedná o obyčejné (automat-like) snímky, které mají přijatelnou exposici a nevyžadují další úpravy, tak je to ok.

[paralaX]

Moc sem s tím ještě nedělal, takže těžko říct. Zatím bylo vše v pohodě. Nicméně jsem bežel na linux-ck jádru s BFQ plánovačem... třeba to může mít vliv.

Se stand-alone Ufraw sem se ani neobtěžoval. Nedovedu si představit v tom upravovat větší množství fotek. Naproti tomu mi RawTherapee přijde jako ok alternativa Lightroomu.

[Heron]

Podle té diskuse se to týká přímo CPU, RT použije spec instrukční sadu (něco jako SSE) jinak a zanechá CPU v nekonzistentním stavu (což jsem nevěděl, že u user space app běžící v ringu 3 jde) a jádro potom zpanikaří. Asi se to týká jen Intelu. Sice mám zakoupený Lightroom, ale i tak jsem chtěl přenést svůj foto koutek na Debian. Zatím se krom hromadného zpracování a Huginu moc nepodařilo.

[Heron]

Tak se zdá, že po update už to RT běží v pohodě. Debian Wheeze 64b, RawTherapee 4.0.9

[paralaX]

Tak to je super :)

[David Ježek]

když vono je RT permanentně v pre-alpha stádiu (horší je snad už jen photivo ) ...

[Heron]

Což o to, to by mi tak moc nevadilo. Umí toho dost (s přimhouřením oka je na úrovni LT3). Ale už hezky dlouho nejsem zvyklý na to, že app mi shodí celý systém.

Ještě je možnost se na to vykašlat, fotit velice přesné exposice a potom použít nějaký automatický skript na převod CR2 do jpegu.

[pavlix]

Ale už hezky dlouho nejsem zvyklý na to, že app mi shodí celý systém.

To musí být hodně šikovná aplikace.

[David Jaša]

Tož nainstaluj balíček s debug symbolama, zapni kdump, zreprodukuj pád, vytáhni z něj dump, dostaň z něj použitelný backtrace a přilož ho do toho vlákna (vidím tam jen "otazníkový" bt).

[Kvakor]

Pokud jsou v RAWu "vestavěné" náhledy, tak pro jejich získání stačí dcraw -e, což je mnohem rychlejší než klasické genorování. Nebo se může použít volba -h, kde se místo složitého interpolování jednotlivé čtveřice pixelů Bayerovy RGBG masky prostě vezmou tak jak jsou a vygeneruje se z nich jeden RGB pixel. Obrázek má sice poloviční rozlišení, ale na náhledy to stačí a stále je to velmi rychlé.

[paralaX]

Moc díky! S tím něco zkusím vymyslet. Tenhle script mi tady běží už od rána :D

[otula]

I kdyby to s náhledy nebylo, tak si myslím (neověřeno), že použít dcraw bude rychlejší, než ufraw - z toho prostého důvodu, že ufraw je vlastně taková nadstavba nad dcraw.

[bambas]

Rawtherapee, BiblePro, ufraw neumi SPRAVNE nahradit (dopocitat) mrtve, chybne pixely v RAWu. To umi dobre zatim jen Lightroom...takze bohuzel :/

[paralaX]

To mě nějak netrápí. Každopádně co Corel AfterShot Pro a darktable?

[bambas]

vam nevadi hnusne tecky, pokud je mrtvy pixel? me celkem jo :) Corel AfterShot neznam, v informacich k tomu softaru jsem nenasel, zda resi muj problem :) Darktable je pomaly az k placi :)

[radix]

Corel AfterShot Pro je prejmenovany Bibble.

[paralaX]

No určitě by vadily, ale zatím jsem se tím nesetkal. Možná s tím bude mít co dělat, že Lightroom nepoužívám teprve týden a možná, že mrtvé pixely nemám.
A co myslíte tím "správně"? Googlil jsem, ale nic jsem k problému nenašel.

[bambas]

No zkousel jsem pouzivat NinjaNoise plugin, ktery to mel umet, ale umel to tak, ze mrtvy pixel nahradil absolutne nevhodnou barvou, rwtherapee ho proste nahradil cernou, atd. Lightroom vezme nejaky prumer z pixelu okolo a tim dopocitaca prislusny odstin, ktery by mel byt v miste toho mrtveho pixelu. Navic to dela automaticky uz pri vykreslovani nahledu - proto jste si toho mozna nevsiml. Zkratka jsem bohuzel zatim nenasle ekvivalent pod linux :(

[paralaX]

Podívejte, co je v manuálu RT:

When selecting a dark frame (or with autoselection), RT extracts from it all the positions of hot pixels and then always corrects them in the final image. This correction is better than applying only the "Hot/dead pixel filter", but works only for hot (=white) pixels not for dead (black) ones.

Bad pixels

RT can correct a list of bad pixels (pixels that are always black or white or stuck to one color) for your particular camera model. To do this you need to write a text file with the absolute raw coordinates of these pixels: each line specifies a pixel with x space y return positions. (If you look at the coordinates of pixels in RT, beware of the offset introduced by cut border: you must add +4 to each coordinate).

The file has to be named exactly as your camera:"maker model.badpixels" (maker must be short name) es: PENTAX K200D.badpixels; if you have two cameras with same model you can specify also the serial numbers (look at exif data): "maker model serial.badpixels". The file has to be located in the "dark frames" directory specified in preferences.

Pixels in the bad pixels list will always be corrected in processed photos.

[bambas]

K200D zrovna vlastnim. KaZdopadne tuhle volbu jsem nenasel (asi jsem byl slepy). Tak toz to jeste vyzkousim, diky!

[Marián Kyral]

Hezký, já furt nevěděl na co ty dark frame vlastně jsou. BTW, to mi připomíná, že bych měl zkontrolovat překlad RT a doplnit ho.

[Michal Kubeček]

U 400D jsem vadné pixely vyřešil pomocí AWH. Což mi připomíná, že bych měl co nejdřív udělat totéž s tím jedním červeným na 7D…