I think it’s now time to install rawproc. 
No need, I already started the discussion over there…
Or you can try the latest libcamera-still from main that doesn’t create these bogus files.
3 Likes
Yeah, the DNG needs to be fixed, first.
rawproc by itself didn’t do it all, I had to manually extract and mung the primaries for ingestion.
The ColorMatrix1 tag looks fine in principle, you might want to lift the “10000 denominator” restriction in your implementation (i.e. read both numerator and denominator and do the actual division):
ColorMatrix1 10533639/8388608 -2310377/4194304 -5071987/33554432 -1063505/2097152 5631805/4194304 8584029/67108864 -2605039/33554432 4462193/67108864 4932553/8388608
IMHO, libraw should have no problem with those. If it does, it should be reported upstream…
Once I removed that 4 byte IFD1 pointer in the hex editor, the image loads fine in dt:
Again, new DNGs from the latest tool should not have this problem and should load OOTB.
I just build libcamera-apps from git and now it works with dt: 
test3.dng (31.2 MB)
But sadly I fear ArduCam provides patched libcamera-apps because now I lost the autofocus option. I opened a discussion in the support forum:
1 Like
Oh, exiftool did it for me, a nice set of floats.
I converted them to integers *10000 because that’s the dcraw format, and I had incorporated that ingest into rawproc, paste a comma-separated dcraw set instead of a color profile filename…
I understood that part (and that’s an Adobe “format” btw as DNGs from Adobe DNG Converter were the only source of profiles for dcraw and its derivatives historically…), but still doesn’t explain why it doesn’t work OOTB for your app, i.e. why libraw doesn’t provide you with the same set of floats as exiftool/exiv2?
Yeah, no kidding. I don’t want to hijack the thread, but this has given me pause to review what I’m pulling from the libraw-delivered data for color information. For this DNG, libraw delivers a RGB->camera matrix, but does not deliver a camera->XYZ which I think is what the metadata’s ColorMatrix1 is supposed to be.
Ah, but it does (or at least it should), check rawdata.color.cam_xyz[][]
For the DNGs posted in this thread, from cam_xyz I get zeros…
Some time ago, I incorporated libraw’s cam_xyz in my search for camera primaries, a last-resort after parsing dcraw’s adobe_coeff and RT’s camconst.json.
No idea, sounded like it should work:
Btw, did you check both color.cam_xyz[][] and rawdata.color.cam_xyz[][]?
Anyhow, different topic I guess…
Well, maybe not quite. The dng from this thread has what appears to be a valid ColorMatrix1, and libraw doesn’t process it. There’s a bit of conditional logic in the code you posted, and I’m running out of time this morning to work through it, but I’d surmise there’s something else missing from the RPi dng to compel libraw to use the ColorMatrix1…
Perhaps, sadly I won’t have time to build libraw in debug and step through it either any time soon…
No, the doc says “All other fields of this structure are for internal use and should not be touched by user code.” for rawdata, and my military time taught me to follow instructions… 
Peeking is not touching 
Okay, okay, put in a collection for rawdata.color.cam_xyz[][] , no joy from test3.dng…
I got the patches from ArduCam, forked libcamera-app and merged them with latest version:
This is the first test image (not very interesting content 
) from this version and it opens in dt:
test4.dng (31.2 MB)
And here the first test image from the second camera module without the IR filter. (Sadly without auto focus.)
NoIR-test.dng (31.2 MB)
NoIR-test.dng.pp3 (11.5 KB) (Just a little white balance done in RawTherapee directly on the Raspberry Pi)
3 Likes