Switch to PNG during processing


(pphoto) #1

Currently I think of changing my image processing workflow, mainly for two reasons:

  • Performance
    Darktable’s processing times increase the more modules I add. After an analysis of Darktable’s processing times (starting DT with ‘darktable -d perf’) I found out that most of the processing times is used by modules that I use at the beginning of my workflow and which don’t change later. For example those are denoising, defringing, demosaicing. In portraits I got long calculating times after using the retouch module (sometimes with a second module when reaching 300 spots to heal).

  • Re-editing
    Some days ago I looked at older images and came to the idea that today I would do a much better job on the image. So I decided to work on an old RAW again. In Darktable I deleted some of my old edits and some other ones I kept.

So I came to the idea to change my processing workflow. The idea is to start with some basic edits on the RAW file like demosaicing and denoising and exporting that result as a 16bit PNG.
At that stage I could do some edits in Gimp (removing an overexposed area in the background for example or soing some detail work on hair in a portrait)
After that I would re-import that PNG in Darktable and continue my edits there.

My question here is: Do I loose anything (except for interrupting the non-destructive process) when working with 16bit PNG instead of the RAW file? Stuff like demosaicing and some other basic edits are already in the PNG.


Why not TIFs? I sometimes have tagging issues with PNGs and colour profile support isn’t good.

(pphoto) #3

I did a bit research about differences between TIFF and PNG.
What I know unit now is that both formats support 16 bit colors.
It seems that color profiles can be embedded in PNG, too


It is but not all apps can read and write the tag, even the ones we talk about here; so double check your work.

(pphoto) #5

I don’t use tags on my image. EXIF data is all I use.

(Mica) #6

Why not leave denoise and defringe until the end of your workflow? Round tripping is cumbersome and difficult to keep track of.

I think PNG is the wrong choice for this. Tiff is quite standard.

(pphoto) #7

Why not leave denoise and defringe until the end of your workflow? Round tripping is cumbersome and difficult to keep track of.

That’s a good point. I already started to deactivate some modules during processing. Just before the final export i reactivate them and switch demosaicing from PPG to Amaze with all options maximised.
I think I try this way for the next pictures.

Today I did a bit of research importing a few Darktable module durations into a spreadsheet.

I will do some more tests with my images and find out which modules do have the most impact on performance times.
Then I will have a better understanding which modules I should use the last in my process.

(pphoto) #8

Think I got it now. First I calculated the relative time for each module corresponding to the total image processing time in seconds.
I did that for 4 images, combined the results in one table and sorted it after the relative time spent.


The modules with the biggest impact on processing time are highlighted yellow.

This has led me to the following conclusions:

  • Defringe / Chromatic aberration: disable until final export
  • Demosaic: keep at simpltest PPG-setting and change for final export
  • Haze removal: since this has impact on the image’s brightness and color I keep it on
  • Highlight reconstruction: keep at ‘clip hightlights’ and change for final export
  • Output color profile: since this has impact on the image’s brightness and color I keep it on
  • Denoise modules: disable until final export
  • Retouch: One part is removing blemishes on skin, another part is softening skin using blur. Blurring changes colors in a face so I use one module for blemishes and another for skin softening. After the retouch edit I disable the one for blemishes and keep the module for blurring.

I will try these modifications in the next images I edit, maybe I can keep the processing times low enough for efficient working…

(Alessandro Amato Del Monte (Aadm)) #9

Love these stats! You’re giving away very clear indications about what modules are heavier, I guess I’ll follow your guidelines and keep defringe, demosaic and highlight reconstruction under check.

I wonder if you could somehow automate the process, e.g., you turn on an individual module, check the settings, then deactivate to do all the rest, and on export just switch back on those “heavy” modules.

…thinking a bit more about it, the modules that I’ve listed above are almost all withouth a great deal of finesse, I mean they’re either on or off, I never play with sliders like I’d do with tone curves or exposure for example. Demosaic, for my Nikon raws it’s either PPG or Amaze-5 times, etc. So maybe a simple a style to be activated on export would be enough?


Like so?

I find the recommended process of manually enabling and disabling modules at certain times cumbersome as well

(pphoto) #11

I understand the need to speed up the processing times. That gitlab issue sounds like an automatic enabling and disabling of modules depending on a GUI state.
I suspect that users would have to keep in mind which modules are active and inactive to be able to rate the impact of edits.
I think that is very cumbersome and would make editing more complicated.

Putting some modules in the export process would help a bit, but in my opinion this would only work with modules that have simple on-off switches. Like ‘chromatic aberration’ or ‘demosaic’ with certain options.

With other modules I need to find the correct settings, like ‘defringing’ for example. Their settings are individual in each image and sometimesI later detect that I need to do some changes again.
For example I do defringing early in the process and later I find an area where some fringing is left or some colors are greyed out.
For these kind of situations my first approach with exporting an early version of the image would result in a heap of rework.

Currently I think that manually turning on and off is the most efficient way to handle this from the viewpoint of the user.

The ‘active modules’ view in the darkroom looks like an easy way to activate and deactivate modules.

From a developer’s point of view there are some modules not using OpenCL for processing. Hope that those modules move to OpenCL soon :wink: