Hi,
thanks for interesting contribution.
I tried inversing some scanned negatives and… the tool is not visible when TIFF files are opened. I can invert only raw files. Is there a chance someone could enable it for non-raw files in near future as I am preparing to print some old scans and I am eager to test new approach?
Hi @cuniek ,
yes, this feature was intended only for raw files, because raw values from the sensor are just a proportion to the amount of light, which simplifies things a lot.
When dealing with non-raw files, i guess i should translate from the source color profile to linear before applying the formula, and i don’t know how to do it reliably, for all possible devices/firmwares and color profiles.
Can you get 16-bit linear TIFFs from your scanner? If so, please can you try using the G’MIC pipeline from this post above? Assuming you save the pipeline to a file called filmneg.gmic, this would be the command line to use it:
gmic your_neg_scan.tiff -m filmneg.gmic -film_neg -output result.png
That pipeline applies the same formula used inside the RT feature, so we can get an idea if it can work or not. If there’s some hope, i can try implementing it in RT, but i don’t promise anything 
In the meantime, you can already use the G’MIC pipeline as a working solution, by pre-processing the negatives with it, and then fine-tuning the (positive) result with RT as usual 
Sorry for REALLY late reply, but I was very busy.
I failed to try your procedure on my scanned negatives - there is “syntax error in expression -fill…” Red few tutorials and could not find any obvious error in Your script or on my side.
I have tested film negative on one of my OLD negatives I am renovating now. They are old and dirty, so not really a good point of reference, but results are great. Previously I had to work much harder to get something similar - thumbs up.
I think I found a bug, or maybe I just overdo film negative? Big, colorfull halos around high contrast edges when “contrast” is increased. Is it a known limitation? Should I report that?
Whoa, how did I not notice this gem before?
I right now have three semi-independent “workflow backlogs” I’m trying to churn through. Digitizing my old negatives from 20 years ago is part of that. I’m definitely interested in improvements to the workflow and hope to take a look at your approach over the weekend.
An observation I have on the darktable workflow (or, why I shelved this project a year ago to revisit later):
It sounds like you’ve addressed item 1 but possibly there might still be some considerations for item 2 if the capture setup has any vignetting?
I’m going to take @rom9’s RT pull request and test it tonight or tomorrow. I’m really excited by this.
It’s already in RT dev
Even better!
Edit: So far, a completely different workflow will take some getting used to. I’m fairly easily able to get better results from the negatives I’ve digitized so far than I ever was able to get with dt’s invert module + whitebalance-after-invert (doing WB-before-invert took a little getting used to…)
I think I’ll be good once I figure out rotations more than +/-45 degrees… Time to RTFM. 
Edit 2: Works great on some of my negatives, but on a few others, no matter what I do there’s a green color cast due to the “black” level of the image being way off no matter what I pick in the black-after-inversion areas.
1: weird, i’ve just tried the same gmic code copied from the post, run this exact command line:
$ gmic DSC06072.JPG -m ~/Pictures/filmneg.gmic -film_neg
… and it works for me. I’m uging G’MIC version 2.5.7 on Linux.
Is the error message complaining about the first -fill (line 3), or the second one (line 9) ?
2: glad to hear that, thanks!
3: you mean artifacts like this?
Thanks a lot for all the help - I got it now. It was not the path, It was my mistake while copying filmneg.gmic content. I just skipped “film_neg:” at the very beginning. I thought it was a title, not a command. Sorry. My bad.
I will test this approach on some problematic negatives and write my report.
Hello Entropy512, and thanks 
Applying inversion after vignetting correction, would also mean applying it after exposure and WB, so those RT control sliders/curves would be reversed ( which we don’t like 
).
Anyway, since you have to use a macro lens, and stop it down to at least f8 - f11 to capture the negative, i don’t think there will be much vignetting from the lens. You are more likely to be affected by the backlight not being perfectly even.
To fix that, your only hope is using flat-field correction (which will take care of lens vignetting and backlight unevenness all in one go). The good news is that the filmnegative tool does happen after flatfield, so you can use it, and it works. The bad news is that if you slightly move anything in your setup, you’ll have to re-capture the flatfield.
Regarding distortion, it should also work post-inversion… i’m tring to use it on one of my pictures and i don’t see any issues. But, again, since we’re using a macro lens, is distortion correction really needed? I’m using a cheap Vivitar from the 80’s and can’t notice any distortion.
This could indicate incorrect exponents, maybe there are no good, neutral spots in the image for the dual-spot feature to work correctly. Try to play a bit with the “Red ratio” slider. Since you see a green cast on your shadows, i think you should lower the red ratio. Please note that you might also have to re-do white balance after adjusting the exponents.
If you can post or PM me the problematic raw file, i’ll try working with it.
Some of this may be some oddities that were in dt’s workflow - I’m not noticing obvious vignetting challenges when revisiting last year’s captures.
I used a Rokinon 100/2.8 at f/8 and only saw what appeared to be vignetting artifacts when fine-tuning the film color in dt’s approach. It seems like your approach may be far more robust in these scenarios based on my experience.
I was primarily concerned with vignetting not distortion - I really haven’t seen any distortion from my Rokinon.
Yup, eventually found it. One of those things that is very different from dt and takes a little getting used to. Thanks!
I’ll try and get you the file later today.
One question I have - Should the chosen film color area be winding up close to black after the points are selected? I’m seeing it consistently winding up well up into the greys (with only the film sprocket holes actually black), requiring further adjustment to bring them down. On my problematic image, the film has a remaining yellowish color cast (was green previously, now I’m seeing yellow) as opposed to just being grey.
Side note: The white balance picker allows selecting a radius for the picker, might this be beneficial for this tool also? Looks like you’re defaulting to 32, might happen to be too big for the white hat I used as reference - although the snow also misbehaves.
Could your median calculation code be getting thrown off by the fact that I included the sprocket holes and this happens to be at the end of a strip? (In the long term I hope to get less of the “extra” crud, but I found having extra unexposed region had been beneficial in dt’s inversion workflow.)
Edit: Revisiting the white balance tool a second time fixed the issue. The original order of operations was not entirely obvious to me… On many of my images, it seemed like you had to use the white balance tool on unexposed film initially before enabling the negative module to get good results, but I think it was just sheer luck that worked on some of my images. A completely new workflow will take some getting used to, but I’m liking RT so far.
No, it can be well above black, that’s normal, it’s a safety margin. You can bring that area closer to black, by raising the “Reference Exponent” (which increases contrast), but then you would risk clipping some highlights. The negative tool does just a rough estimation in order to keep the channel values inside a usable range, but the actual fine tuning must be done with the usual Exposure/Black/Tone curve controls, which are much much better at that task
Looking at the image, it seems that the yellow cast is constant across the entire range, so the exponents should be ok, the image should just need white balance.
Try doing spot-WB on and unexposed area of the film, and it should be fixed.
I think going below 32 is not recommended. At 24MP if you zoom in at 100%, you will easily see film grain in your picture. Each single grain has its own color, so we need enough values to average out all that noise. Maybe i should allow selecting sizes above 32, though…
Anyway, looking at the picture, it seems that the white hat should have a clear area of at least 32x32… the square pointer marks the exact area use for the average, and is adjusted with zoom level, so you can zoom in with the scroll wheel, precisely pick the white area, then zoom out / pan, pick the black area, and you’re done.
Also, snow shoud work perfectly as white spot… i think your exponents are ok as they are, and your image just needs WB (see above)
Yes, definitely! Sprocket holes, and the empty area after end-of-strip are introducing lots of outliers in the median calculation, so that the result is not correctly “centered” on the histogram of the interesting content. Anyway, it’s not the end of the world; that median shift will be automatically corrected by applying WB and adjusting Exposure
Yep, confirmed: since the film negative processing happens on the raw values, white balance should be done afterwards, with the film negative tool already enabled. This is also easier because you immediately see what you get
Yup. When I first started playing around, it seemed odd that I had to adjust white balance first - I think it was just pure luck that it worked at all. It seems like on my build, the WB tool defaulted to being completely turned off off initially. Perhaps that’s an RT-ism that is why you should manually ensure you’ve applied the neutral profile first before starting to work with the film negative function.
This is what happens when you’re excited about a somewhat advanced module but are at the very start of the learning curve for the tool it’s in. Ooops.
I’m going to have to pull out my negative capture setup again later this week and get started on going through everything now that you’ve solved my processing headaches.
OK, here is the promised assesment:
My current workflow is (after scanning the negative without any corrections done by scanning software) - invert using tone curve, adjust exposure, click white balance (then use RGB curves to fine tune the colors - I skipped this step in this comparison). The steps are shown from left to right.
With filmneg gmic procedure (that I did not change, so the values are for Kodak ColorPlus 200 and not Konica Centuria 200), similar steps give results as follows
Results are not perfect (remember that settings were for different film), but overall we are way closer to final image than before with less work and confusion with some tools working “the wrong way”. I guess that black/white spot tool would make the image even better and streamline the workflow.
Conclusion - It would be great to have film negative working for all file types.
I just compiled this through through AUR on manjaro (rawtherapee-git-7827.061bf713c-1) I’m very interested in this feature and it looks really good, But for whatever reason the Film Negative is bypassed when processing, it’s all good in the preview but exported files are still negative, is it just a fluke in the current build or am I missing something?
Export works fine here
Hi,
this is very weird. I’ve compiled the latest upstream dev, tried exporting in all JPG, PNG, and TIFF formats, but it works for me too.
If you try closing RawTherapee and re-opening the same file, do you see the film negative tool stays enabled or not?
Which type of raw file are you processing?
If you open the .pp3 file with a text editor, do you see the [Film Negative] section at the end, with Enabled=true ? Or, even better, can you post the .pp3 file ?
I see… well, that would be a major rework. I can try looking into implementing this, but first i have to do some experimentation and learning, because i know absolutely nothing about color profile conversions, gamma correction and all that stuff embedded in non-raw files. Dealing with a straight readout from a photodiode is much simpler.
I’ll take a look, but i can’t promise anything 
In the meantime, i’ve made some tests with different film types, i’ll post some examples (and related parameters) in the next few days.
If You ever need - I have few ends of filmstrips (with clear and totally burned out areas) scanned. Yes, they are not raw files but 48bit tiff files with color profile built in. Yes - some of them are 50 years old.
Film Negative is true, It’s really strange, thumbnails are ok everything is as it should after restarting, Only exports are still negative o_O I have an fuji X-t3 could that have something to do with it? I tried starting from (neutral) preset but it’s still the same :o I also tested all demosaic methods, no difference…
DSCF6211.jpg.out.pp3 (11.1 KB)
Please provide the raw file too
