Pro ty co trpí iracionálním strachem z KDE je tu Shotwell.
nejsu si jistej o co ti presne de, nicmene pokud jen o nahledy, tak jak je mas roztrideny na disku/na zaloznich mediich, tak k plne spokojenosti vyuzivam http://sourceforge.net/projects/vvvp/ ... umi to jak primo podle tvych adresaru + si to dal roztridit virtualne v ramci vvvp db
Zkusil jsem Darktable. Trochu zapas s ovladanim, ale jsem ajtak a ne fotograf. :-)
Jedna vec mi ale hned na pocatku vrta hlavou: Import vlastne neni import fotek nekam do "alba" (jako to dela DigiKam) ale jen import informaci do jeho databaze ? Alespon tak mi to pripada.
Predhodil jsem mu adresar na externim disku s kopii fotek z karty fotaku, natahal info k souborum a tak nejak jsem nevedel, jestli uz je hotov. Nahledy delal az kdyz jsem po nich roloval a zcela jasne je bral az v te chvili z toho externiho disku. Vybral jsem mu 2 adresare a zpracoval jen druhy. A do nej ke kazdemu souboru vyrobil xml popis. WTF ? Nejak nechapu jak to muze fungovat s fotkami na fotaku. Mozna v pripade fotaku, ktere nemaji dostupne fotky jako mass-storage, provede opravdu import nekam na HD.
Proste mi to pripada, ze je to dobre jen k praci nad fotkami, co nekde uz jsou vykopirovane. Mozna vyhoda pro nekoho, kdo si fotky tridi do adresaru sam a nechce to resit v databazi. Ale v tom pripade bude pro nej i nadbytecna databaze s "filmovym pasem" z danych adresaru.
Do ~/.config/darktable/library.db si ulozil exif informace, nic jineho nema po odpojeni toho disku..
Evidentne to bude zcela jina filosofie prace s fotkami nez jsem zvykly. Asi tusim: prace s fotografiemi (upravy do kopii a jejich exporty), ne prace s fotoaparatem, tzn ze asi moc neresi ziskavani fotek z nej nekam do alb.
Aha, zacinam do toho trochu videt .. role filmu jsou adresare (chybi mi moznost dolepsit jmeno "role filmu") a sbirka je pak mnozina zfiltrovana podle pozadavku klidne pres vsechny "filmy" .. treba: fotky ze vsech "filmu" vsech fotaku cele rodiny dle datumu, kdy jsme byli v zoo (zajimave asi pokud chce rodina tu navstevu zoo hodit nekam na web). Nebo fotky jen z urciteho fotaku. Nejak nevim jak udelat kombinaci tech podminek .. uff ..
Hlavne jsem neprisel na to, jak vymazat "roli filmu" pokud jsem uz ten adresar zahodil. Teda jako intuitivnim zkoumanim. Asi bude na case precist si nejaky manual.
Skoda ze to neni nad QT, mohli by to vice portovat.
V ne-KDE prostředí nelze spustit terminál v příslušném adresáři alba, spuštění souborového manažeru funguje.
Z pohledu GUI mohou nastat též problémy, liší se to podle verze digiKamu. Starší verze dk mají vlastní témata vzhledu, ta však obarví pouze některá okna, jiná zůstanou světlá. V ještě starší verzi to fungovalo bez problémů.
V nové (zatím vývojové či beta(?)) verzi už vlastní témata tuším nejsou, ale přebírá se nastavení z KDE ovládacího panelu (tj. je třeba jej nainstalovat a sladit vzhled KDE s GNOME).
DigiKam mam na spravu fotiek ale akekolvek upravy som musel v nom prestat robit. Konverzia z raw je vyrazne horsia ako pri pouziti ufraw [netusim, aky backend pouziva DigiKam] a export do jpegu je nepouzitelny. Ked z toho isteho TIFFu ulozim jpeg v DigiKam-e a v gimp-e, rozdiel v kvalite je viditelny na prvy pohlad...
Sakra lidi, udavejte zdroje kdyz uz neco placnete!
Ukazka:
Podpora RAW v digiKamu by nemela byt tak spatna, jak se domnivate. Zkuste poladit..
digiKam usually does a decent job of decoding RAW files using the default settings. But if you prefer to have complete control of how the application processes RAW files, choose Settings » Configure digiKam, switch to the RAW Decoding section, and enable the Always open the Raw Import Tool to customize settings option. Next time you open a RAW file for editing, digiKam drops you into the RAW Import interface where you can tweak the RAW import and post-processing settings. digiKam relies on the LibRaw library for all RAW processing. LibRaw is a pure C++ library which includes demosaicing algorithms from the dcraw software as well as algorithms from other projects like Rawtherapee.
zdroj: http://scribblesandsnaps.wordpress.com/2011/05/04/process-raw-files-in-digikam/
Ackoliv nekterymi postrehy autor zaujal (chybi nastroj pro tvorbu prezentaci, odlisne chovani pod Gnome), musim jako dlouhodoby uzivatel digikamu hodnotit clanek jako slaby. Krome drobnych chyb (napr.: objektiv neni cocka, jak je chybne uvedeno u funkce "Lens-correction") se autor dopousti nepresnosti danych neznalosti soucasneho stavu, napr.: "nejslabší místo celého programu a jistě by někteří uživatelé ocenili také funkce na rozpoznávání obličejů." Tato funkcionalita je dostupna od 2.0.0 beta1 (http://www.digikam.org/drupal/node/561). Současná verze je 2.0.0 RC, verze 2 je planovana na 27/07/2011 (http://www.digikam.org/drupal/about/releaseplan).
Uprimne doufam, ze kritiku nebude brat autor osobne a z chyb se pouci.
Poslední dobou to vypadá, že ten samý SW toho pod Windows umí více než v linuxu. Například detekci tváří verze 2.0.0 beta pro Windows má http://farm6.static.flickr.com/5155/5873878380_2fe68e6a35_o.png
Vyhledate-li "digikam face recognition" v googlu, prvni odkaz vede na: http://scribblesandsnaps.wordpress.com/2011/04/11/new-features-in-digikam-2-0-face-recognition/
Pokud byste chtel v dikuzi pokracovat, tak ja jen shrnu ze funkcionalita dostupna je, ale blize jsem ji netestoval (nepotrebuji ji, stejne jako GPS a mnoho dalsich funkcionalit, o kterych jsem rad ze jsou k dispozici, kdybych zmenil nazor).
Testoval jsem to před cca dvěma měsíci, detekce obličejů jakž takž fungovala.
Učení se, co je obličej a co nikoliv, nefungovalo.
Rozpoznávání obličejů (tj. přiřazení štítků se jmény) bylo dost zoufalé a navíc nefungovalo učení téhož.
Občas se v mailing listu objeví dotaz - funguje to vůbec někomu? Počítám, že až vyjde 2.0.0 ostrá verze, která se dostane do normálních distribučních kanálů k uživatelům, tak se ukáže, zda je to prakticky použitelné.
Musím dementovat problémy s provozem Digikamu pod Gnome. Před chvílí jsem vyzkoušel Digikam pod Gnomea nic patrného jsem neviděl. Nevěříte? Mám to někam uploadovat screenshoty? OpenSuse 11.3, Digikam 1.9, KDE 4.4 tuším.
Mohl by autor upřesnit o co přesně šlo?
Naopak, co se týče vzheldu jsme měl spíš problémy s Gnome aplikacemi pod KDE obecně; než jsem přišel na to - vypnout spouštění xsettings (imitace gnome-settings-daemon od KDE, aby to lépe sdílelo nastavení, ale ono to nikdy moc nefungovalo) a místo toho spouštět plnohodnotný gnome-settings-daemon. Pak se konečně. Trik s ruční editací souborů .gtkrc-2.0 bohužel platí jen na některé aplikace, plnohodnotné Gnome aplikace se nenechají ošálit a poslouchají jen maminku - teda pardon jen svého "démona".
Digikam dlouhodobě používám, tady je mích pár postřehů:
Jedna z mála aplikací pro linuxový desktop která snese srovnání s profesionálními produkty (vesměs pro Win a Mac). Není mnoho takových. Moc bych Digikamu přál kvalitní Windows verzi, protože jen tak má šanci se více rozšířit mezi uživatele (to píšu na linuxu a jako mnoholetý uživatel linuxu).
Chyběla mi zmínka, že řada funkcí je přes kipi-pluginy. Pokud nenainstalujete, nebudete je v Digikamu mít. Kipi API, jedno z mála vyšších aplikačních API, které sdíli více jak jedna aplikace, I když mám dojem, že momentálně to je pouze Digikam a Gwenview. Pochopitelně, z Gnome nic, ani netuším, jestli mají něco podobného.
Ač je to KDE4 aplikace, nepoužívá ani Nepomuk ani Akonadi (metadata/aplikační storage) ale léty ověřenou SQlite a to přímo. Vzhledem k nevalnému stavu v jakém se hlavně Nepomuk nalézá, jde spíše o pozitivní vlastnost. Tabulky jsou lidsky čitelné, jednoduchá asociativní data.
Jednou se mi rozjela SQLite databáze a o všechna data jsem přišel. Naštěstí vždy mám nastaveno aby se data duplikovala i do obrázků samotných, do jejich metadata. Tím pádem jsem o nic nepřišel, databáze funguje jen jako jakýsi index, ne primární zdroj. Nechal jsem ji jednoduše vygenerovat znovu, přímo z Digikamu.
Při používání jakéhokoliv pokročilejšího nástroje vždy se ptejte, kde, kam a jak to ukládá metadata. je v tom váš čas a někdy i nenahraditelné informace.
Nešetřete místem na disku ale vaším časem.
Ukládání metadat i do fotek má další výhodu - zálohování a synchronizace.
Jednoznačně doporučuji mít nastavené i když to může to nepatrně zpomaluje práci.
Chybí zmínka o batch operation managementu. Přitom dotazy uživatelů jak zmenšit (převést, zaostřit, přejmenovat, ..) všechny obrázky v adresáři. Tyto dotazy se často opakují ve fórech. Digika má tuto funkci na vysoké úrovni, Batch manager, asi nejpokročilejší UI batch manager obecně pro linux.
Bugy. Těch by taky bylo pár:
Moje oblíbené QtCurve téma nefunguje správně s Digikamem, posuvníky se zobrazují i tam kde nemají a s obrázkem je pak třeba posouvat i při volbě "fit to window". Otrava. Musel jsem dát sbohem QtCurve, sehnout hřbet a přepnout do Oxygenu.
Rating ani tagy se nezobrazují při prohlížení obrázků v plné velikosti. Je nutné mít aktivovaný boční panel s tagy a ratingy. Rád bych viděl "hvězdičky" i při celoobrazovkovém zobrazení.
Není možné jemněji nastavit okénka s metadaty, filtr, musím pak často mezi nimi přepínat, hodilo by se mi jich mít pár na jediném panelu - histogram, závěrku, aperturu, jméno, blesk, tagy a rating a to je vše.
Někdy si říkám, že ShowFoto (aka Digikam Editor) je zbytečnou duplikací editoru Krita. Vím, mají trochu jiné zaměření, ale funkčně se překrývají o více jak 50%. Je to zbytečné štěpení sil. To nemluvím o duplicitu s Gimp a dalšími editory pro Gtk/Gnome, ale doufal jsem, že alespoň v rámci jednoho desktopového frameworku by k nějaké užší splupráci mohlo docházel, ale kdepak, každý si hrabe na svém písečku.. :(
Nemám s programem osobní zkušenosti a fandím mu. Ale srovnání s profesionálními produkty nemůže snést dokud nebude mít plnou podporu pro RAW formáty (ideálně DNG), nejen generování náhledů (viz diskuze výše). Právě v profesionálním sféře se RAW formát používá takřka výlučně až na velmi specifické případy (např. požadavek na maximální rychlost sekvenčního snímání, pak se fotí na jpeg). Tak snad to časem bude :).
Ked som zacal s DigiKam, chrochtal som blahom nad batch managementom - pouzival som ho na generovanie "web size" verzii. Az kym mi nedoslo, ze jeho jpeg backend vyraba strasne hruzy a radsej si to odvtedy naskriptujem v ImageMagick :(
Moj osobny dojem je, ze darktable casom prevalcuje DigiKam.
Hmm, resize určitě používám a nespozoroval jsem. Je fakt že žádný batch už jsem dlouho nejel. Hádám že to používá libjpeg přes k kdegraphics a možná v případě exportu ještě přes kipi, Nahlaste to jako bug.
Jinak generování webu z Digikamu (Kipi) je skutečně slabé po všech stránkách, jestli byl resize součástí tohoto procesu tak mě potíže zase tak nepřekvapují.
A ještě na jeden zádrhele jsme si vzpomněl. Jeden čas Digikam strašně padal. Dával jsem bugreport na Mandrivu. Ani snad ne tak Digikam jako spíš něco z hlouby KDE (kio vrstva). Pomohl upgrade na novou verzi KDE i Mandrivy. Teď na Suse to taky jede bez problémů.
darktable vypadá velmi nadějně na konverzi RAW, ale jako správce (DAM) je prakticky v plenkách a vzhledem k vyhraněným názorům vývojářů se to jen tak nezmění.
Na jednoduché věci to stačí, ale digiKam jakožto DAM je o generace dále.
P.S. Používám obojí. digiKam je zase zoufalý v konverzi RAW, takže se prima doplňují.
Nevim co delam spatne, ale predhodil jsem mu cca 6000 fotek a start programu trva cca 40 minut (ne neni to preklep). Ergonomie ovladani nevim jak v poslednich verzich, ale stala za prd. Napriklad ukol orezat hromadu fotek na stejny pomer stran prestane bavit uz u treti fotky pokud pokazde musite slozite ten pomer nastavovat.
Nakonec jsem koupil Bibble5.
Presne tak, neco tam bude spatne. Udelal jsem nedavno v zoo asi 1000 fotek (casto serie 7snimku, 10mpix FujiHS10 cca 4MB/fotku). SDHC karta vlozena primo do ctecky v notebooku. Proste prekopirovani v Krusaderu je v radu jednotek minut. DigiKam se nad tim zamyslel asi na 45minut. V zaveru jsem si vsiml, ze RAM je zabita aplikaci a cele se to jiz potaci ve SWAP (notebook ma jen 2GB RAM).
Nechapu, proc vsechna ta data zustavaji viset v RAM, kdyz se dela jen postupne importovani fotek jedne po druhe. Vsak po zpracovani souboru se da vse zahodit a zpracovavat dalsi.
Znamena to, ze pri prenaseni 16GB fotek budu mit v haji i muj domaci komp s 8GB RAM ? A zacina mne desit, co to dela s RAM pri zpracovavani tech snimku potom.
PS: tyka se to stable verze 1.9.x
Duvod se vzdy najde.
Picasa miri na masy a proto je to velmi jednoduchy nastroj. Obsahuje velke mnozstvi funkcionality, vcetne tagovani a zakladnich uprav fotek, proto ji vzdy vrele doporucim kazdemu fotoamaterovi, sam jsem na ni zacinal. Casem jsem prestal editovat fotky a snazim se fotit tak, aby upravy nebyly treba. Nejsem perfekcionalista, proto nepotrebuji stravit nad fotografii hodiny ve fotoshopu, prakticky jen prebiram svoje soukrome a rodinne fotky. Proto ocenuji pokrocile tagovani digiKamu, ktery mi umoznuje tagy postihnout me pracovni forkflow (domlouvame se se zenou co poslem babickam a pod.).
Berte to jako ukazku pro ukazani rozdilu mezi jednoduchym a do velke miry prednastavenym nastrojem (Picasa) na jedne strane a komplexnejsim nastrojem, umoznujicim slozitejsi zasahy (digiKam) na strane druhe. Samozrejme vetsi mira volnosti je i pozadavek na vetsi miru znalosti.
Co budete pouzivat by melo byt odpovedi na Vase ocekavani od aplikace. Kombinace Picasa + GIMP je logicka a pokud Vam vyhovuje, neni treba menit :-)
Poměrně dobrý program F-spot měl až do nedávna nepříjemnou vlastnost. U každé importované fotky upravoval datum a čas jak si myslel, že by to mělo být. Nemusím ani říkat, že to pokaždé bylo špatně. Svévolná manipulace s exif daty se nedala vypnout. To byl také důvod, proč jsem F-spot přestal používat, i když v poslední verzi už to, myslím, opravili. Ale já jsem tomu programu přestal věřit. Neví někdo, jak je to s Digikamem? Nedělá něco podobného?