Can't decode Nikon Z6/Z7 uncompressed raw file about darktable HOT 7 CLOSED

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.

from darktable.

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

Z7
Z6

from darktable.

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

from darktable.

Ok, done. darktable-org/rawspeed@84eabd7
Will propagate to darktable sometime later.

from darktable.

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 :/

from darktable.

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)

from darktable.

(Have i already said that having more than one issue tracker is idiotic?)
Forgot to close this, fixed in 4645a8b

from darktable.