I’m using Digikam’s import feature from Panasonic (RW2) cameras and I’ve been using the conversion to DNG with the “Embed Original File” enabled (it should also be possible to do with with the batch queue converter too). I deleted the original RW2s from the SD cards when doing so.
An issue with the newer cameras means that I’d like to get the RW2 back, but it’s not as simple as using exiftool -OriginalRawFileData; the DNG specification says that this is zip-compressed big-endian 64k chunks.
How do I do the reverse and get the original file back? Or, how does digikam do the compression during the import process so I can reverse engineer that?
Does using that exiftool command do nothing, or does it give you a large binary blob?
If a large binary block, what happens if you unzip it? I don’t have the spec open at the moment and family arrive soon, did they literally say “zip”, or just one of the base algorithms used in zip files? (e.g. does it have a ZIP file header or not?)
Dng converter has a function extract embedded raw so I’m pretty sure this is the reverse of embedding it unless digikam did something off course with the file .
Does using that exiftool command do nothing, or does it give you a large binary blob?
Large binary blob, but it’s not recognised as a zip file header. The spec says “ZIP compressed data”, which I guess means DEFLATE?
unzip P1037959.blob.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive.
...
$ xxd P1037959.blob.zip | head -1
00000000: 01a1 e400 0000 0690 0000 6dda 0001 6b26 ..........m...k&
I’m re-reading the spec and it’s starting to make a little bit more sense to me. I’ll try to whip up some python code to extract it…
Well, it’s not zip file… When storing a data blob, there’s no reason to add the directory found in a zip file, the “owning” program knows what the blob is (and that it only contains one “item”)…
You can perhaps verify the compression scheme used by digikam in its source code. It looks as if they use the DNG SDK from Adobe.
Ah yes, the digikam source code has been pretty useful. I was able to write a python script which can decompress the first block and get the magic sequence in the original header.
The adobe dng converter is free so at least you can use it if you need to but it seems you want to code something… I think it can be run on Linux if need be via vm or emulation…
