abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 21:55 | Komunita

Nadace pro svobodný software (FSF) oznámila aktualizaci seznamu prioritních oblastí (changelog), na které by se měli vývojáři a příznivci svobodného softwaru zaměřit. Jsou to například svobodný operační systém pro chytré telefony, hlasová a video komunikace nebo softwarový inteligentní osobní asistent.

Ladislav Hagara | Komentářů: 1
včera 16:44 | Nová verze

Byla vydána verze 2.0.0 knihovny pro vykreslování grafů v programovacím jazyce Python Matplotlib (Wikipedie, GitHub). Přehled novinek a galerie grafů na stránkách projektu.

Ladislav Hagara | Komentářů: 0
včera 15:33 | Komunita

V australském Hobartu probíhá tento týden konference linux.conf.au 2017. Na programu je celá řada zajímavých přednášek. Sledovat je lze online.

Ladislav Hagara | Komentářů: 0
včera 10:20 | Zajímavý článek

Pavel Tišnovský se v dvoudílném článku na MojeFedora.cz věnuje bitmapovým (rastrovým) grafickým editorům ve Fedoře. V prvním dílu se věnuje editorům MyPaint, MtPaint, Pinta, XPaint, Krita a GIMP. V pokračování pak editorům GNU Paint (gpaint), GrafX2, KolourPaint, KIconEdit a Tux Paint.

Ladislav Hagara | Komentářů: 1
16.1. 17:11 | Komunita

Byl proveden bezpečnostní audit svobodného IMAP a POP3 serveru Dovecot (Wikipedie). Audit byl zaplacen z programu Mozilla Secure Open Source a provedla jej společnost Cure53. Společnost Cure53 byla velice spokojena s kvalitou zdrojových kódu. V závěrečné zprávě (pdf) jsou zmíněny pouze 3 drobné a v upstreamu již opravené bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
16.1. 15:30 | IT novinky

Nadace Raspberry Pi představila na svém blogu Raspberry Pi Compute Module 3 (CM3 a CM3L), tj. zmenšené Raspberry Pi vhodné nejenom pro průmyslové využití. Jedná se o nástupce Raspberry Pi Compute Module (CM1) představeného v dubnu 2014. Nový CM3 vychází z Raspberry Pi 3 a má tedy dvakrát více paměti a desetkrát větší výkon než CM1. Verze CM3L (Lite) je dodávána bez 4 GB eMMC flash paměti. Uživatel si může připojit svou vlastní. Představena byla

… více »
Ladislav Hagara | Komentářů: 1
16.1. 01:23 | Nová verze

Oficiálně bylo oznámeno vydání verze 3.0 multiplatformního balíku svobodných kancelářských a grafických aplikací Calligra (Wikipedie). Větev 3 je postavena na KDE Frameworks 5 a Qt 5. Krita se osamostatnila. Z balíku byly dále odstraněny aplikace Author, Brainstorm, Flow a Stage. U Flow a Stage se předpokládá jejich návrat v některé z budoucích verzí Calligry.

Ladislav Hagara | Komentářů: 7
15.1. 15:25 | Nová verze

Bylo oznámeno vydání první RC (release candidate) verze instalátoru pro Debian 9 s kódovým názvem Stretch. Odloženo bylo sloučení /usr jako výchozí nastavení v debootstrap. Vydán byl také Debian 8.7, tj. sedmá opravná verze Debianu 8 s kódovým názvem Jessie.

Ladislav Hagara | Komentářů: 6
15.1. 13:37 | Zajímavý projekt

1. ledna byl představen projekt Liri (GitHub). Jedná se o spojení projektů Hawaii, Papyros a původního projektu Liri s cílem vyvíjet operační systém (linuxovou distribuci) a aplikace s moderním designem a funkcemi. Včera byl představen Fluid 0.9.0 a také Vibe 0.9.0. Jedná se o toolkit a knihovnu pro vývoj multiplatformních a responzivních aplikací podporující Material Design (Wikipedie) a volitelně také Microsoft Design Language (designový jazyk Microsoft) [reddit].

Ladislav Hagara | Komentářů: 8
14.1. 00:33 | Zajímavý software

Google na svém blogu věnovaném open source představil knihovnu pro komprimaci a dekomprimaci 3D grafiky s názvem Draco. Knihovna bude využívána například v aplikacích pro virtuální a rozšířenou realitu. Porovnání Draco s gzip na YouTube. Zdrojové kódy Draco jsou k dispozici na GitHubu pod licencí Apache 2.0.

Ladislav Hagara | Komentářů: 5
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (10%)
 (2%)
 (75%)
 (3%)
 (10%)
Celkem 304 hlasů
 Komentářů: 24, poslední včera 10:14
    Rozcestník
    Reklama

    Dotaz: Fotografický workflow s digikam

    13.8.2009 12:48 lertimir | skóre: 59 | blog: Par_slov
    Fotografický workflow s digikam
    Přečteno: 692×

    Rěším problém jak organizovat si fotky a zkouším se zkamarádit s digikamem, ale nedaří mi v něm najít jak realizoavat základní workflow. A to:

    1. Načíst fotky z media (karta, databanka) do archivního adresáře. V průběhu přenosu případně přejmenovat a ideálně prohlížet ve fullscrenu a ihned vyházet a nepřenášet technicky špatné.

    2. Pokud první výběr nešel udělat v pruběhu přenostu tak tedy následně vyházet špatné.

    3. Otagovat a fotky (to digikam umí dobře)

    4. Vybrat fotky, které chci upravovat, a překopírovat je do pracovního adresáře. To snad vůbec nemá, nikde jsem to nenašel, ani tu možnost procházet sadu fotek a markovat je a ani triviální kopii, snad jedině "uložil jako" po editaci. Kopírování by mělo nakopírovat i tagy k nové fotce.

    5. V pacovnímím adresáři fotku upravovat, případně vyvolat RAWy a případně mít i od fotky více verzí obět s držením tagů

    6. Finální fota nakopírovat do adresáře na hotové fota.

    Celkem triviální workflow, a připadá mi jediný logický. Jednoduché podmínky, nikdy nešahat na originální foto a oddělit hotové od rozpracovaného. Backup na vše, dlouhodobá archivace na archiv a hotová fota.  Ale nijak jsem nenašel jak to realizovat v digikamu (nebo v něčem jiném v linuxu. Před časem na Win jsem tohle dělal v ACDSee a tam to fungovalo.) Nebo je tam nejaký jiný fígl v digikamu? Poradte. Pro mne je nepřijatelné, abych přechod mezi archivem a pracovním adresářem dělal jako "uložit jako" z editace fotky to je na mrtvici. Stačí uklepnutí a je po původních datech.

    Odpovědi

    14.8.2009 22:18 lertimir | skóre: 59 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Fotografický workflow s digikam

    Jak vidím tak workflow v digikamu nikdo nedělá.

    stativ avatar 15.8.2009 10:26 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: Fotografický workflow s digikam
    LOL. Nejdřív si musíš uvědomit, co to workflow je a pak dojdeš, že každý, kdo s digikamem pracuje ho nejspíš má součást jako svého „workflow“. Spíš nikdo nepracuje tak, jako ty. Třeba já bych takhle pracovat nikdy nemohl. Ale hned sepíšu odpovědi na tvé otázky.
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    15.8.2009 08:22 MilanK
    Rozbalit Rozbalit vše Re: Fotografický workflow s digikam

    Ad 1) Neumí. Soubory zkopíruji do příslušného adresáře a pustím na ně skript (soubory se přejmenují dle data a času, v případě RAW se vytáhne vložený JPEG a RAW se uloží do podadresáře).

    Ad 2) Prostě klávesou DEL v Album view? Bohužel neumí "párovat" JPEGy a RAW, takže plánuju skript, který příslušné raw/blabla.cr2 smaže dodatečně.

    Ad 3) Ano, to je důvod proč jsem na něj přešel z MaPiVi.

    Ad 4) Neumí. Lze to obejít: nechat spuštěný digiKam a pomocí souborového manažeru s náhledy souborů tyto soubory prostým drag&drop překopírovat kamkoliv jinam ve struktuře adresářů, které jsou zahrnuty v albech/sbírkách digiKamu. digiKam automaticky zaregistruje nové soubory. Bohužel u nových souborů nebude vědět, že jsou kopií (pracovní verzí) archivního souboru.

    Co očekáváte od akce "markovat"? Není problém to vyřešit vytvořením samostatné větve ve štítcích a následně pomocí vyhledávání takto označené soubory zobrazit. (Ale uznávám, je to neohrabané.)

    Ad 5) Verzování neumí. Řeším to ručně vytvořením kopie s číslováním na konci názvu souboru.

    Ad 6) Neumí.

     

    Vy třeba vůbec nezmiňujete interoperabilitu - digiKam se zaměřuje na XMP (což je fajn) a současně se snaží udržovat vazbu na IPTC (ale už jen částečně a bugy nejsou považovány za zásadní). Smazání (třeba v důsledku poškození) databáze a její znovuvytvoření importem z metadat souborů pak může vést k nepříjemným překvapením.

    Některé typy údajů se spravují komplikovaně - např. IPTC location lze editovat jen jednotlivě pro každý obrázek. Obcházím to paralelním používáním MaPiVi.

    Největší problém je domluvit se na "workflow", každý očekává něco jiného a co si budeme povídat: digiKam programují především programátoři a ne fotografové...

    Osobně nechápu, proč ztrácejí čas s editorem (showFoto) namísto zlepšování digiKamu jako Content Management System (štítky, verzování, synchronizace metadat, decentralizovaná správa fotek). Editorů a prostých prohlížečů je už dost. Aniž bych to myslel zle, tak by též prospělo vyhodit z loga "like a professional", působí to jako sebeironie.

    Přes to všechno: netuším, zda je v linuxu něco lepšího.

    23.8.2009 21:24 lertimir | skóre: 59 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Fotografický workflow s digikam

    Díky za odpověď. Byl jsem na dovolené takže odpovídám až teď. Nedá se říci, že by mi udělala radost. Hlavní otázka v současnosti pro mne je, zda-li správu fotek budu moci udělat pod linuxem a nebo musím jít směrem virtualizace XP a správy buď ACDsee nebo Adobe Lightroom.  Zatím mám tak pouze 40000 fotek, většinu jen zařazených v Canoním softu. V jistém směru je to nyní otázka dlohodobé volby, to co mám ještě jsem schopen překlopit do jiného softu ale až budu mít tak 150 000 fotek to si nedokážu představit že to změním, a to bude tak do 5 let. Takže k tomu co jsi psal.

    Ad 1) OK. skript je možné řešení

    Ad 2) No DEL sice jde, ale to markování, které má jak ACDsee tak lightroom tak třeba Canon DPP (což odhaduji, že máš podle přípony RAW) je, že separuješ od sebe označení a akci DPP třeba má značky 1,2,3. Procházíš fotky s tím, že je vlastně posuzuješ podle nějaké podmínky, např, je špatná, nebo je třeba moc světlá, nebo WB potřebuje posunout do teplé nebo studené atd. označíš tak sadu, můžeš si výběr zkontrolovat, přeznačit a až tehdy, kdy jsi spokojen, tak spustíš akci, jako výmaz nebo posun v barvě či jasu atd. Přímý DEL je těžké vzít zpět. A nikdy bych nemazal originální raw, disky jsou levné, a máš základ s nímž můžeš i v budoucnu pracovat. DTP studia běžně pracují s 16 bitovou barvou v souborech a v současnosti už jsou profi monitory s 10-bitovou barvou a dá se očekávat že za pár let bude 10-bitová hloubka i v tiskárnách, když to nesmažeš, máš zdroj, jak to využít.

    Ad 3) Tady jsem spokojen, to je dostatečné.

    Ad 4) Pokud to zkopíruješ mimo digikam, tak nevezeš s sebou tagy. V digikamu to zkopírovat lze, když to udělám jako přesunutí a puštení na jiný adresář ve struktuře alb, ale když tohle máš dělat pro 200 fotek tak je to strašně času. Když fotíš dynamické situace vyrobíš hodně fotek a pak je třeba vybrat ty, které danou atmosféru nejlépe zobrazují, takže procházíš a vybíráš. Ty jiné programy mají hot key, který přepíná označení/zrušení stejně jako třeba v Krusaderu mezerou markuješ soubory, naprosto nejefektivnější výběr, než to chytím myší, přesunu, pustím a vyberu z menu, že chci kopírovat, mám tím markovacím způsobem projítých 10 souborů. Mě to připadá jako triviální, ale naprosto nezbytná věc. A další kritická věc je rychlost přechodu mezi fotkami. Alespoň z hlediska práce s velkým množstvím fotek. Když fotím krajinu je to jedno. Počkám si na světlo, vyfotím tak 5 snímků, s čím nejsem spokojen, smažu už ve foťáku. Ale akční fotky, sport, párty, koncert, svatba, tam není čas, buď rychle mačkat spoušt nebo sériové snímání vyrobí kvanta fotek, někdy i přes 1000.  A je třeba v prvé řadě vyhodit takové bez ducha, z každé sekvence vybrat tak 1 nebo 2 fota, která ji charakterizují. A když projíždíš sekvenci 30 fotek za sebou dopředu dozadu nekolikrát a hledáš tu 1 která je z nich nejlepší tak každé zpoždění je znát. Při dnešních pamětech nechápu, proč by  to digikam nemohl mít předpřipravené v operační paměti takové pohledy, výřezy, jaké potřebuješ když stiskneš "next", na monitor se vejde tak 2Mpix což je tak 6 MB spotřeba paměti na fotku pro celoobrazovkový náhled, pokud tam mám panýlky, toolbary tak méně. Předpočítat 10 fotek dopředu a dozadu zabere jenom nějakých 20*6=120MB.  ACDsee má přechod na "next" pod 0.1 sec, digikam tak 1-2 sec, což je při 1000 fotkách skoro půl hodina času na přechody jen při přechodech postupně dopředu, pokud porovnávám fotky přechody tam-zpět-tam-zpět několikrát za sebou tak ztráta narůstá mnohem více.

    Ad 5.6) jasné

    Ad interoperabilita) to je také závažné, vracím se s dovolené s 2000 fotek v notebooku a dalších 40k je ve stacionáru. Netuším jak to sloučit. Asi příště budu muset udržovat a synchronizovat dvě kopie databáze. Nechci zdrhnout s fotkami z linuxu, ale nástroj, který mi umožní během 2 hodin vybrat z 1000 fotek 30-50, které stojí za to a alespoň základním způsobem je doladit nemohu najít.

    stativ avatar 15.8.2009 10:34 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: Fotografický workflow s digikam
    1. Přejmenování je vpravo mezi nastaveními. Prohlížení ve fullscreenu a zároveň nepřenášení je s prominutím kravina. Před prohlížením se to vždy bude muset přenést.
    2. V tom ti nic nebrání. Navíc Light table v Digikamu je na tohle asi nejlepší věc co může být.
    3. Už sis odpověděl. Jen tak mimochodem, pokud budeš chtít otagované fotky používat i jinde tak nastav, ať se metadata neukládají do digikam databáze ale přímo do fotek.
    4. Normálně přetažením.
    5. Na RAW jsou lepší externí programy…
    6. Opět normálně přetažením.
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    15.8.2009 18:08 MilanK
    Rozbalit Rozbalit vše Re: Fotografický workflow s digikam

    Z kontextu tuším, že to měla být odpověd na původní dotaz, nikoliv na můj příspěvek.

    U bodu 3 bych vážně doporučoval nejprve vyzkoušet, obsahuje mnoho chyb (viz kde bugs).

    Z těch, které mne trápí nejvíce je chybějící podpora UTF-8 pro IPTC (původní standard byl pro US ASCII, ale dnes se přímo doporučuje používat UTF-8) a s tím související chybný "přepis" UTF-8 českých znaků do US ASCII - digiKam používá nějakou knihovnu KDE, která pro převod považuje zdrojový text za latin1 (západní Evropa).

    Je třeba též dát pozor na práci s různými programy ukládajícími informace do metadat fotky: digiKam považuje za obsahově shodné např. EXIF comment = IPTC caption = XMP Dublin Core Description = XMP Tiff ImageDescription (a obdobně pro štítky). Takže při případné editaci v jiném programu a následném zpětném importu do digiKamu nemusí výsledek úplně odpovídat očekávání. Je třeba vyzkoušet. Vím o čem mluvím, migroval jsem cca 15 tis. fotek s EXIF / IPTC metadaty, krásně jsem si procvičil exiv2 v bash skriptech, abych vyřešil různé "features" a chyby digiKamu.

    A mimochodem - metadata se _vždy_ ukládají do databáze a navíc je možné je navíc současně ukládat to fotek. U některých operací to nefunguje automaticky (např. přejmenování štítku/tagu), takže je vhodné občas "sesynchronizovat" databázi s fotkami.

    U bodu 2: Light table je dobrá věc, ale nelze tam přenést obrázky přímo z Image preview (resp. lze, ale jen ten jeden zobrazený a zbylé je tam pak nutné přetáhnout), pouze z album view, což otravně zdržuje. Pro rychlý výběr špatných/dobrých fotek stačila mnohem jednodušší věc: zachovat zoom při přecházení mezi fotkami v Image preview (vždy se vrátí na auto-fit).

    bluemoon avatar 23.8.2009 21:59 bluemoon | skóre: 2 | blog: bluemoon
    Rozbalit Rozbalit vše Re: Fotografický workflow s digikam
    co tady mlzis o tom, co Digikam neumi? davas si vyhody k nevyhodam, aby jich bylo vic a snazil se tim zakryt svou vlastni neschopnost. mam ti na to pak vubec odpovidat? skopirujes-li vsechno z databanky, musis, pokud sis nic pred tim nikdy netridil, to udelat vsechno rucne, at je to digikam nebo jiny spravce alb. nauc se mackat CTRL pri vyberech a pak jen presunes tazenim mysi do patricneho alba. co jako cekas slozitejsiho? ze ti krename prejmenuje kazdy druhy raw na tvoje album, aby sis to mohl sipkou srovnat ve spravci souboru a presunout? upravou 40ti tisic fotek stravis takovou dobu, ze tak jako ja si od zacatku budes klikat na "ulozit jako". nechapu tvuj argument, ze prijdes o rawy, kdyz vsechno budes ukladat do tiff nebo jpeg, samo ti to nabidne predchozi volbu. to neni o puvodnich datech, nikdy mi to raw neprepsalo a v samotnem vyberu z nabidky stavove listy jsem si pak mohl vybrat pouze zobrazeni jpeg fotografie a oznacit tak vsechny a prenest je do vybraneho alba. raw timhle zpusobem nikdy neprepises, jsou to surova data. pokud ti nestaci jmena 01 a budes potrebovat 001 nebo 0001, tak krename ti vyresi vsechny tve starosti, tuhle volbu najdes malokde. chces upravovat vice fotek stejne? na to ti opet staci CTRL oznaceni vsech upravovanych a nabidka bash. nic jednodussiho neni, jen se toho neboj.
    bluemoon avatar 23.8.2009 22:40 bluemoon | skóre: 2 | blog: bluemoon
    Rozbalit Rozbalit vše Re: Fotografický workflow s digikam
    ja ti reknu, jak to delam ja: vyfotim tak dve ste fotografii, zvladnu i za den, z karty a chci je archivovat do digikamu. vytvorim si ve spravci souboru nove album jako odkaz na adresar karty, vzdy kdyz se pripojim spustenim digikamu se objevi tato slozka, nektere jine alba uz tam mam. jako podslozku vytvorim raw surova data a druhou pojmenuju jako vyvolany format jpeg nebo tiff. vsechny rawy z karty prenesu do slozky raw. pokud fotim raw a zaroven jpeg, mohu si to vyfiltrovat nabidkou ve stavove liste nebo pouziji oznaceni pomoci ctrl a prenesu mysi do prislusneho alba. jsou fotky, ktere z jpegu upravovat nemusim a na prvni pohled vypadaji perfektne, tak je necham byt. jsou jpegy, ktere uz musim upravit radeji z raw, jako jsou vyvazeni bile, jas, kontrast atd. pak pouziju ShowFoto a upravim, mohu pouzit i bash, obzvlaste pri zmene velikosti. ukladam pomoci "ulozit jako" jpeg. raw mi to nikdy neprepsalo. porad ale ve filtrovacich schopnostech mam oznacit vsechny jpegy nebo tiff. dam vybrat vsechny a prenesu je do alba jpegu nebo tiff. nelibi se mi dsc jako zacatek souboru, pak nastoupi krename celeho obsahu adresare. nevim,co chces slozitejsiho. nevim take, co si predstavis pod pojmem tagy. ja mam tagu v digikamu vic nez dost. tagy exif informaci ne histogramu, profilů? co? nevim?
    24.8.2009 17:30 lertimir | skóre: 59 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Fotografický workflow s digikam

    Asi každý pracujeme s jinou fotografickou technikou. Když máš hloubku ostrosti 5cm nepoznáš z těch malinkých náhledů, kde přesně je zaostřené. Když fotím modelku je kritériem, aby měla ostré oči a řasy. Na náhledu jsou oči přes 4 pixely a řasy vůbec naprosto nic nejde poznat, jen kompozici, třeba že má zrovna teď ruku před obličejem. Ale markování už jsem si vyřešil, značení na 1 hvezdičku může zastoupit, to co chci. I když hvezdičky jsou myšleny jako permanentní marker tak tako tento jeden dočasný fungovat mohou. K tomu krename: to sice je možné, ale na druhou stranu jakékoliv operace mimo digikam poruší vazby mezi informacemi v jeho databázi. zkusil jsem si to testovacím způsobem a přišel po přejmenování o tagy. Ale základní přejmenovávání má. Nepsal jsem,  že přijdu o rawy, ale ať rawy nemaže, když psal o skriptu jak je chce smazat. tiff je formát na práci a ne na ukládání, zkusil jsem si jich prá vyrobit ale můj 16bitový tiff má 120MB, což je opravdu i na mne moc na jednu fotku pak bych 1TB zaplácl s cca 8000 fotkami, což vyfotím za půl roku. Ale finálně už mám dojem že společně s programem Bibble to půjde zůstat pod linuxem s fotkama.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.