I believe many of us work with mutiple programs for photo retouching, as one software can’t fit all needs.
For example, I use DT, C1, Gimp, Nik, ON1, Portrait Pro, and others. Of course I don’t use all of them every time, but every SW has its specific use case where it excels.
When using a suite of programs, you need a pivot program which is capable to run all the others by doing round trip.
DT at the moment can’t be the pivot program as you can’t define a list of external editors. The LUA script for Gimp is only a partial solution.
For example, Capture One has the “Edit with” / “Open with”
Unfortunately, most of those programs will not go beyond a flat 16 bits display referred TIF file as input, but that is enough for many purposes.
Of course a tighter integration with layered linear 32 bits EXR is much better, but you can only do it with one specific program.
I can’t comment on Krita as I don’t use it.
In a rendition, that is, an image file that represents the culmination of a lot of processing to make it look right in a particular medium, I’d like to see stored in that rendition file the entire chain of processing it took to get there, from each of the softwares, in sequence. In the image file. Not in some sidecar.
Image metadata is a mess of blocks and tags organized in rather myopic manners, but XMP starts to stand out as a potential space in which to accomplish such. Like most things here, I know enough about it to be dangerous; looking for more knowledgeable folk to weigh in…
Of course you can, it just isn’t done for you. The gimp script just dumps a tiff to the temp folder and tells.gimp to open it. This script could be adapted to work with any program.
As I said the gimp LUA script is a very partial solution:
can only work with one program, unless you want to change the pointer to the executable each time, which is very slow
if you want to use in sequence more programs on the same image, it will export a new TIFF every time. It is not possible to just open the same TIFF
What would be needed is a new lighttable module where you have a custom list of external editors in a combo box and two buttons “Edit with” (which will export and create a new TIFF file) and “Open with” (which will just open the TIFF file without exporting).
Maybe it can be done in LUA and I’m thinking to do it myself.
Marco
Copy the gimp script, rename it, change the pointer to the program to whatever you want, call the lua script in your lua config file. Then you have one for each editor.
If you want that chain, then you probably don’t want or need to come back to darktable. From your next-in-chain application you’d need another “open with…” type of thing. GIMP is good at this and others here have worked gimp to open other apps.
Further to this, given that different people use different tools for the same role, it’s sub-optimal to have one out of a variety of apps that perform a particular role be a “pivot app”. If, for example, you want to use dt as the “pivot app”, what use is that to someone that uses RT as their raw editor?
Why wouldn’t you come back? Darktable provides an excellent DAM solution, so the goal that I have is to have the entire photo management in darktable. Ideally, each involvement of external software such as gimp would still end in darktable. For 95% of images, darktable alone is sufficient, but for the other 5% (pano, *stacking, heavy retouching, composing) I would still want to do the management in darktable. And maybe even a final touch such as colour look or cropping. Even more ideally, what comes when the images are ready, such as printing, would be manageable by darktable as well.
Ideally, each of the workflow tools such as darktable would provide “headless” modes as well that can be invoked from external to do just the raw editing part.
I’m a long-time user of darktable and became one of its developper. RawTherapee and Digikam are nice, but they are no concern of mine.
darktable has pretty much all you need for non-destructive editings in a classical photography workflow. However, it lacks painting abilities. Hence this topic.
I’m not interested in wiring darktable to every piece of soft around there just for the sake of it. I’m willing to design a fully streamlined 32 floats scene-referred workflow, because it’s consistent for colour handling and it’s the only way to get good results no matter the picture (HDR, SDR, hand-brushed or only non-destructive filters). For productivity reasons, and because there are people who rely on their camera to make a living and don’t have time to fiddle around, this workflow needs to involve a minimum number of software that are fully integrated and consistent in the way they process images. It also needs to keep working on the raw file as long as possible.
So, 3 things are out-of-question here:
going through 16 bits display-referred encodings in exchange files formats,
reproducing a GMIC-like UX, with dozens of scattered toy filters organized in a plugin directory fashion with no consistency whatsoever and too many options everywhere, AKA trying to do everything at once,
supporting non-opensource software because their pipeline is opaque and consistency with the aforementioned goals can’t be asserted.
To sum-up, the specifications book is as follow:
use darktable as the pivot software for DAM, basic editing (technical signal processing and profiling) and multi-output exporting,
develop a fully output-agnostic workflow through all the involved pieces of software, with light transport consistency,
allow for rasterized editing in scene-referred 32 bits float in the middle of darktable’s pipeline,
rasterized editing should be non-destructive (peel the steps into layers, lock the base layer) and every step should be fully reversible without affecting the previous/following steps,
the input and output of the rasterized editing should be updated on-the-fly, respectively from darktable bottom pipeline and to darktable upper pipeline,
the roundtrip darktable <-> raster editing should feel as if it was built-in darktable (no manual file naming, saving, synchronization, etc.)
care about colour spaces + dynamic range only at the “export to display output” step,
share OCIO-like view transforms along the process (but don’t apply them on the actual data, keep data encoding scene-referred).
Would you add “support multiple platforms (Linux / Win / Mac)” to the list of requirements ? If so, I’m 100% with you.
Do you think this DT+Krita workflow would work on Windows / Mac, ot it would rely on Linux-only mechanisms ?
Well, yes, as much as possible. But keep in mind I have zero experience with development under Windows, I use it as a standard user for apps that don’t run on Linux at all.
I suppose so. It’s just file handling, so I don’t see why not.
The whole idea is little revolution but Krita is a drawing machine not tailored to retouch photography… no selection, no mask, no paths, useful filters (Gmic is fun, that’s all) and when you use a lot of layers (20 & more), it becomes very slow. Its GUI is like Rawtherapee… A mess. Gimp 2.10.14 with a tablet is very good, quick, stable, and his future (non destructive workflow!) is a great promise. His development is now very active.
On the contrary… drawing is the whole point here. Did you see my D&B mask above ? For everything else but painting, darktable works. But there is a great deal of the editing (at least for high-end skin works) that is only drawing.
we have wavelets already in darktable, and Krita has them too. I think Mypaint brushes are in Krita as well, but Krita’s brushes are several orders of magnitude above Photoshop and Gimp.
With my work, portrait & products photographer, i need a rock solid layered retouch software, not a photoshop which crash too often… I have dead-ends to respect. Capture1 is an exception in the win10 world. Now with the new great modules, filmic, contrast equalizer, color balance, raw b&w point, etc & your video courses, Dt is better. I often use 2, 3, 4 layers filled with 60mpx/16bits images… The waveletdecompose filter in Gimp decompose the image in numbers of layers you can choose. And you work on each layer with all the tools proposed in Gimp. Also you can check quickly the result. Smoothed brush in Gimp is not a problem, you can set a lot of parameters & build your own brush , also the dynamic effect when you use a tablet. It’s a little bit tricky but with experience, it’s a pleasure. But i wait & look at Krita and your innovations, i’m curious +++.
Krita already has the bare essential for retouching amd photo restoration(the latter is painting). Wavelet decompose already exist inside Krita. Path tools while they are vector can be mimicked by vector layers, and you can save selections as a mask in Krita. Krita has some big advantages over GIMP like fully incorporated nde editing in forms of clone layers, adjustment layer and masks, file layers. Some photo editors do see these and how Krita can be a essential tool. Photoflow do exist, and has those benefits.
My bad! I found the wavelet decompose… Not at the place as i espected & not as described in the manual! Nde editing with clone layers, etc exist in Gimp 2.10 too. I don’t find similar select tools like foreground select & intelligent scissors or luminosity mask setup, but i know Krita not as i know Gimp 2.10. When i speak about nde editing, the future of Gimp is different. The difference between the 2 free software became thin, it’s more a matter of taste & future development. Roadmap - GIMP Developer Wiki… Roadmap | Krita. Gimp stay quicker than Krita on heavy pictures & retouch, thanks to OpenCl. Two little trick make the difference for me, the full screen mode (the normalised F11 key & different aspect between the 2 modes) & when you use the mouse + a tablet, i have two different tools assigned to the mouse versus the pen. Also the brush parameters, dynamics, etc has more granularity.
Clone layers are essentially linked layers that always is a copy of another layer be it group layer, paint layer, file layer, another clone layer. It isn’t just a linked layer that has been duplicated. The benefits are real with adjustment masks/layers and folder. Luminosity mask in Krita is a little bit more complicated, but you can have nondestructive version of that pat david tutorial, I could pm you a tutorial on that. Magnetic selection tool do exist in Krita 4.3, and it is better than Photoshop. Foreground extraction is actually planned on kde phabricator on krita.
I had less work these last weekend & i was alone, so i tried to use Krita instead of Gimp (i don’t use Photoshop anymore & will never do i) & the photography manipulation template as a part of my workflow, in a professional & effortless way. First, cieLAB is not a good working color space choice. A template… It’s tricky & time consuming, in a professional workflow. I repeat it, Krita is an excellent software… To sketch, draw, paint & animate, not to retouch, it will never not be. The Krita’s history say it, you say it & the roadmap tell nothing else. The brush flow’s granularity is similar for the softwares, with a different approach. The Gimp’s evolution is now great, for retouching photography, internal’s workflow in linear color mode, Opencl, useful filters, MyPaint brushes, regular updates & a dream roadmap. You need to “repaint” your photography, the 2 are suitable. But if you have to spend more time to retouch your image than to light & shot it, in studio, you have a problem with the lighting. You need to rethink & master the light. Too much retouch/lighting repaint, kill the photographic aspect of the image. In 3D creation aiming to manufactured’s product representation, after photographic rendering, the lighting & retouch are entrusted to experienced photographers or photographic’s retouch specialised teams, to give a photographic touch, and it’s not an easy work.
