RAW processing plug-in - any interest?

[EI]

Screencast looks impressive!

- 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.

- Have you looked at QProcess? http://doc.qt.io/qt-5/qprocess.html

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

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>
> To: Krita's developers and users mailing list <kimageshop at kde.org>
> Subject: Re: RAW processing plug-in - any interest? (PhotoFlow Editor)
> Message-ID: <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>
>
>
> 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>) 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>)
>
> - 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-d1501a91826e6b768af51bf6c734bd
> 989507915d.glibc2.14-dbg-x86_64.AppImage <https://github.com/
> aferrero2707/PhotoFlow/releases/download/continuous/
> PhotoFlow-20170307-git-stable-d1501a91826e6b768af51bf6c734bd
> 989507915d.glibc2.14-dbg-x86_64.AppImage>
> I simply downloaded the package, made is executable with
>
>     chmod u+x PhotoFlow-20170307-git-stable-d1501a91826e6b768af51bf6c734bd
> 989507915d.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-d1501a91826e6b768af51bf6c734bd
> 989507915d.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/20170310/d8364e42/attachment.html>