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âŚ
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)