darktable 2.0

Szerszám

Darktable

Megjelent a nyílt forráskódú, szabad (GPLv3) darktable fotó workflow alkalmazás és RAW szerkesztő 2.0-s kiadása.

Részletek a bejelentésben.

( khiraly | 2015. 12. 26., szo – 17:06 )

9:40-11:00 között igazi érdekesség, ha valaki nem akarja az egesz videót végignézni.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( mn3monic v | 2015. 12. 26., szo – 21:27 )

Nagyon messze van ez még egy camera raw-tól.

Szerintem ha ők nem veszik észre hogy össze lehet omlasztani az alkalmazást ha indítok egy importot és a mappa kiválasztó ablakban az importálási lehetőségeknél lenyomok bármilyen billentyűt, akkor semmi értelme a bug reportnak. Olyan bug reportnak sincs értelme, hogy 10x lassabb és alapvető funkciókat nem találtam meg abban a kis időben amég próbáltam. Bevallom, nem szenvedtem vele több mint egy percet, de ennyi elég volt arra, hogy tudjam, megéri a 48k huf évente lightroomra és photoshopra :)

Az első élményem nekem is pontosan ilyen volt. A második se volt sokkal-sokkal jobb. Harmadjára viszont már egész használható szintre hoztam a készségemet, bár ettől nem lett gyorsabb a kóceráj, ez tény. És pont ezért kérdeztem, mert elkezdtem számolgatni hogy mennyibe lenne nekem váltani az AfterShot-ról, illetve most majd az lesz a kérdés, hogy látok-e érdemi különbséget az AS és a DT outputja között.

Nem tudtam reprodukálni. Lehet, hogy náluk sem jött ez elő. Szóval lehet értelme a bugreportnak, nem véletlenül illik leírni, hogy milyen környezetben jön ez elő. Lehet, hogy a te rendszered vacak.
1 percet voltál hajlandó áldozni valamire és ennyi idő alatt megállapítod, hogy szar. Simán lehet, hogy igazad van, de ez ebben a formában csak fröcsögés, már megbocsáss...

Abból indultam ki, hogy a camera raw-nál (legyen lightroom, de én inkább camera raw-ot használok photoshoppal) az első perceimben nem voltak ilyen problémáim, mindent elsőre megtaláltam és nagyon gyors volt. Az hogy összeomlik ilyen esetekben lehet attól, hogy osx-en néztem és azon nem tesztelték egy percet sem, de akkor miért van official build rá? A többi szoftver tud gyors lenni, szóval nem hiszem hogy a rendszer a vacak. De hogy ne csak "fröcsögjek", bejelentem a hibát ;)

OpenCL támogatással használható sebességgel fut nálam (8 éves gép, 4 GB RAM, Core2 Duo, NVidia GTX 650/2GB, 16 megapixeles Nikon D7000 raw képekkel), és össze sem szokott omlani.
Amit sokan nem találnak, az az RGB görbe - mert nincs (csak a base curve), a legtöbb tool LAB alapú. Robert Hutton tutorial videóit érdemes megnézni.

A RawTherapee-ban sok komoly algoritmikus fejlesztés van, pl. ilyen a CIECAM2 támogatás és annak összekötése a tone mappinggel, a zajszűrők és sok más. Cserébe nincs visszafelé kompatibilitás, ha egy raw fájlt kidolgozol X verzióval, lehet, hogy X+1-gyel már másképp néz ki, mert tekertek kicsit az algoritmuson vagy annak paraméterein. Ezt fórumokon ki is mondják: miért ne akarnád mindennek a legújabb, legjobb változatát használni, ha újraexportálsz valamit? A felépítése pedig monolitikus, tehát raktak bele RGB görbét, majd később beraktak még egyet, de harmadik nem lesz, és nem tudsz más modult sem kétszer használni. Maszkolás sincs (még; úgy tudom, a hosszú távú tervek között szerepel).
A Darktable-ben upgrade után azonos módon fog exportálni, mert minden modul verziózott; ha *szerkeszted* a régi fájlt, akkor már átáll a modul új verziójára. Majdnem minden modul többször alkalmazható, és tudsz maszkolni, így külön állíthatsz élesítést a bőrre és a hajra. Az OpenCL hab a tortán.
Amit még érdemes figyelni (szerintem), az a PhotoFlow (minden szerkesztés külön réteg - a Darktable esetén minden modul fix helyen van a pipeline-ban, legfeljebb többször szerepel, a műveletek általad kiadott sorrendje nem feltétlenül egyezik meg a végrehajtási sorrenddel, ami lehet korlátozás; a PhotoFlow tényleg az előző modul kimenetére teszi rá a következőt, abban a sorrendben, ahogy te megadod). http://aferrero2707.github.io/PhotoFlow/ Windows alatt is megy.

Köszi!
Érdekes ez a PhotoFlow, de kicsit fura, hogy pl. miért nem egy Gimp-hez fejlesztenek ilyen fotókidolgozásban jól használható dolgokat? Ott gyakorlatilag az egész infrastruktúra (gui, rétegek, színkezelés, export/import?, a legtöbb algoritmus is) meg van, "csak" kényelmes eszközket/plugineket kellene fejleszteni hozzá. :)

Mer a Gimp egy tök más rendszerű eszköz, mint ahogyan a PS sem RAW-ra van kitalálva. Nem véletlenül van Lightroom sem az Adobe kínálatában.
Megpróbálom _konyhanyelven_ leírni (szakmaiságot ne keressetek benne):
a Gimp vagy PS esetén már renderelt fájlokon végzel "visszavonhatatlan" módosításokat (azaz folyamatos minőségromlást kapsz minden egyes művelet után). A RAW editorban "csupán" változásokat rögzítesz paraméterként (mintha egy scriptet írnál) renderelés előtt egy tömörítetlen csatornánkénti adathalmazon, majd ezt követően rendereled a végterméket. A RAW nevéből adódóan is egy minden sallangot nélkülöző adathalmaz, míg egy JPEG már tömörített, fejlécezett, stbstb. formátum.
A Gimp feldolgozási mechanizmusa már feldolgozott képekre van kitalálva. Létezik hozzá RAW előfeldolgozó plugin, de a további feldolgozás már ez esetén is minőségromlással fog járni. Ergo nem elég plugineket fejleszteni hozzá, mert más az eljárás.
(ha valaki érthetőbben le tudja írni, vagy fixálni, amit rosszul írtam, megköszönöm)

Az addig oké, hogy tök más rendszerű, illetve most, hogy már nem csak nyolcbites, már akár esélyes is lenne.

Viszont konyhanyelv ide vagy oda: a folyamatos minőségromlás így nem igaz. A raw se annyira raw (ezt tíz perce tanultam :D), pl.: http://lclevy.free.fr/cr2/#ddd - Dust Delete Data és hasonlók.

Az igazi problémát ott látom, hogy most akkor melyik raw feldolgozót szögeljék bele? Vagy írjanak nulláról egyet? (mindenki ismeri a vonatkozó xkcd-t :D) És akkor a két alkalmazást egybe kellene fejleszteni, egymásra várnának, és lenne egy marrha nagy dög alkalmazás, aminek a felét nem használja senki :D

Jelenleg bárkinek adott a lehetőség hogy akár 16/32 bites tiffeket gyártson a számára legkedvesebb raw gyurmázóval (én mondjuk 400 képből kb. 20 képet választok ki, és abból 2-3 kerül gimp-be), és utána akár gimppel, akár más valamivel kedvére módosítsa.

Fogod a Gimpet és rátolsz egy effektet egy képre. Ebből csinál egy példányt a tempbe. Új effekt, ebből a tempből csinál újat, ergo egymás mögé láncolod őket. A végső export már csak egy mentés másként funkció, semmi más. Szerinted ez nem jár minőségromlással?

Ebből csinál egy példányt a tempbe.

Ebben biztos vagy? 


> lsof | grep gimp | grep /tmp | wc -l
0

Egy gimpswap fájlt tényleg nyitva tart: 


> ls -la .gimp-2.8/gimpswap*
12242944 dec   31 00.43 .gimp-2.8/gimpswap.18078

Egy új (átlátszó) réteget hozzáadva a képhez: 


> ls -la .gimp-2.8/gimpswap*
6897664 dec   31 00.46 .gimp-2.8/gimpswap.18078

Mindent réteget törölve: 


> ls -la .gimp-2.8/gimpswap*
22728704 dec   31 00.48 .gimp-2.8/gimpswap.18078

Ez alapján inkább valami visszavonási naplónak tűnik, nem hiszem, hogy minőségromlással járna.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A GIMP a betöltött képet képpontonként kezeli. Munka közben a GIMP nem használ sem adatvesztéses, sem másféle tömörítést. (gimp-2.6)

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Ezt most komolyan el kell magyarázni? Na jó...

Tegyük fel, hogy a Gimp és a Darktable is ismeri az f, g, h képmanipuláló algoritmusokat (függvényeket), amik egy-egy i bejövő képet és egy-egy p paramétert kapnak. Mindkét programban sorban alkalmazod a képre az f, g és h függvényeket: o = h(g(f(i, p1), p2), p3). Eddig mindkét program azonos kimenetet állított elő. Mivel nem tetszik a végeredmény, ezért úgy döntesz, hogy p1 helyett p1' paramétert alkalmazol f függvényen. Ekkor Darktable-ben elég ezt a beállítást "az eredményen" alkalmazni, Gimpben viszont vagy visszavonod f, g és h-t majd újra alkalmazod őket, immár h(g(f(i, p1'), p2), p3) módon, vagy megpróbálod végrehajtani f(o, p1'')-t úgy, hogy az eredménye ekvivalens legyen h(g(f(i, p1'), p2), p3)-val. Ez utóbbi viszont csak addig lehetséges, amíg f, g és h invertálható függvények, és akkor se könnyű.

( csearo | 2015. 12. 27., v – 11:16 )

Kipróbáltam, nekem kissé túl sokat tud :)

:wq

( bathory | 2015. 12. 27., v – 14:29 )

(Mérsékelt) örömmel jelentem be, hogy a következő verzió magyar kezelőfelülettel fog érkezni. A kiadás előtti napon küldtem be a 85%-os készültségű fordítást, mint utólag kiderült 90% kellett volna ahhoz, hogy bekerüljön ebbe a kiadásba. Ironikus módon a megjelenéskor már bőven 90% fölött tartottam, de mivel sem a kiadás idejét nem ismertem, sem a bekerülési határt, a magyar fordítás átcsúszott a következő kiadásra.

Ha valaki forrásból fordítva (vagy unstable PPA) kipróbálná, örömmel veszem az észrevételeket!

( Fisher v | 2015. 12. 29., k – 13:31 )

Mondjuk most viszonylag boldog kezdek lenni, OpenCL-lel már egész vállalható a sebessége, és fél nap után már-már olyan képeket gyárt, amilyeneket én szeretnék :D

( sigellef | 2015. 12. 30., sze – 19:25 )

... egy újabb silány próbálkozás arra, hogy még egy GIMP-et írjanak :D:D

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Attól, hogy valami után beszúrunk egy-két szmájlit, még nem lesz vicces. Bár nem kizárt, hogy egy idő múlva már a szmájli elég lesz a nevetéshez.

Hint: http://www.vicclap.hu/vicc/21607/Bolondok.html

----- 

(&%;_98\<|{3W10Tut,P0/on&Jkj"Fg}|B/!~}|{z(8qv55sr1C/n--k**;gfe$$5a!BB]\.-