Project

General

Profile

Bug #12347

Invert module does not work for raw images

Added by Christian Mandel 3 months ago. Updated 2 months ago.

Status:
Patch attached
Priority:
Low
Assignee:
-
Category:
Darkroom
Target version:
Candidate for next patch release
Start date:
09/29/2018
Due date:
% Done:

70%

Affected Version:
2.4.4
System:
Ubuntu
bitness:
64-bit
hardware architecture:
amd64/x86

Description

As discussed here: https://discuss.pixls.us/t/inverting-photos-of-color-negatives-with-darktable/9140, there are issues with inverting raw files. Since it becomes more and more popular to digitally photograph old film instead of real scanning, this is unfortunate. I tested with the files provided in the thread linked above and with my own scans with darktable 2.4.4, and the colour picker seems not to provide the correct colour in the raw case but works for my scans (tiff files).

house.cr2 - raw file of photo taken of color negative (24.8 MB) Daniel Laidig, 09/29/2018 02:16 PM

polar_bear.cr2 - raw file of photo taken of color negative (25.1 MB) Daniel Laidig, 09/29/2018 02:17 PM

processing_examples_dt_gimp.jpg - overview of processed images (2.74 MB) Daniel Laidig, 09/29/2018 02:18 PM

0001-quick-hack-to-make-inverting-sort-of-work.patch Magnifier (1.37 KB) Daniel Laidig, 09/30/2018 11:35 PM

screenshot_patched_invert_module.png (748 KB) Daniel Laidig, 09/30/2018 11:35 PM

polar_bear.xmp (3.59 KB) Daniel Laidig, 09/30/2018 11:35 PM

History

#2 Updated by Daniel Laidig 3 months ago

I have attached the two raw files I posted in the pixl.us thread and an overview image showing the results of using the darktable invert module and of inverting using GIMP (all CC-BY-SA).

I would also like to point out that it is quite easy to get good results using GIMP (without manual tuning except for optionally picking the film base color like in the darktable module).

Based on a tiff exported using darktable with the basecurve disabled:

- pick the color of the unexposed part of the film
- create a new layer with that color and choose the blend mode "divide"
- merge the two layers
- invert the image (colors > invert)

The image still looks flat (which can easily be solved), but the colors are quite good.

Another approach using GIMP is to stretch the histogram of all color channels individually:

- crop the image so that no unexposed part is in the image
- colors > invert
- colors-> levels > auto input levels (just called "auto" in GIMP 2.8)

Of course, this uses information from the whole image and makes assumptions that might easily be wrong for some images. But I think the first method that uses the film base color should be quite comparable to what darktable's invert module should be doing (and shows that it is possible to invert the image quite well based on the color of the unexposed film).

#3 Updated by Daniel Laidig 3 months ago

I have played around with the code of the invert module and I think I have found out what is going on and how to potentially fix it.

What darktable is doing is film_color - in (for each channel, where film_color is the value of the unexposed film and in is the input value of the pixel). When inverting in GIMP using the divide layer, the operation basically is 1 - in/film_color. The difference between the operations is a multiplication with film_color, which means each color channel is scaled differently.

I have hacked the divide version into the invert module (in a not very nice way by disabling the SSE implementation -- I don't have opencl anyway). It turns out that when disabling white balance (as picking the film color already does white balance) and also disabling the base curve (why?), I get an inverted picture with the right colors. It is still quite dull, so I cropped it and stretched the histogram using a tone curve with RGB chroma scaling.

I attached a screenshot of darktable with the inverted picture, the quick and dirty patch I used and the xmp. Of course the patch is far away from being something that could be merged. I am also not sure what would be needed for that (Generally, is this the right approach? Is there a way to make it better and require less postprocessing? What about backwards compatibility?)

#5 Updated by Aurélien PIERRE 2 months ago

  • % Done changed from 0 to 70
  • Status changed from New to Patch attached
  • Target version set to Candidate for next patch release

Also available in: Atom PDF