Darktable: Can't decode Nikon Z6/Z7 uncompressed raw file

[paperdigits]

Describe the bug
Darktable is lacking support in rawspeed for using uncompressed raw files from the Nikon Z6.

To Reproduce
Steps to reproduce the behavior:

1. Open Darktable
2. Import a Nikon Z6 uncompressed raw file
3. Get the "unable to read white balance" error.

Expected behavior
Open the uncompressed raw file correctly.

Screenshots
If applicable, add screenshots to help explain your problem.

Platform (please complete the following information):

• OS: all
• Version 2.6.0

Additional context
See here for more details.

[LebedevRI]

Thanks.
I have a fix for decoding (ended up being idiotically simple, it was supposed to just work already),
but i'm now not sure yet how to detect this situation.

[heckflosse]

i'm now not sure yet how to detect this situation

Z7
Z6

[LebedevRI]

Duh, come on :) No, that is too obvious even to me,
i'm looking for something more elaborate, with less hardcoding.

[LebedevRI]

Duh, come on :) No, that is too obvious even to me,
i'm looking for something more elaborate, with less hardcoding.

To put some context into

but i'm now not sure yet how to detect this situation.

You'd think that any compressed raw would have smaller file size than uncompressed raw.
Would make a lot of sense, wouldn't it, why else waste all that time compressing
But no, this is nikon. (i'd guess mostly because they hardcoded the 6 huffman tables to be used?)

Even just out of all the RPU samples (yay test coverage), this is not true in 5 (sic) cases:
(expected input size is the byte size that image would take as uncompressed packed)

• ./Nikon/Coolpix P330/DSCN0138.NRW
area 12192768 bpp 12 input size 24385536 expected input size 18289152
• ./Nikon/Coolpix P7800/DSCN2039.NRW
area 12192768 bpp 12 input size 24385536 expected input size 18289152
• ./Nikon/D100/RAW_NIKON_D100.NEF
area 6140816 bpp 12 input size 9844736 expected input size 9211224
• ./Nikon/D4S/FU9_3802.NEF
area 4040960 bpp 12 input size 12122880 expected input size 6061440
• ./Nikon/D810/DSC_1888.NEF
area 9038080 bpp 12 input size 27114240 expected input size 13557120

Using some heuristics over the STRIPBYTECOUNTS is so fragile here :/
Even just the current equality-comparison _could_ fail i guess.

Yet, i'm presently not seeing any obvious formula between the image dimensions,
expected/actual buffer sizes and the padding for the Z {6,7} uncompressed raws in question.
And there does not _seem_ to be some _other_ this image is really uncompressed EXIF tag.
(It also is just great that they continue to lie in the Compression EXIF tag :)

Or well, i see the correlation, but i can't really formulate it - count trailing zeros(actual input pitch) > count trailing zeros(expected input pitch).

So yeah, just 'accepting' some small per-row padding (16 bytes?) might be the path of least resistance :/

[heckflosse]

Well, If my hint got you closer to the solution, that would already be a progress ;-)
I'm not saying the solution in Rawtherapee is perfect (it's far away from that)

[LebedevRI]

Ok, done. https://github.com/darktable-org/rawspeed/commit/84eabd77e8d134fab1669f73382e44b4805e5e7e
Will propagate to darktable sometime later.

[LebedevRI]

(Have i already said that having more than one issue tracker is idiotic?)
Forgot to close this, fixed in https://github.com/darktable-org/darktable/commit/4645a8b725eca6dee71ae5b549c61cea65148c42