RAW processing plug-in - any interest?

Sat Mar 11 12:52:58 UTC 2017

> On 11 Mar 2017, at 04:27, EI <geneing at gmail.com> wrote:
> 
> Screencast looks impressive! 

Thanks! :-)

> 
> - I don't think there a way to prioritize which plugin will handle loading. One option may be to add a menu item under "File" for PhotoFlow. The actions are configured through krita/kritamenu.action
> 
> - Krita can keep almost arbitrary metadata for the loaded image. An example can be found here: krita/libs/image/tests/kis_meta_data_test.cpp. The code itself is in krita/libs/image/metadata/. However, your plugin would have to write this metadata to the raw file and then read it. Storing metadata in an xml "sidecar" file may be easier. 

I will look into both...

> 
> - Have you looked at QProcess? http://doc.qt.io/qt-5/qprocess.html <http://doc.qt.io/qt-5/qprocess.html>
That’s exactly what I was looking for, thanks!

> 
> - You can probably request a developer account. boud at valdyas.org <mailto:boud at valdyas.org> may be able to help. Is your plugin code available through https://github.com/aferrero2707/PhotoFlow <https://github.com/aferrero2707/PhotoFlow>? 

I have forked the Krita github repository and issued a pull request: https://github.com/KDE/krita/pull/1 <https://github.com/KDE/krita/pull/1>

I think that for the moment this is probably the safest way to proceed…

Andrea

> 
> Eugene
> 
> 
> 
> 
> Today's Topics:
> 
>    1. Re: RAW processing plug-in - any interest? (PhotoFlow Editor)
>       (PhotoFlow Editor)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 9 Mar 2017 14:41:59 +0100
> From: PhotoFlow Editor <photofloweditor at gmail.com <mailto:photofloweditor at gmail.com>>
> To: Krita's developers and users mailing list <kimageshop at kde.org <mailto:kimageshop at kde.org>>
> Subject: Re: RAW processing plug-in - any interest? (PhotoFlow Editor)
> Message-ID: <DFC8CB20-2075-4244-94DA-10377E0FC8FF at gmail.com <mailto:DFC8CB20-2075-4244-94DA-10377E0FC8FF at gmail.com>>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi!
> 
> the initial implementation of the RAW loading plug-in turned out to be relatively easy… just a couple of spare-time coding hours to achieve the result shown in this screencast: https://youtu.be/9K6RJv-O6Yw <https://youtu.be/9K6RJv-O6Yw> <https://youtu.be/9K6RJv-O6Yw <https://youtu.be/9K6RJv-O6Yw>>
> 
> 
> However, this is just the very beginning. Unfortunately I do not have much time to chat on IRC, only to read/write emails from time to time. Therefore, if any krater developer is reading those lines, here are a few questions (some might be trivial):
> 
> - is there a way to prioritise the file loading plug-ins in Krita? In my first experiments I had to remove the official impex/raw plug-in from the CMakeLists.txt file, otherwise my own plug-in would not be invoked…
> 
> - does Krita provide a mechanism to store arbitrary meta-data in the image structure? The idea would be to store the RAW processing parameters directly inside the krita image, so that next time the photoflow plug-in is invoked it can re-open the RAW file and restore the last saved processing parameters
> GIMP provides such mechanism through functions like gimp_parasite_new() (https://developer.gimp.org/api/2.0/libgimpbase/libgimpbase-gimpparasite.html <https://developer.gimp.org/api/2.0/libgimpbase/libgimpbase-gimpparasite.html> <https://developer.gimp.org/api/2.0/libgimpbase/libgimpbase-gimpparasite.html <https://developer.gimp.org/api/2.0/libgimpbase/libgimpbase-gimpparasite.html>>) and gimp_item_attach_parasite() (https://developer.gimp.org/api/2.0/libgimp/libgimp-gimpitem.html <https://developer.gimp.org/api/2.0/libgimp/libgimp-gimpitem.html> <https://developer.gimp.org/api/2.0/libgimp/libgimp-gimpitem.html <https://developer.gimp.org/api/2.0/libgimp/libgimp-gimpitem.html>>)
> 
> - is there a way in Qt to spawn a process and pass parameters to it in the form of QStrings instead of char*? I would need this to properly invoke the photoflow executable with UTF8 file names…
> 
> - what is the best way to distribute the preliminary code so that experts can have a look?
> 
> 
> By the way, the photoflow executable used for the test in the screencast is actually this AppImage package: https://github.com/aferrero2707/PhotoFlow/releases/download/continuous/PhotoFlow-20170307-git-stable-d1501a91826e6b768af51bf6c734bd989507915d.glibc2.14-dbg-x86_64.AppImage <https://github.com/aferrero2707/PhotoFlow/releases/download/continuous/PhotoFlow-20170307-git-stable-d1501a91826e6b768af51bf6c734bd989507915d.glibc2.14-dbg-x86_64.AppImage> <https://github.com/aferrero2707/PhotoFlow/releases/download/continuous/PhotoFlow-20170307-git-stable-d1501a91826e6b768af51bf6c734bd989507915d.glibc2.14-dbg-x86_64.AppImage <https://github.com/aferrero2707/PhotoFlow/releases/download/continuous/PhotoFlow-20170307-git-stable-d1501a91826e6b768af51bf6c734bd989507915d.glibc2.14-dbg-x86_64.AppImage>>
> I simply downloaded the package, made is executable with
> 
>     chmod u+x PhotoFlow-20170307-git-stable-d1501a91826e6b768af51bf6c734bd989507915d.glibc2.14-dbg-x86_64.AppImage
> 
> and moved is to a folder in the PATH so that is gets automatically found:
> 
>     mv PhotoFlow-20170307-git-stable-d1501a91826e6b768af51bf6c734bd989507915d.glibc2.14-dbg-x86_64.AppImage $HOME/.local/bin/photoflow
> 
> 
> This AppImage should be compatible with most of the current Linux distributions, and requires no installation of additional packages… just download the AppImage and run it!
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20170311/f846f874/attachment.html>