RAW processing plug-in - any interest?

[Boudewijn Rempt]

On Fri, 6 Oct 2017, PhotoFlow Editor wrote:

> Hi!
> 
> > On 06 Oct 2017, at 16:31, Boudewijn Rempt <boud at 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