Help with OpticFilm 8200i + VueScan + Black&White Processing

[TottiT]

Hello dear Community!

First time poster here, and pretty newbie in general.

I’ve been a Darktable user for a couple of years now after making the switch from Lightroom and generally I’m convinced with it’s capabilities as a raw image processor and would be into continuing using it in the future. I have a one bigger issue with Darktable in general that I hoped some of you wise folk in the interwebs could help me out with. Let me explain further:

I’m shooting traditional black and white film and with a help of a friend we develop and scan the negatives to .DNG’s using Plustek OpticFilm 8200i scanner and VueScan as the software. My friend is the magician here, and he knows all the details about those two spesific tools.
The end result after this process is a .DNG that loads up beautifully in Lightroom!

And here come’s the problem:

When I load up these .DNG’s to Darktable, the default rendering for these images is a tilted-to-pink B&W image, that looks not at all like it should. Also, all the images load up with a message:
‘Plustek Opticfilm 8200i’ color matrix not found!

With the previous film rolls of mine I’ve manually adjusted loads of parameters from Darktable, with an exported JPEG from my friends Lightroom as a reference, and after numerous tweaks I’ve been able to somewhat make the image look as it should.

I don’t like this process at all though, and I feel I’m always loosing something on the process, instead of getting a 1:1 rendering of the image.

My question would be:
Is there a right way™ for Darktable to read these DNG’s of mine as they should be read without having have to adjust a million parameters? Do I have to export/import a color profile of some sort from the scanner? Can I download one from the internet? etc.

If you need any more information about the scanner and or the software I can consult my friend and let you know!
Also, if any other pieces of information is needed, I’m happy to help!

I’ll attach an example screenshot and the corresponding image file as a reference.

[TottiT]

Here’s a screenshot of how an image would look like in Darktable.

[TottiT]

And here’s the .DNG in question.
https://www.dropbox.com/s/dvlvypbdfso514p/2019-10-04-0011.dng?dl=1

[paperdigits (Mica)]

@TottiT

And here’s the .DNG in question

Where?

Can you upload a sample to https://raw.pixls.us?

[TottiT]

Hey @paperdigits!
Sorry, I was having trouble with uploading the photo here and Dropbox.
I had to actually get another computer to succesfully upload the file.
It’s there now!

Also, I’ll upload it to raw.pixls.us as requested!

[chris]

My advice would be not to scan to dng in VueScan but to tiff. The VueScan dng has several drawbacks over tiff (I would have to do the research again to find them again, if you have to know). You can use the tiff format as well to save the raw data including the infrared channel and this never caused issues for me in darktable. However, the invert module seems to have problems with camera’s raw files, so maybe with scanner generated dngs as well.

[TottiT]

Hey @chris!

OK, good to know for the future!
But would this have any effect on the actual key topic though, which is the apparently missing ‘color matrix’? Correct me if I’m wrong, but wouldn’t we still face the same issue of not being able to render the images due to the aforementioned issue? Or does the tiff format somehow bypass this with some cleverness?
Anyways, I would also love to find a workflow that doesn’t require re-scanning all the previously scanned negatives.

[TottiT]

I uploaded the sample image to raw.pixls.us as well and also opened a ‘camera support’ bug tracker in GitHub as well. Eager to get this cleared :).

[gadolf (Gustavo Adolfo)]

I’ve just loaded it with darktable 2.7.

EDIT: Welcome!

[TottiT]

Holy cow it’s true!!
Just installed a dev build for Windows that someone was kind enough to provide to also see it in action with my system!

Oh yes, this makes me so happy! Thanks a lot for the tip @gadolf!
Now let’s just hope using a dev-build doesn’t bring up other weirdness with it .

[gadolf (Gustavo Adolfo)]

@TottiT

Now let’s just hope using a dev-build doesn’t bring up other weirdness with it .

In general, DT dev releases are pretty stable.

Just be aware that once you edit an image with it you can’t downgrade. This is important.

EDIT: Let me stress it this way: in terms of user experience, the dev release is fine. But if you work with photography or have lots of images already edited in 2.6 and you start tweaking them with 2.7, then you can’t go back to 2.6 stable, and you’ll loose your original 2.6 edits.
EDIT 2: … unless you first backup all the edits (there are lots of posts in the forum telling how to do it). In my case, I didn’t do that because I don’t have tons of edited images and I’m just a hobyst.

[TottiT]

Thanks for the heads-up.

So if I understood correctly:
The newer builds are able to import all the edits from older builds, but after any edits on a newer version, backwards compatibility is lost.

I’m wondering though: if I start using a dev build from now on, and do my edits with it, in the future when the stable 2.7 is released, the sidecar-files created with 2.7-dev should be readable with 2.7 stable? Or is there a chance there’s also a possibility for incompatibility there?

And to answer your other comment - I’m also a 100% hobbyist with no interest in going “pro”, but I do try to maintain a processing environment that allows me to tweak my older stuff as well and not have to do my work twice or trice.

[gadolf (Gustavo Adolfo)]

@TottiT

The newer builds are able to import all the edits from older builds, but after any edits on a newer version, backwards compatibility is lost.

100% sure, yes.

@TottiT

if I start using a dev build from now on, and do my edits with it, in the future when the stable 2.7 is released, the sidecar-files created with 2.7-dev should be readable with 2.7 stable?

70% sure, yes, they should

@paperdigits can you help us here?

@TottiT

but I do try to maintain a processing environment that allows me to tweak my older stuff as well and not have to do my work twice or trice.

Then you’re a hobbyist on a higher level than me. One day I’ll reach you

[paperdigits (Mica)]

If you’re familiar with git, check your 2.6 edits in on one branch and your 2.7 edits in on another branch.

Or just start scanning and wait a month or two for 2.7 to become stable.

[gadolf (Gustavo Adolfo)]

@paperdigits

If you’re familiar with git, check your 2.6 edits in on one branch and your 2.7 edits in on another branch.

In other words, do a backup, right?
So there’s a possibility that a xmp file produced by a 2.7-dev release is not compatible with the 2.7 stable release (actually, this will be 2.8, right?). Is that right?

[paperdigits (Mica)]

Yes, do a backup! Not only when upgrading versions, but periodically as well!

[gadolf (Gustavo Adolfo)]

Thanks!
As for forward compatibility…?

[paperdigits (Mica)]

Development is development: things change.

Probably likely that Dev xmp files work just fine in the next stable, which is 3.0, but it isn’t a guarantee.

[TottiT]

Thanks for both of your input @paperdigits and @gadolf!
Very excited to have my original issue resolved, and this extra information concerning the versioning and compatibility is very useful indeed!