RAW processing plug-in - any interest?

Fri Oct 6 14:31:45 UTC 2017

On Tue, 3 Oct 2017, PhotoFlow Editor wrote:

> Hi!
> 
> I am planning to resume the work on the PhotoFlow Krita plug-in, with the goal of duplicating the functionalities already provided by the equivalent GIMP plug-in.
> 
> Here is a short description of what I am aiming for:
> 
> - a file loader plug-in that allows to open RAW images, process them in photoflow and then send the result to Krita. This is already existing and available for testing here: https://github.com/aferrero2707/krita <https://github.com/aferrero2707/krita>

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! 

> - a filter plug-in that allows to send the contents of a Krita layer to PhotoFlow, do some editing, and then send the result back to Krita by either replacing the layer or adding a new one. This is my next goal…
> 
> PhotoFlow is a non-destructive editor, and the editing configuration can be saved in special XML files along with the original pixel data. This is used in GIMP to provide a non-destructive filter plug-in, which works in the following way:
> 
> - the first time a layer is opened with the PhotoFlow filter, the image data is simply saved into a floating-point TIFF file that gets opened by PhotoFlow
> - after the editing is finished in PhotoFlow, the result is saved back as a floating-point TIFF, together with the XML configuration of the editing that has been performed
> - the output TIFF data is loaded as a new layer, and the XML configuration data is associated to this new layer as meta-data
> 
> At this point we have the new layer (B) with the output of photoflow sitting above the original layer (A). If the user runs again the photoflow filter plug-in on layer B, the plug-in will detect the presence of the XML meta-data, and will give the option to resume the stored edit instead of starting a new one. In this case, the contents of layer A as well as the XML configuration will be sent to the plug-in, and all the editing steps needed to go from layer A to layer B will be restored, ready for further tweaking.
> 
> In some sense, this provides the infrastructure for running a non-destructive filter plug-in, which keeps track of all the editing steps applied in the plug-in itself. Of course, one can also go from layer B to a new layer C, and so on…
> 
> Just to get an idea, you can see this concept in action in the GIMP case here: https://www.youtube.com/watch?v=945OnK93C1g <https://www.youtube.com/watch?v=945OnK93C1g>
> 
> 
> In order to implement the same mechanism in Krita, and provided you are interested in such an extension, I would need to find the proper way to store some meta-data, in the form of an array of characters, in the information associated to Krita layers. 

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.

> To me, it seems that KisAnnotation objects are the most appropriate solution, but as far as I understand they can only be associate to the whole image, not to individual layers. Is this correct? What would then be the best solution?

Yes, that's correct. We do have per-layer metadata, for things like exif and so on, but that's not quite suitable here. 

> 
> 
> Thanks a lot in advance!
> 
> 
> > On 13 Mar 2017, at 11:19, Boudewijn Rempt <boud at valdyas.org> wrote:
> > 
> > On Fri, 10 Mar 2017, EI wrote:
> > 
> >> 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.
> > 
> > The metadata is really meant for official metadata structures, like exif. Krita metadata is also associated with the layer, not the image. I'm not sure it's the right thing here, better investigate KisAnnotation.
> > 
> >> 
> >> - 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?
> > 
> > To get a KDE developer account, follow https://community.kde.org/Infrastructure/Get_a_Developer_Account and mention me as sponsor, indeed.
> > -- 
> > Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
> 
> 

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