FotoSHOCK - nový editor obrázků

26.7.2012 21:33 | Přečteno: 1967× | Programování | | poslední úprava: 27.7.2012 11:42

Tak a je to tady. Oznámení nové zabijácké aplikace! Je to bitmapový editor jménem FotoSHOCK, na kterém pracuji ve svém volném čase více než rok. Protože pořád mám tendenci něco upravovat a neustále vydání oddalovat (jen pro zajímavost – lokální repozitář obsahuje 782 commitů) jsem se rozhodl nakonec FotoSHOCK vydat bez větších příprav. FotoSHOCK se skládá ze dvou částí: jádra FotoSHOCKcore (pod licencí LGPL3) a grafického rozhraní FotoSHOCK (GPL 3).

FotoSHOCKcore

Jádro je trochu podobné GEGL, protože podobně jako GEGL umožňuje operace nad obrazem uchovávat ve formě grafu, ale je lepší . Oproti GEGL je implementováno v C++, takže se zde nevyskytují obezličky pro „objekty“ typu GObject.

Protože se mi teď nechce psát sáhodlouhé texty o tom, jak je FotoSHOCKcore super, shrnu to nejzajímavější do několika bodů:

• Jádro automaticky vytváří cache takovým způsobem, aby vstup aktivních operací byl cachován, v případě operací před delší dobou se ale cache už nepoužívá (pokud se změní, znamená to ale, že se toho musí spočítat více).
• Je demand-driven. Přepočítává se tedy jen část obrazu, která je potřeba.
• Řeší závislosti mezi operacemi – pokud operace vyžaduje vstup z jiné operace, tato operace se spustí také. Funguje to i opačně – pokud operace změní vstup pro následující operace, tyto operace se přepočtou.
• Podporuje více bitových hloubek. Konkrétně se jedná o 1, 8, 16, 32, 64bit integer a 32 a 64bit floating point. Je možné i specifikovat i konkrétní počet používaných bitů. To se může hodit např. u RAWu, který má řekněme 12bit. Operace pak nemusí vytváře 16bit LUT, ale ví, že stačí 10bit.
• Podpora různých barevných prostorů pomocí LittleCMS 2. V tuhle chvíli jde o šedotón, RGB, CMY, CMYK, XYZ, Lab, YUV, HLS a HSV. V blízké budoucnosti chci integrovat svůj vlastní superrychlý převod RGB<->Lab pro 8bit obraz.
• Pěkné rozhraní – jak by ne, sám jsem ho navrhl k obrazu svému
• Rychlé (viz dále).
• Víceméně stabilní API. Tím víceméně myslím to, že API by, kromě rozpracované serializace, mělo být stabilní.

FotoSHOCK

FotoSHOCK je uživatelské rozhraní k jádru FotoSHOCKcore. Je implementován kompletně v Qt 4. S jeho vývojem jsem začal relativně nedávno, jedná se tedy zatím jen o takový proof of concept.

Ovládání

Pro zobrazení menu pro nahrání obrázku a přidání operací se musí kliknout pravým tlačítkem na bílé ploše. Propojení se dělá kliknutím na takovou tu šipku a tažením k jiné (modré šipky jsou výstupy, zelené jsou vstupy). Pro zobrazení GUI operace (zobrazení náhledu, nastavení křivek) slouží double click na operaci v grafu.

Jo, a pozor na jednu věc – GUI zatím neumí operace aktivovat, pokud nejsou propojovány „zdola nahoru.“ Nejdřív se tedy musí spojit root (načtený obrázek) s první operací, první operace s druhou atd.

Ukázky

Pro demonstrování (zatím velmi jednoduchého) uživatelského rozhraní jsem vytvořil dvě ukázková videa. Omlouvám se za horší kvalitu (zejména divnou změnu barev, když se objeví text), s kdenlive jsem začal před zhruba hodinou…

Ukázka, proč je rozhraní ve formě grafu tak mocné. Video ukazuje možnost zobrazit jednotlivé kroky zpracování obrazu najednou a také ukazuje možnosti nedestruktivního editování, kdy je možné jednu ze straších operací změnit a změny se příslušně promítnou i na následujících operacích.

Ukázka grafu

Ukázka, jak je to rychlé. Porovnávám GIMP 2.8.0 z distribučních balíčků s FotoSHOCKem. Je nutné poznamenat, že FotoSHOCK byl zkompilován v debug módu, který obsahuje mimo jiné dodatečné kontroly při každém přístupu k pixelu, a je tedy citelně pomalejší než release. Krom toho jsem FotoSHOCK zatím téměř neoptimalizoval.

Porovnání rychlosti s GIMPem

A nakonec screen nastavení z prvního videa pro Bedňu, aby mohl zabíjet čas i v práci . Rozhodně doporučuji kouknout na videa, kde je demonstrováno jak to funguje.

Odkazy atd.

Homepage
Dokumentace API

Pozn. omylem jsem blog publikoval ještě dříve, než jsem chtěl. Je tedy poněkud odfláknutý…

       

Obrázky

Komentáře

[xsubway]

vypadá to dobře.)

[Dreit]

Moc se mi to líbí, ta rychlost....k neuvěření! Jen aby to dokázal používat i BFU jako já

[stativ]

Díky. Rád bych časem udělat i GUI „pro začátečníky,“ které by bylo určeno jen pro lineární řetězení operací (což pro jednoduché úpravy dostačuje), kde by se jednotlivé operace automaticky napojovaly. Představuji si GUI podobné tomu, které mělo LightZone – sloupeček, ve kterém jsou operace poskládány nad sebou. Sám jsem s LightZone začínal a používalo se to výborně.

[Dreit]

O LightZone jsem nikdy neslyšel, ale Google naznačil, že to nevypadá špatně. Rozhodně se nemůžu dočkat oficiálního vydání

[chrono]

Nie je v Gimp zapnutá správa farieb? (v takom prípade sa niektoré veci robia veľmi pomaly)

[stativ]

Je, ale zrovna křivky to neovlivňuje. Pro jistotu jsem to ještě teď zkoušel a překresluje se to stejně pomalu i vypnutou správou barev.

[Dusan]

Aké máš s tým plány?

Predstavíš to na nejakom linuxáckom alebo inom zraze?

Chceš aby sa niekto pridal k tvojej práci?

Myslíš že kód gegl/gimp je zbytočne zložitý? aj s pridaním všetkých funkcií ktoré používajú?

Pridáš podporu filtrov z Gimpu?

[stativ]

Predstavíš to na nejakom linuxáckom alebo inom zraze?

Časem možná ano. Zatím je na tom práce jako na kostele.

Chceš aby sa niekto pridal k tvojej práci?

Až bude GUI v trochu lepším stavu, tak se bude hodit každá ruka na implementaci nových operací do GUI. Zatím jsou tam jen křivky (i když technicky vzato ve FotoSHOCKu jsou i načtení obrázku, náhled nebo konverze barevných prostorů standardní operace).

Myslíš že kód gegl/gimp je zbytočne zložitý? aj s pridaním všetkých funkcií ktoré používajú?

Kód GEGL je podle mého názoru jeden z nejhezčích kódů v opensource, když pominu nutné skopičiny kvůli GObject. Dá se přečíst a pochopit za 2–3 dny (nepočítám operace), takže bych řekl, že je i docela jednoduchý. Ale, jak už je vidět z mých předchozích řádků, nejsem fanda GObject, spíš se mi líbí rozhraní VIGRA, kterým jsem se částečně inspiroval.

Kód GIMPU jsem studoval naposledy ca před rokem a to už bylo horší. Ale u programu, který je tu už pěkných pár let to není nic překvapivého. Zejména kvůli současné existenci částečně integrovaného GEGL a starého tile manageru. Předpokládám, že s přesunem ke GEGL, který se snad konečně děje (když jsem začal psát FotoSHOCK, tak to bylo v nedohlednu…), se kód zlepší.

Pridáš podporu filtrov z Gimpu?

Nevím. Pokud ano, tak je to hudba vzdálené budoucnosti. Myslím, že by to mohl být docela problém. Spíš bych to viděl na nějaký wrapper, který by umožňoval spouštět gimpovské skripty v Pythonu.

[Bedňa]

Si fakt frajer.

Mám v práci blokovaný YT, môžem ťa poprosiť o nejaké screens GUI?

Ako dlho už na tom pracuješ?

Nechceš GUI spraviť tak ako ho má ten čo sa vysllovuje skoro rovnako

[kralyk z abclinuxu]

Zkus to takhle.

[Bedňa]

Dík za pokus, ale proxiny máme všetky blokované

[xm]

A co Tor? Neříkej mi, že když s ním člověk prorazí i velký čínský firewall, tak že v práci bys neuspěl Při nejhorším bys musel použít nějaký z mnoha Tor bridgů (Tor relay který není publikován v Tor adresáři, takže jeho IP není lehce zjistitelná a tedy je odolný proti cenzuře).

A nebo použít nějakou VPNku, pokud ti Tor přijde moc pomalý.

[stativ]

Mám v práci blokovaný YT, môžem ťa poprosiť o nejaké screens GUI?

OK, přidal jsem. Mimochodem, zkoušel někdy někdo možnost přidat video k zápisu? Mě to vrací chybu "Přístup odmítnut Pouze administrátor nebo vlastník tohoto objektu smí provést požadovanou akci!"

Ako dlho už na tom pracuješ?

Zhruba od února minulého roku – jádro jsem navrhoval v rámci bakalářky. V současném stavu je oproti bakalářce prakticky kompletně přepsáno, zejména kvůli zavedení mipmap a obecnějšímu způsobu přidávání hran do grafu. Většina původního API ale zůstala téměř nezměněná (nepočítám změny datových typů pro parametry), takže bych řekl, že je API snad dostatečně dobré na to, aby se dalo považovat za stabilní.

Nechceš GUI spraviť tak ako ho má ten čo sa vysllovuje skoro rovnako

Ne, chci ho úplně jiné. Rád bych měl GUI ve stylu Blender Node Editoru, jelikož je to neuvěřitelně mocné. Časem bych rád přidal i jednodušší GUI, kde se operace nebudou zobrazovat v grafu ale v řetězu s automatickým napojováním. Přeci jen například v případě, kdy je potřeba jen upravit křivky a změnit velikost obrazu, je nutnost sestavovat graf operací zbytečná a zdlouhavá práce.

[zirapha]

Jak v tom nakreslim ciaru alebo obdlznik, jak sa v tom orezava fotka?

[stativ]

Zatím nijak. Konkrétně kreslení má hodně malou prioritu, jelikož ho nepoužívám. Zatím to chci vést zejména směrem zpracování fotek (podpora různých barevných prostorů, křivky, doostření, odstranění šumu, možná nějaký tonemapping pro zpracování HDR...), kde není kreslení obvykle potřeba.

Nicméně nebudu se bránit tomu, když to implementuješ – stačí implementovat ImageOperationDescriptor a ImageOperation.

[zirapha]

Nehrozi :D, v tom pripade by si mohol zmenit nadpis na "FotoSHOCK - nový editor fotek". Ja si ako BFU pod pojmom "editor obrazkov" predstavim kreslenie portretu a pod pojmom editor fotiek "cucenie na fotku a hybanie slidermi". "Foto" v nazve uz je tak ho treba tak prezentovat - editor fotiek.

[Bedňa]

Ty fakt nečítaš. Však si môžeš implementovať slidery

[xxxxxxxxxxx]

Držím palce s vývojem, každej kdo tahle něco výjmečnýho bastlí je u mě borec!

[Bedňa]

A čo z QTapps neodpísali?

[xxxxxxxxxxx]

Ne... Jsou to hovada a dementi. Nebudu se snažit budu to dávat na sourceforge.net

[stativ]

Jo, to je IMO dobrá volba. Nevím o jiném hostingu pro projekty, který by poskytoval tolik možností. Bohužel teď ale ruší hosted apps, takže některé věci si teď člověk musí nastavit sám. Na sourceforge se mi nelíbí jen dvě věci – pomalost a neexistující propojení bug trackeru s repozitářem a dalšími částmi webu, jako to má Google Code nebo Launchpad (který má mnohem lepší bugtracker než má sf).

[s0]

vypada to dobře. Teda na videu :) V reálu jsem nějak nebyl schopný nahrát ani obrázek.

Jen drobné poznámky:

cmake je potřeba 2.8.8. Měl jsem 2.8.6 a tam není OPTIONAL_COMPONENTS ve find_package.

Jakou Qt potřebuješ? 4.8.x? Nešlo mi uic na mainwindow.h, musel jsem to vohackovat, protože můj uic z 4.7.x nezná tag iconset

diff -r 8b0788844b31 src/fotoshock/mainwindow.ui
--- a/src/fotoshock/mainwindow.ui       Thu Jul 26 18:31:05 2012 +0200
+++ b/src/fotoshock/mainwindow.ui       Fri Jul 27 11:21:01 2012 +0200
@@ -38,7 +38,6 @@
   <widget class="QStatusBar" name="statusbar"/>
   <action name="actionOpen">
    <property name="icon">
-    <iconset theme="document-open"/>
    </property>
    <property name="text">
     <string>Open</string>
@@ -46,7 +45,6 @@
   </action>
   <action name="actionSave">
    <property name="icon">
-    <iconset theme="document-save"/>
    </property>
    <property name="text">
     <string>Save</string>
@@ -54,7 +52,6 @@
   </action>
   <action name="actionSave_As">
    <property name="icon">
-    <iconset theme="document-save-as"/>
    </property>
    <property name="text">
     <string>Save As</string>
@@ -62,7 +59,6 @@
   </action>
   <action name="actionQuit">
    <property name="icon">
-    <iconset theme="application-exit"/>
    </property>
    <property name="text">
     <string>Quit</string>

[stativ]

vypada to dobře. Teda na videu :) V reálu jsem nějak nebyl schopný nahrát ani obrázek.

To jsem asi měl zmínit. Dodám i do zápisku. Pro zobrazení menu pro nahrání obrázku a přidání operací se musí kliknout pravým tlačítkem na bílé ploše. Propojení se dělá kliknutím na takovou tu šipku a tažením k jiné (modré šipky jsou výstupy, zelené jsou vstupy). Pro zobrazení GUI operace (zobrazení náhledu, nastavení křivek) slouží double click na operaci v grafu.

Jo, a pozor na jednu věc – GUI zatím neumí operace aktivovat, pokud nejsou propojovány „zdola nahoru.“ Nejdřív se tedy musí spojit root (načtený obrázek) s první operací, první operace s druhou atd.

Jen drobné poznámky:

cmake je potřeba 2.8.8. Měl jsem 2.8.6 a tam není OPTIONAL_COMPONENTS ve find_package.

Jakou Qt potřebuješ? 4.8.x? Nešlo mi uic na mainwindow.h, musel jsem to vohackovat, protože můj uic z 4.7.x nezná tag iconset

Díky za poznámky. Vyvíjím to na Archu, takže mám vždy jen to nejnovější Sám jsem nevěděl, že požaduji až tak nové verze softwaru . Požadavky zahrnu do CMakeLists, ať to řve už při konfiguraci.

[s0]

jou je, tak už to jede. Každopádn tě čeká dlouhá cesta (objevil jsem pár pádů, když jsem klikal nazdařbůh jako zdivočelá opice). Hlavně by bylo supr, kdybys sehnal víc lidí alespoň na to GUI, protože nějaký takovýhle editor bych ocenil i na macu.

No vlastně by mi stačilo resize a ukládání v jiných formátech :)

[stativ]

Kdyby se ti podařilo zjistit nějaké bližší info k některému z těch pádů, bylo by to super. Vím o jednom pádu v rozhraní křivek způsobený přístupem do pole mimo jeho rozsah. Projevuje se náhodně, strávil jsem nad ním už spoustu času, ale zatím se mi ho nepovedlo opravit. Nejdivnější je to, že před každým přístupem do pole kontroluji platnost toho indexu.

[stativ]

Jako na potvoru jsem ten bug teď, chvíli po odeslání postu, nalezl. Budu muset trošku překopat způsob, kterým se určují nejbližší body k bodu, se kterým se pohybuje.

[kralyk z abclinuxu]

To je ta třída HermiteCurve? To int* m_ctrlPointLUT mě teda docela děsí , v tom bude problém, ne? Nešlo by to nahradit vectorem nebo něčím méně nebezpečným? Ten by se taky líp kopíroval...

Jinak ještě mně není jasný účel třídy FixedArray - std::vector má taky konstruktor s parametrem size, v podstatě by se imho dal použít místo toho, nebo tam máš nějaký spešl optimalizace?

[stativ]

To je ta třída HermiteCurve?

Ne, problém je v QCurveWidget a použití proměnných leftNear a rightNear. Když se hýbe s nějakým bodem, tyhle proměnné ukládají index bodu vlevo a index bodu vpravo. Pokud se ale přepne na jinou křivku, tyhle indexy už mohou být mimo rozsah vektoru ukládajícího body nové křivky. Na opravě jsem už začal pracovat (dodělání odkládám na zítřek…).

To int* m_ctrlPointLUT mě teda docela děsí , v tom bude problém, ne? Nešlo by to nahradit vectorem nebo něčím méně nebezpečným? Ten by se taky líp kopíroval...

Je to lookup tabulka fixní velikosti, takže vektor je zbytečný overkill. Krom toho, ačkoliv je zatím využívána minimálně, pro floating point data a větší celočíselné datové typy se do ní bude muset přistupovat při zpracování každého pixelu, takže overhead, který vektor přidá by nejspíš byl problém.

Jinak ještě mně není jasný účel třídy FixedArray - std::vector má taky konstruktor s parametrem size, v podstatě by se imho dal použít místo toho, nebo tam máš nějaký spešl optimalizace?

V podstatě jde o to samé jako výše, vlastně bych mohl nahradit int* m_ctrlPointLUT touhle třídou. Je to minimální obal pro pole, který vlastně navíc ukládá jen velikost (ty výjimky nejsou úplně nutné a asi je nahradím asserty). std::vektor je pro daný účel strašný overkill.

[stativ]

Tak jsem vytlačil opravu

[kralyk z abclinuxu]

Čistě ze zvědavosti: V jakým smyslu je std::vector overkill? Compile-time?

[kralyk z abclinuxu]

Ok, líp jsem si přečetl tvůj komentář...

Je to lookup tabulka fixní velikosti, takže vektor je zbytečný overkill. Krom toho, ačkoliv je zatím využívána minimálně, pro floating point data a větší celočíselné datové typy se do ní bude muset přistupovat při zpracování každého pixelu, takže overhead, který vektor přidá by nejspíš byl problém.

Silně pochybuju, že bys s c-style polem dostal lepší výkon než s std::vector. Viz.

V podstatě jde o to samé jako výše, vlastně bych mohl nahradit int* m_ctrlPointLUT touhle třídou. Je to minimální obal pro pole, který vlastně navíc ukládá jen velikost (ty výjimky nejsou úplně nutné a asi je nahradím asserty). std::vektor je pro daný účel strašný overkill.

Ale vždyť vector je taky v podstatě pouze minimální obal pro pole. Lidi mají představu, že std::vector je jakási velká, složitá a relativně pomalá třída vhodná jen na ukládání velkýho kvanta dat. Není to pravda.

Přijde mi, že použitím c-style array nebo psaním třídy jako je to FixedArray zbytečně vynalézáš kolo a přiděláváš si práci (nehledě na to, že tam mohou být chyby).

Samozřejmě můžeš narazit na nějakej hodně specializovanej případ anebo případně špatnou implementaci STL/kompilátoru, ale tohle bych opravdu řešil teprv až bys nějakej výkonovej problém skutečně naměřil...

[stativ]

Zajímavé… Podle tohoto exámplu by iconset měl být i v 4.7.

[kotrcka]

stiahol som si, klikam na to a nic sa neinstaluje. mas to asi pokazene

mam sice starsi pocitac so starsou verziou operacneho systemu (stale ale podporovanou a oblubenou), ale nemyslim si, ze bude chyba tu..

[stativ]

Příloha:

• not-sure.jpg (77282 bytů)

?

[Bedňa]

Ti to preložím.

Mám Widle XP a nedokážem ani spustiť program.

[stativ]

Hmm. Widle zatím nepodporuju.

Ale dá se to zkompilovat (testováno na Win XP s Visual Studio 2010 Ultimate) po nahrazení všech výskytů snprintf za sprintf a dodefinování #define M_PI 3.14159265358979323846 v src/fotoshock/widgets/QGraph/Edge.cpp.

[vlastikroot]

#define _USE_MATH_DEFINES pred includovani math.h

[stativ]

Nevím proč, ale tahle volba mi ne vždy zafungovala. Možná za to mohly precompiled headers, nebo prostě skrvny na Slunci.

[stativ]

Aha, M_PI neni standard... Tak to to raději zařadím přímo do kódu.

[Bedňa]

Som doinštaloval Boost aj tak mi hádže túto chybu.

Linux Mint Debian (LMDE201204)

[stativ]

Nejspíš to bude ten samý problém, který reportoval už s0. „Opravu“ (vyžadování CMake 2.8.8 a vyšší) jsem pushnul před pár minutami. Řešení – buď použij CMake 2.8.8 nebo uprav CMakeLists.txt, řádek 23: find_package(Boost REQUIRED COMPONENTS system filesystem… tak, aby neobsahoval OPTIONAL_COMPONENTS.

[stativ]

Nakonec jsem se rozhodl opravu revertovat a raději odstranit použití OPTIONAL_COMPONENTS. Přeci jenom v distribucích, které nejsou rolling-release, jako Fedora, OpenSuSE, Mint, Ubuntu a další bude CMake starší než 2.8.8 nejspíš ještě chvíli strašit.

[Bedňa]

Vyvíjať softvér na Archu zaručí že to pôjde len dvoch distribúciach Archu a Gentoo

Editácia zabrala.

Mohol by si pridať do root adresára README.debian

Mám tu ďalšiu chybu:

[ 89%] Generating ui_mainwindow.h
uic: Error in line 41, column 36 : Unexpected attribute theme
File '/home/mario/Programy/photo_shock/fotoshock-code/src/fotoshock/mainwindow.ui' is not valid
make[2]: *** [src/fotoshock/ui_mainwindow.h] Error 1
make[1]: *** [src/fotoshock/CMakeFiles/FotoSHOCK.dir/all] Error 2
make: *** [all] Error 2

[stativ]

Vyvíjať softvér na Archu zaručí že to pôjde len dvoch distribúciach Archu a Gentoo

Přece se nebudu nechávat omezovat pravěkými verzemi SW

Mohol by si pridať do root adresára README.debian

Díky, hodím to tam.

Mám tu ďalšiu chybu:

Hmm, za to bude bude moct staré Qt. Pokud máš možnost nainstalovat 4.8, tak použij tu. Jinak by mělo pomoct odstranit tagy, které způsobují chyby z ui souboru, nejspíš se ale pak rozbijí ikonky.

[Bedňa]

QT za posledný čas spravilo dosť zmien, chyby z QT som odstránil, ale zas som narazil na ďalšie na dnes končím. No čo mám praveký softvér