I opened test.dng in rawproc, libraw handled it okay except for finding camera primaries, probably attributable to the IFD issue. Exiftool did find a D65 ColorMatrix1, so I converted those floats to int * 10000:
12557,-5508,-1511,-5071,13427,1279,-776,664,5880
Pasted those numbers into the colorspace:assign tool and processed the image like this:
As I can only guess what you are talking about, I would like to ask you what to write into the issue.
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.
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:
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…
