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

List:       kde-kimageshop
Subject:    Re: RAW processing plug-in - any interest?
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2017-10-06 16:41:12
Message-ID: alpine.LNX.2.00.1710061836590.15063 () calcifer ! valdyas ! org
[Download RAW message or body]


On Fri, 6 Oct 2017, PhotoFlow Editor wrote:

> Hi!
> 
> > On 06 Oct 2017, at 16:31, Boudewijn Rempt <boud@valdyas.org> wrote:
> > 
> > Yes -- I remember looking at that. There are a bunch of problems with it, of \
> > course, since it just copies the tiff import code, and that's not necessary. For \
> > starting photoflow, it's better to use QProcess instead of system(cmd). For \
> > finding the temp dir, QStandardPaths::TempLocation is the correct thing to use. \
> > It might also be better to use QTemporaryFile to actually generate the \
> > interchange file. 
> > It would also be better to work against master for this project, the \
> > import/export code has changed a lot since then! 
> 
> Indeed, the code on my forked Krita on github was just a quick hack, to prove that \
> the implementation of the RAW loading plugin would work and would not be too \
> difficult to implement. 
> Provided that I get a de developer account (I still have to try out the \
> procedure…), what would be the right way to proceed? Make a new branch in the \
> official repository and put the new stuff there? Or what? Sorry for the newbie \
> question, but that's my first time collaborating with a KDE project...

Yes -- that would be the right way to proceed. See \
https://community.kde.org/Infrastructure/Get_a_Developer_Account . Usually we'd like \
to see some patches before we say "yes, give him access" to our sysadmins, but here \
the situation is different. So, just apply & give my name.

> > Yes, this could be interesting, but it's going to be tricky. In Krita, a layer \
> > has the original layer data and the projection of the layer as modified by masks. \
> > Krita's non-destructive editing works through filter layers and masks, so the \
> > correct way to implement this would be to create a photoflow filter that can be \
> > used in a filter mask or filter layer. Note however that since these are part of \
> > the graph, any change underneath the photoflow filter mask/layer would mean you \
> > would have to shell out to photoflow and recalculate, you cannot just use the \
> > cache. 
> > Also, Krita's projection update is tiled and threaded, which adds lots of \
> > complications.
> 
> Maybe the G'MIC extension plug-in could be the right example to follow? I guess it \
> is also _not_ re-processing automatically the layer data whenever there is a change \
> underneath… am I right? What do you think?

Well, g'mic currently isn't used non-destructively. That is, you cannot make a g'mic \
based filter mask or layer. People have asked for that, but I'm not sure I'm up to \
it. g'mic is also an external process, but communicates using sockets and shared \
memory (which is a problem on OSX), and it doesn't support running with a particular \
set of settings anyway. It always pops up the gui, unless you run it like "apply last \
filter again".

> Nevertheless, the key point with the photoflow plug-in would be to have the \
> possibility to store the filter configuration as meta-data, so that the filter \
> status can be restored next time it is executed on a previously created layer.

Yes, that's easy enough -- create a photoflow filter that uses this data as its \
filter ocnfiguration object.

> This is something quite new, giving the possibility to "group" a whole bunch of \
> edits into a single layer, and still be able to come back to the original edits and \
> tweak them further if needed. 
> I wonder if we can find a way to attach a string buffer to a Krita layer, and have \
> it saved to the Krita image for later re-use… Any idea?

That would make it more like the way we work with layer styles -- it's a possibility, \
of course, and would circumvent the problems with updating the stack with filter \
layers and masks.

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



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