hello geeks, the colour pickers (white balance and film colours) are pushed on the branch 
I’m considering adding other pickers for Dmax (max RGB, same as filmic) and inversion offset (min RGB, same as filmic), then the OpenCL code should take me 30 min of work, and it will be ready to go.
This is the white-balanced polar bear:
Looks great.
You (kind of) asked for it, so here’s the challenge 
: If we only could make use of the alpha channel that has the information about scratches and dust from an infrared scan directly in darktable … (find my musings about this topic here: Scanned image scratch removal with “ICE”)
That would require to modify the TIFF reading library in dt to map the 4th channel of the image to some mask buffer, then to wire the mask to some sort of inpainting algo. I have thought about it (you bet), I have some (half-working) inpainting code in image doctor, so once I get image doctor to work properly (probably at least 3 months of work), it will be feasible.
This module started as a joke, while drinking beers, with a friend who happens to scan a lot of negatives these days and be quite unpleased with the results. It took 4.5 hours to get the whole prototype to work, then 3 days to test and debug.
@anon41087856 not sure if this means something:
[ 93%] Building C object src/imageio/format/CMakeFiles/tiff.dir/tiff.c.o
In file included from /home/gustavo/darktable/build/src/iop/introspection_negadoctor.c:5:0:
/home/gustavo/darktable/src/iop/negadoctor.c: In function ‘process’:
/home/gustavo/darktable/src/iop/negadoctor.c:243:6: note: The ABI for passing parameters with 64-byte alignment has changed in GCC 4.6
void process(struct dt_iop_module_t *const self, dt_dev_pixelpipe_iop_t *const piece,
^~~~~~~
[ 93%] Linking C shared module libhighpass.soAren’t these the best ideas 
…
As scanning of 1 film takes approx 2 hours, 1 slide magazine approx. 4 hours, digitizing the remaining material will take another half a year. So Christmas 2020 would be sufficient for the release of this feature . But seriously, thanks for what you already implemented, this looks amazing. I have to get a new computer to be able to compile darktable again and test your code …
Here’s an attempt to an edit with negacolor. I found this one particularly difficult, not sure if I messed something while capturing the negative, but there is this strong color cast at the bottom corners that I could not get rid of. Other images from the same negative strip don’t present this issue. Now thinking about it, could this be the camera vignetting, since this is the only image where I’ve pushed the darks this much? In the negative, these corners lie on the brightest areas of the negative, so vignetting may be noticeable.
The image I used to set up negacolor film properties tab and then copy to the image above as a starting point, and corresponding xmp:
IMG_7286.cr2 (11.8 MB)
IMG_7286.cr2.xmp (8.7 KB)
EDIT: Anyway, the color pickers are a great add on, thanks!
These images are licenced by CC-NC
There is something deeply messed up with this negative. The foreground seems harshly underexposed, then you have 2 WB plus light leaks or developer stains on the sides. I had to use the color balance to take care of the 2 WB. Also, I have no clue what the camera scanning light WB was, but you should fix it first.
IMG_7291.cr2.xmp (18,3 Ko)This photo would be great for a playraw
I think it’s possible to rescue it with a lot of curves
IMG_7291.pfi (49.7 KB)
I just pushed a change that adds 5 more color pickers (Dmax, inversion offset, density, exposure and a second WB), and added a second white balance term (for shadows) intended to correct color casts in addition of illuminants.
If using the auto-tuners/color pickers to speed-up your edits, please use them in the UI order (from left tab to right tab, from top to bottom inside the tabs).
I will check the maths in the auto settings of the color pickers tomorrow, I’m pretty sure I messed up at least one of them.
Nice job, @age and @anon41087856!
If you think so, let’s go then.
The OpenCL kernel is available. Also I have fixed a big mistake in my optimized log10 function (expect your edits to not produce the same result).
Thank you.
I’ll do my best to do some more tests, but I’m very short of time now due to personal problems, so I probably won’t be available for the next days.
Module finished and ready for testing:
Exzellent video, as usual 
.
@anon41087856, thanks for the video and the work on the module.
Here’s one more raw, this time, a breeze to edit.
I used in-camera custom WB, so, since there are no clues in the image from the illuminant, here are the settings:
EDIT: The film is a Kodak Gold 100-2
As a friend is going to lend me a nikon ES2 film adapter, I am exercising on negative inversion.
I am doing trials with ART and I could not stop to post my @gadolf photo processing.
I modified the WB to avoid what I see as a purple cast.
You mean the right side of the image? You’re right.
I have to review my capturing setup. I suspect it has to do with lens vignetting, but it could also be some kind of light leak, since I had a well lit window at right. Maybe I have to do the shooting at night.
For the moment, I have no real experience, but as my friend told me, even with an adapter as identified above, lighting is critical ( uniform lihgting, CRI…).
I think you have to avoid dual illuminant situation. That could explain the difficulty to balance colors.
Ok, I tried this and it worked nicely (thanks!)
Then I went back to the regular git version of darktable, but it won’t start. I get:
[defaults] found a 64-bit system with 32822120 kb ram and 6 cores (0 atom based)
[defaults] setting very high quality defaults
[dt_ioppr_check_so_iop_order] missing iop_order for module negadoctor
[dt_ioppr_check_so_iop_order] missing iop_order for module doctor
And that’s it. I did remove my .config/darktable directory, but to no avail.
