$25 for a 16 MP autofocus module?!? This is astonishing.
I hope they will bring a version without IR filter, that could be really useful for my planned next project.
@tobias I believe that somebody has; search for raspberry noIR.
Claes in Lund, Sweden
He’s probably looking for a NoIR variant of this particular product.
I have mixed feelings about this one… I would much rather see a compact 12+ MP wide-angle module that could be used to assemble a 360 camera that outperforms the xphase.
Binned that’s 16MP.
Definitely an interesting thing to look into, but it continues to highlight the fact that the Pi’s 2-lane CSI interface (unless you get a CM4 with custom carrier board) is starting to become a pretty nasty limiting factor in terms of readout rates.
I bought the 16 MP autofocus module and the 16 MP IR module and they arrived last week. Yesterday I even got my RaspberryPi and I assembled everything. Sadly the IR module has no autofocus.
As I’m a completely newbie in the RaspberryPi camera world I would welcome any good hints and links. Especially because Raspberry switched from there old camera stack to libcamera and a lot of tutorials I fond no longer work.
Here are the first images of the 16 MP autofocus module:
JPEG created with
libcamera-jpeg --autofocus -f --keypress -o test.jpeg:
DNG created with
libcamera-still -r -o test.jpg
test.dng (31.2 MB)
(This file doesn’t work with darktable.)
RAW file created with
libcamera-raw --autofocus -f --keypress -o test.raw
Thanks for sharing. There are multiple issues w/ this DNG, please report upstream (RPi and/or libcamera). Rawspeed throws an “Two IFD’s overlap. Raw corrupt!” exception:
test.txt (3.0 KB)
- Entirely superfluous IFD1 (the cause of this exception, overlaps w/ ExifIFD)
StripByteCountstags in the ExifIFD (already recorded by IFD0 and SubIFD as mandated by TIFF/EP, i.e. DNG, which overlaps w/ Exif)
Actually, the extra IFD1 issue seems to be handled already: Dng fixes by davidplowman · Pull Request #285 · raspberrypi/libcamera-apps · GitHub
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:
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.
Do we dare to tell @Tobias that the image is upsidedown?
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: