4 Channel DNG/TIFF/RAW (RGBI) Imported Images not being handled correctly in Darktable/Lightroom

[stevecs]

Describe the bug

I have thousands of scanned images (slides/negatives/positives) captured with VueScan in (64/16bit) RGBI DNG format on a network share. (Images scanned with Nikon LS-9000 and Epson Perfection V850). I have historically been using Adobe Bridge to manage photos and wanted to see about converting over to Darktable/Lighttable). When importing a copy of the directory (as a test to avoid any bugs with image modification) lighttable imports the files, but all show up with a missing image placeholder.

During import I get a flash of 'image xxxxxxx.dng is not available' which is the filename of the actual image file. The same file can be read natively and can be imported/seen in bridge without an issue.

After the import process the exif data on the file does exist (can see the metadata, path, filename, size, etc) but just no thumbnail and when I go to the darkroom tab it says 'could not load xxxxxx.dng switching to lighttable now'.

But can go into photoshop from bridge and works fine there.

If I use individual JPEG images this works as expected. Can Darktable not handle 64bit/16bit RGBI TIFF/DNG files or RAW (gamma 1.0) DNG files?

Steps to reproduce

Import
Add to library. (any directory),
select files to import.

Expected behavior

should generate or display thumbnails of images in lighttable and allow processing with darkroom

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you install darktable from?

darktable.org

darktable version

4.4.2

What OS are you using?

Windows

What is the version of your OS?

Windows Server 2022 (21H2)

Describe your system?

Supermicro X10DAX
Dual E5-2667V4
256GB ECC Ram
Windows server 2022 (21h2)
Nvidia GTX 3080TI

Are you using OpenCL GPU in darktable?

None

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

[wpferguson]

Could you supply an image that we could test with?

[stevecs]

uploaded a sample here, it's 7zipped to save some space and to allow checking for transmission errors.
https://gofile.io/d/35izkZ

This is one scanned with a nikon coolscan LS-9000 w/ vuescan software.

[jenshannoschwalm]

rawspeed does currently not support such images

@LebedevRI a quick test, in UncompressedDecompressor.cpp we have in line 118

  if (cpp < 1 || cpp > 3)
    ThrowRDE("Unsupported number of components per pixel: %u", cpp);

changging to if (cpp < 1 || cpp > 4) seems to be fine - not understanding the rawspeed code though :-)

[LebedevRI]

uploaded a sample here, it's 7zipped to save some space and to allow checking for transmission errors. https://gofile.io/d/35izkZ

This is one scanned with a nikon coolscan LS-9000 w/ vuescan software.

Can you please contribute such a sample to RPU?
But please upload something with a small file size, 1MPix should be plenty here.

[stevecs]

So you want me to contribute the photo to RPU? I can do that. (doing that now as I type this). I don't have any 'small' captures (actually that was probably the smallest as most of the scans I have are for 4x6; 6x6 and larger negatives/slides so they're up towards 1GB each. That's only a 35mm one so it's rather small at 190MB. I've used other scanners over time (Nikon Coolscan LS-4000, and LS-2000) for example but those are showing the same issue but since it's always using VueScan they should all be the same. (i.e. it's the vuescan software that is writing the RGBI not the scanner).

[LebedevRI]

Once again, can you not specify the target size in the software?
181MiB is a bit too much for this.

[ralfbrown]

Or scan at a lower resolution.

[jenshannoschwalm]

And please update the issue title, this issue is very specific. It's about 4channel dng files with the forth channel being infrared.

[stevecs]

I don't have the nikon LS9000 attached at the moment, but have the following (same issue) scanned from the Epson PerfectionV850 scanner.

https://gofile.io/d/5GYJZG

also uploaded to RPU. Much smaller scan and using a different scanner (but same capture software) to aid in fixing issue and hopefully showing it to be scanner agnostic (i.e. related to VueScan RGBI/4channel opposed to a particular scanner model).

[LebedevRI]

Unfortunately, that image contains people, so it's not well-suited for RPU...
Do you perhaps have another similar problematic sample? The filesize is nice!

[stevecs]

that's my family member, I will see about another (working through a current batch but they are all portraits). I guess I am confused as to the purpose of RPU here, I mean the image itself should be irrelevant is it not? The point really is the 4 channel nature of the TIFF/DNG capture and handling that within Darktable.