Bug #12347
Invert module does not work for raw images
70%
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)
polar_bear.cr2 - raw file of photo taken of color negative (25.1 MB)
processing_examples_dt_gimp.jpg - overview of processed images (2.74 MB)
0001-quick-hack-to-make-inverting-sort-of-work.patch 
(1.37 KB)
screenshot_patched_invert_module.png (748 KB)
polar_bear.xmp (3.59 KB)
History
#1
Updated by Christian Mandel 8 months ago
Maybe related: https://redmine.darktable.org/issues/11164 and https://redmine.darktable.org/issues/10835.
#2
Updated by Daniel Laidig 8 months ago
- File house.cr2 added
- File processing_examples_dt_gimp.jpg added
- File polar_bear.cr2 added
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 8 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?)
#4
Updated by Daniel Laidig 8 months ago
- File 0001-quick-hack-to-make-inverting-sort-of-work.patch added
- File polar_bear.xmp added
- File screenshot_patched_invert_module.png added
Oops, here are the files.
#5
Updated by Aurélien PIERRE 8 months ago
- Status changed from New to Patch attached
- Target version set to Candidate for next patch release
- % Done changed from 0 to 70
#6
Updated by S. Claessen 1 day ago
any update on this? I have been struggling with this and thought it was my camera settings fouling things up until i found the post about the strange behavior of this module with raw files. I really want to ditch my antique coolscan III but it still manages to produce way better quality scans than the dslr and darktable setup.
if needed, i can provide scans and dslr images of the same negative with a pleasing positive as well from the coolscan