Hi,
unfortunately Darktable gives me an error and doesn’t seems to load few dng files.
It’s strange becouse the file before and after are working.
This is a dng that gives me errors: https://www.transferxl.com/download/08NRjydcpyKtH
I tried to load it in Osx and Ubuntu versions 5.2.1 of Darktable and it doesn’t work.
The other shots from the same day are perfectly working.
I have to add that I can’t register to this forum with my gmail address, don’t know why.
Thanks for the help.
Hey and welcome. Where is the dng from? Currently dt does not support dng 1.7, which is latest iPhone and Samsung dngs.
It’s from a Leica M240… a camera from around 2014. 99% of the files from that camera are working in Darktable. I have only a few of them that have this problem.
Ah, known problem w/ old Leicas corrupting an occasional file when writing to card: Leica M 240 (compressed DNG) - File has unknown format · Issue #15123 · darktable-org/darktable · GitHub
But strange that only darktable has problem with them. They are working in every other app.
It’s not strange - as explained in the linked issues, darkrtable has a very strict raw file parser.
Maybe you could open and resave the file as another DNG using Adobe DNG convertor or similar.
yes, converting it with the DNG converter works. I still am curious about why this happens.
When running darktable in debug mode
$ darktable -d camsupport
4,1755 [rawspeed] L1006401.DNG corrupt: void rawspeed::AbstractDngDecompressor::decompress() const, line 249: Too many errors encountered. Giving up. First Error:
rawspeed::Buffer rawspeed::Buffer::getSubView(size_type, size_type) const, line 80: Buffer overflow: image file may be truncated
4,1779 [rgbe_open] RGBE bad file format: no FORMAT specifier found or it’s not 32-bit_rle_rgbe
Not a JPEG file: starts with 0x4d 0x4d
I don’t understand that error. 4D 4D 00 2A is Big-endian TIFF.
@Peter All is explained in the link above and associated issue.
P.S. Ignore the rgbe_open line and the one below - rawspeed already failed and other loaders are attempted as fallbacks… They will of course fail as well for other reasons.
The firmware you used was 2.0.3.0.
Take a look here Leica M10 support (0.3% of my images can't be loaded) · Issue #11695 · darktable-org/darktable · GitHub
I changed StripByteCounts from 25356355 to 25704311 and the file works in darktable.
exiftool -htmlDump test.DNG > hex.html
In a Hex editor, open the file and search for EOI, End Of File, FF D9
Check the offset. Here it is 0x1886F33. In decimal it is 25718579.
25718579-StripOffsets = 25718579-14270 = 25704311
Real StripByteCounts should be 25704311.
Check the hex dump from Exiftool and in the hex editor navigate to the offset 0x02C6.
To the right we see 01 82 E8 43. In decimal that is 25356355 which we want to change to 25704311.
25704311 = 01 88 37 77
There must be a more simple way to change StripByteCounts…
test.DNG (24.6 MB)
Looks like this should work:
why is it so fussy about it? Every other photo app reads those files with no problems.
It’s already mentioned in the linked issues: it’s strict about compliance and security. Non-compliant files could carry malicious payload and if you keep reading beyond what the file told you the end was your machine could end up being compromised. It’s a feature, not a bug.
Doesn’t mean it’s the right thing to do.
Well, you still have to open the file in the hex editor to look for the EOI signature offset and recalculate the the count value. So might as well change it while in the editor. (The actual writing could be done even w/ a simple dd.) A custom tool would be needed to do all the steps automatically. If you ask me, it’s Leica who should be provide it. 
Isn’t this something similar? Phil Harvey created this for Nikon users when Nikon corrupted the owners’ raw files. Fix Corrupted Nikon NEF Images
Thinking of the part about StripByteCounts.
