Wiring darktable with Krita [nsfw]

Software darktable
,
1

Since the retouch and liquify modules have been merged in darktable, I have not used Photoshop anymore to do my skin retouches, since it covers most of my needs. There is still a thing I miss from Photoshop: its painting abilities, to do advanced skin retouch (airbrushed dodging and burning) and specific colour edits without all the burden of sliders and parameters tuning.

Layered painting options give a lot more freedom and fill the gap between painting and photography. (example of stuff I did with darktable + PS). Also, I enjoy this kind of retouching much more than the sliders pushing process in dt (it’s more organic).

I knew about Krita for a long time but just tested it recently. Its painting abilities are on-par with those of Photoshop or better (many options to create your own brushes + efficient UI), and far superior to those of Gimp (witness the settings layers, OCIO colour management, smart patch tool and the no-nonsense UI), but you also get a fully scene-linear 32 bits workflow.

I’m considering wiring Krita and darktable in a seamless way, kind of the same thing you would get with Photoshop and Lightroom, using Smart Objects and such.

My preliminary idea would be to add a Krita module in the darktable pipeline, before the non-linear adjustments, like that:

RAW → WB + demosaicing + denosing → input colour profile → global colour adjustments → [Krita] → filmic/base curve → output colour profile

The darktable Krita module would send its input to the base layer of a new Krita project (32 bits float linear REC2020), open Krita, allow you to add layers and paint. Once you save the Krita file, its output would be re-injected in darktable pipeline and allow you to finish the tone-mapping and stuff, export to your usual media and be done.

When you change parameters in previous modules in dt, the base layer of the Krita file will be updated accordingly (with the input of the Krita module), then Krita will be run in CLI or something to process the stack of layers, then the updated output will be sent to darktable pipe again.

What do you think about the general idea/feature and the implementation method ?

27 Likes
2

There’s not much Krita users here, so I don’t expect much feedback, however a few Krita users that prefers it to GIMP would like it.

@betazoid This is of interest.

1 Like
3

I’ve used krtia on occasion, though not well, aw I’m not gifted at painting, but this is a really cool feature and I’m sure it’d be welcomed by many.

4

From my point of view the major advantage of Krita is its ability to work in larger color spaces, this is something that Gimp cannot do so far, unfortunately, and there are legitimate doubts that it never will. Although I think it’s a pity since Gimp is or used to be some kind of “cult”.
I use Krita mainly as a “bridge” to GMIC, where I use the inpaint and noise reduction and/or sharpening filters, although as far as noise reduction and sharpening is concerned, I use the detect edges filter in Krita before GMIC.
However, I’d be more happy if there was a direct plugin to GMIC in darktable and a noise reduction and sharpening module that uses edge detection directly in darktable. So there were no need to go to Krita.
Well, I think those who were at the last LGM know all of this already.
But Aurélien’s ideas sound nice, I would not mind them at all.
Maybe one more thing: I do not use Krita often.

5

Sounds nice. We already have a lua sript for Gimp written by @wpferguson , that does something simmilar:

You just need to search and replace gimp with krita and done.

What is missing is the last paragraphe:

When you change parameters in previous modules in dt, the base layer of the Krita file will be updated accordingly (with the input of the Krita module), then Krita will be run in CLI or something to process the stack of layers, then the updated output will be sent to darktable pipe again.

Here we are missing a Lua event to get notified as soon as parameters change.

6

This is a bit less polished than what I have in mind because you need to reimport the Gimp output in lib, not even as a .xcf but as a flat file. I’m aiming toward something that can save .kra as a sidecar file of your raw and keep the scene-linear 32 bits float all the way through, so you don’t carry a 8/18 bits integer duplicate, possibly display-referred, of your raw file in your lib.

2 Likes
7

Anyway, at the moment Krita seems to be the best or better “old school” open source image editor, i.e. better than Gimp. From time to time there are tasks where “old school” is needed.

1 Like
8

@anon41087856 I would absolutely love this kind of integration.
Currently, I am using a workaround with a krita.lua script. But a lot of info such as the krita changes get lost, if you do not save the kra file explicitly.

9

That’s great idea.
I was thinking about the way back, how to get external tif file into darktable, so i could use the powerful parametric masking feature of darktable for blending. I think this feature isn’t available in any other sw in such extent.
I heard long ago that there is way to misuse watermark module for this, but was accepting only embeded low q jpgs.

10

You are right, the Lua script is very limited. But it is what is possible at the moment without changing the darktable code. A real nice solutions would be a module that starts Krita (or any other program) and a method to attach or link files to a photo.
Like @betazoid wrote, it would be useful for gmic too. And I can think of having gegl, imagemagic, vips or even blender in there too.
Perhaps the most flexible solution would be a module that starts a Lua script. Then you don’t need to hardcore any program. I like the idea of simply running programs via CLI, because it is simple and easy to debug. But at the same time you need to work with files and that is slow. Some kind of direct communication would be much faster but needs more work on both sides. (I’m just brainstorming.:thinking:)

1 Like
11

If you did it with lua, you would need a function to take the krita output and inject it into the pipeline. It would be nice if the function was not krita specific so that we could use the injection for other pieces of software, such as gmic, imagemagick, gimp, blender(?), …

However, if we do this then we cross the line of lua isn’t supposed to be used in darkroom mode.

Bill

1 Like
12

@Tobias, you are on the same track that I am, just quicker :smiley:

13

I wonder if the other way round would make sense as well or even more sense, that you have a darktable layer (or several) in $pixeleditor. That would maybe mean to better separate the raw processing from the library such that you can have the former alone. And the pixel pipe would have to accept either an input file or the pixel data from the layer below. Anyway, just thinking out loud … In adobe world I think they have both options. But then you could have darktable layers embedded in $pixeleditor documents embedded in darktable pipelines embedded in …

14

Krita does support file layers already, so in part, perhaps the OP could allow import of darktable files.

@Carmelo_DrRaw Any inputs since you made Photoflow plugin for Krita?

15

If I remember correctly someone was working on adding gmic filters to darktable and had implemented a few. Their code might provide a starting point. Darktable PR 2557

16

To be clear, I don’t want filters (GMIC, GEGL or else). I believe filters (whatever they are) should be integrated in darktable as stand-alone modules, in order to wire them to the OpenCL pipe when available, and optimize them manually because these libs are usually painfully slow and don’t always use the same data structure as darktable.

What I’m after is a way to integrate painted layers (stuff that can’t be written as filters) in the scene-linear part of darktable pipe, meaning bypassing every conversion to integer formats or colour management massaging, to paint with linear light without having to export, import, re-export, re-import, duplicate, check encoding, check colour space, read some doc, ask questions on a forum, do stupid things without knowing it, claim that the feature doesn’t work, argue that darktable is garbage, etc.

For me, the photographer workflow ends up at the export step, which is better handled by darktable, as well as the file management and EXIF business. So darktable is the core of the workflow, and it makes more sense to squeeze Krita in darktable than the opposite.

Lua is more than limited since it doesn’t allow to deal directly with the pipeline, but only with I/O. That means re-importing Krita/Gimp output as a standalone picture in the collection, and finishing up the work. It duplicates digital assets and doesn’t sound like streamlined workflow, since you need to split your edits between 2 files, and manage updates manually.

Also, I’m pretty sure users will keep their bad habits of exporting darktable history to Gimp/Krita including the non-linear transforms, in 8 or 16 bits integers, which will trigger a whole load of issues if they do compositing and blending, but most of them don’t know it.

The point of branching Krita directly on darktable’s pipe is I can force the operations to happen before the non-linear transforms and prevent a whole set of troubles very few users are aware of.

3 Likes
17

That’s an important point, for several reasons. I agree with you that for dodge/burn/heal etc. this approach makes most sense. But I would guess that once the power is given to the people, they will use it for any purpose you cannot think of. But as long as the integrated $pixeleditor can be at any position in the pixel pipe and can read external resources, I think this will suit most use cases. “Linking to” more than one image from darktable would be a great addition, e.g. by representing the actual image as one layer, but having the ability to drag additional images from darktable into the same “document”.

The point is, that the end-to-end workflow (raw image from camera → exported image) does work most of the time, but there are many use cases that do not (yet) fit into it.

My personal use case is e.g. editing of scanned film negatives with infrared scratch detection information in the alpha channel. For now, the workflow is cumbersome, gimp+g’mic for scratch removal with my g’mic plugin and using the inpainting power of g’mic, then into darktable for correction and colour look. I would therefore try to get the $pixeleditor module before invert in the pixel pipe and make it load and preprocess the image. That would fit as long as I would be able to load images directly and use $pixeleditor as a source.

Another example would be compositing. There, it would be handy the other way 'round, to have several source images from darktable added into one $pixeleditor document, which is again managed in darktable.

Just some thoughts …

18

Sure, but let’s focus on the problem scope defined here. What users will do ultimately is their responsability and will void the guaranty if they don’t comply with the guidelines.

Indeed, good idea, not sure how to bend the UI to make that not aweful though, but I will keep it in mind.

Compositing in scene-linear is definitely in the scope here.

1 Like
19

Luckily the module did not recognize this yet and still accepts my tiff input files (without alpha channel). As many people report, it even works much better with real scans than with raw files.

20

My bad, I just checked the source code, it works on demosaiced/non-mosaiced data too.