I was pointed to the fact that dnglab might be able to turn compressed dng files into uncompressed, darktable compatible dng files. Simply running “convert” on them actually works and creates absurdly large DNG files which I can open in darktable. But the images have a strong magenta shift and are very low in contrast. I have a feeling the options of the makedng subcommand might help to fix this. Anyone got an idea how to fiddle this in the right direction?
FWIW, the “traditional” lossless JPEG compressed DNGs should (mostly) work in dt, and dnglab can output those as well (expect 70-50% of uncompressed size).
The conversion side effects might be due to black or white levels not crossing over correctly, or CFA pattern not crossing over correctly (or active area being changed so the pattern shifts), or some actual decoding mishap… You might want to check and compare e.g. exiftool -a -u -s -G1 output before and after conversion…
Thanks, exiftool -a -u -s -G1 produces some EXIF Data and a lot of gibberish. A lot of the data from the original DNG is missing so something is afoot. Through trial and error I didn’t get any further with dnglab dngmake. It may be a bit of a long shot but @cytrinox do you have an idea how to get the “reverse conversion” of jxl-compressed dng to dng right?
The color shift happens because Adobe-software transforms raw data prior to jpeg-xl compression to gain more compression ratio. These transformations must be reversed after decompression, which is instructed by DNG opcodes (OpcodeList2).
You can verify that by looking at exiftool output:
Opcode List 2 : MapPolynomial, MapPolynomial, MapPolynomial
These opcodes must be applied to get correct color+contrast.
Such codes are copied from source to outut dng by dnglab, but afaik this opcode is not yet implemented by darktable/rawspeed.
I’ve an experimental branch with some implemented opcodes and a dnglab switch to preprocess opcodes before writing the file, but it’s not yet public available.
Interesting (and unfortunate?)…
RawSpeed seems to implement it, but only for lossy compression (and only for “34892: Lossy JPEG” so far). Don’t know why that restriction on OpcodeList2 is there (nothing about it in the spec), someone could try relaxing it and report back.
Opcode processing for only 34892 compression mode makes no sense.
IIRC Adobe software combines sometimes MapPolynomial and GainMap for JPEG-XL compression, I think I’ve seen these together when testing JPEG-XL compression.
