[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: RAW processing plug-in - any interest? (PhotoFlow Editor)
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2017-03-13 10:17:29
Message-ID: alpine.LNX.2.00.1703131112570.26837 () calcifer ! valdyas ! org
[Download RAW message or body]


On Thu, 9 Mar 2017, PhotoFlow Editor wrote:

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

Cool! I guess I should've read the entire backlog before writing my previous mail :-)

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

The X-KDE-Weight entry in the json files should work like that. But like I said in my \
previous mail, maybe we should add something that makes it possible for users to \
switch between two existing plugins that have the same weight. That would have to be \
done outside the actual plugin, which breaks separation of issues a bit, so it needs \
a bit of thinking.

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

Yes -- KisAnnotation is meant for that purpose.

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

Yes: QProcess should be used for that. See http://doc.qt.io/qt-5/qprocess.html

> - what is the best way to distribute the preliminary code so that experts can have \
> a look?

A git repo anywhere should be fine!

> 
> 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-201 \
> 70307-git-stable-d1501a91826e6b768af51bf6c734bd989507915d.glibc2.14-dbg-x86_64.AppImage \
> <https://github.com/aferrero2707/PhotoFlow/releases/download/continuous/PhotoFlow-20 \
> 170307-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! 

Yes, appimages are cool :-) We're also distributing Krita as appimages for Linux.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org



[prev in list] [next in list] [prev in thread] [next in thread]