Nice camera, bringing a few questions for the microscope.
It appears to require the Libcamera software (As stated by Pimoroni), and it is not obvious whether we can now take the lens out. Libcamera means changes to the Openflexure server that will take effort.
The pixels are bigger, and there are more pixels, so the overall sensor is almost twice as big on the specification comparison. In fact it is nearly as big as the High-Q camera - smaller diagonal, but higher aspect ratio, so the long dimension is bigger on Camera Module 3 and the short dimension is bigger on High-Q camera.
This brings bigger design questions in the optics modules, to make use of that larger sensor area might mean a longer optical train - There is a bit of a thread here. @r.w.bowman any thoughts?
Of course, one could just keep the same optical train and then only use the central part of the sensor. Camera V1, also had 1.4µm pixels and gave 5MP which is still probably more than the actual optical resolution of the system. With fewer, bigger, pixels than V2, and a newer sensor design one would hope that the noise is quite a bit better. By cropping we could also use more of the useful optical image area with a nearly square crop to 3.68mm wide (width of image circle designed for the V2 camera) by 3.63mm high (limited by the height of the V3 camera), which gives nearly 7MP. Having significantly more pixels than needed for the optical resolution would just bloat the image sizes.
I got a Raspberry Pi Camera Module 3 to play with.
It works on a new install of the Raspberry Pi OS, which needed updating to get the new camera driver.
Unsurprisingly it does not work immediately on a microscope Raspbian Openflexure, which is based on an older version of the Pi operating system and a different camera software. It is not recognised as a camera, which may be more about drivers than about how the software talks to it. That is beyond what I can do quickly.
The Camera module 3 does not come with a lens removal tool like Pi camera v2 usually does. The lens is freely floating on the autofocus mechanism. Grabbing the lens it will move in and out a bit, and twist a bit before coming to stops. Surprisingly this did not immediately break the autofocus mechanism.
I don’t actually need a camera, this is just to work out whether it is possible to use the new sensor with other lenses. So the next is a pair of big pliers. Twisting the lens has quite a bit of resistance at first, so the camera body needs to be supported. But the lens does start to unscrew! The autofocus also works, although of course the focus range becomes very reduced.
Unscrewing the lens completely reveals the sensor and the lens.
The sensor is very wide aspect ratio, as we know from the specifications. The lens is obviously different from the Camera V2, but overall pretty similar.
So what have I learnt for the Openflexure Microscope from the teardown? The board form factor is the same, and we can remove the lens. The lens is suitable to be re-used in a microscope lens spacer. So there would be a few changes to microscope parts to accept the slightly different size camera module and the different size lens in a lens spacer, but optically and physically it should all still work. It is likely that we would want to crop the image to a square-ish shape so this is would not be a 12MP camera on a microscope.
The software would however probably require much more involved revision to accommodate this camera.
One final note: After screwing the lens back in, the autofocus still worked. That is amazingly robust for such a thin and light mechanism.
This is a fantastic review. I’m making a few microscopes and was informed by the pihut (thepihut.com) that the previous 8MP v2.1 cameras have been replaced by the current model 3. Not sure if the V2.1 will be discontinued, but they are extremely difficult to locate in the United States.
Many people, including myself, have noticed that the arducams do not function with the current OFM software.
Just as the Pi is supposed to be coming back available, the camera goes away…
Looking in the UK, the maker retailers seem to have stopped stocking the Pi Camera V2.1, but the big electronics firms still have them (RS and Farnell/CPC) with more than 150,000 in stock between them. However Newark (sister company to Farnell in the US) only has a small number of the NoIR version.
The announcement of Camera Module 3 seemed to say that it was a new camera alongside Pi Camera V2.1, but having it still manufactured is not the same thing as it being widely stocked. There are other projects where I need a fixed focus camera to keep the image size constant, so the Camera Module 3 is a problem even when there are not the software ties to V2.1 that we have on the microscope.
The NoIR is still widely available but I don’t think is OFM compatible. It is too hard to make the Arducam or similar OFM compatible?
The V2.1 NoIR should be the same as the normal V2.1 in terms of the connection to the Pi and operating with the OpenFlexure software. The only difference is that it does not have an optical filter in front of the sensor to remove any infrared light. When using the camera to image a scene in daylight or using incandescent illumination this will make the colours look odd. In the microscope with LED illumination the LED spectrum usually contains no infrared anyway, so having no filter should make no difference. However, I have not actually tried it.
Making other cameras compatible requires quite a big change in the software in order to implement the camera colour and lens shading correction that makes the microscope images so clear. It is going to be necessary, the current method not only prevents other cameras from being compatible, it also ties the microscope server to an old version of the Raspbian operating system.
I think you can disable the autofocus/set it to manual on the new camera so it should still work for non-OFM uses. There’s also the global shutter camera with larger pixels New Raspberry Pi Global Shutter Camera for machine vision and more - Raspberry Pi which could be very useful for fluorescence, imaging fast things (it should be able to do 30us exposure if we can get enough light), and synchronising to illumination.
Has anyone tried the lens shading tuning described in https://datasheets.raspberrypi.com/camera/raspberry-pi-camera-guide.pdf ?
According to your findings, camera module 3 differs greatly from v2.1. I believe it will necessitate some modifications to the objective tube and possibly another type of corrective lens(?) as well as software changes. But aren’t we passing up an opportunity to increase image quality by not making it more compatible?
There is actually not much to do to make the camera physically compatible. We would just need to define the new camera cutout shape in the same way that we have for the existing cameras.
The resolution part of the image quality is set mainly by the objective lens and the illumination, all the cameras have plenty of pixels to cover the optical resolution. The new camera has bigger pixels and so should have better low light and noise performance. The lens shading correction is the biggest part of the visual image quality, and is what makes tiled images look good. That is the software part that is only currently implemented for V2.1.
The software is the larger task, because it means somebody learning how to use the new lens shading in the latest Raspberry Pi OS and libcamera. However it could bring big rewards because there should be ways to make it much less camera specific.
I finally bought the new module today. I now have OFM server running on the latest 64bit Raspberry Pi OS and can stream the preview MJPEG stream using Picamera2 (which uses libcamera) and take images in OFM software. The dependencies are a complete mess (e.g. using venv --system-site-packages to include libcamera), but otherwise, it’s looking promising. The more complicated part of camera configuration, lens shading etc. is mostly untouched yet, but it should be supported by picamera2 so with a bit of luck it won’t be as bad as I feared. I pushed my implementation of PiCamera2Streamer in Commits · picamera2 · OpenFlexure / openflexure-microscope-server · GitLab (it will need some cleanup when it’s done, I just wanted to have something working for now).
I’ll try to make progress on it when I have some free time, if anyone else wants to work on this I can provide my SD image to simplify setup.
Hi everyone, my first post in this forum! I am building only the picamera objective module of the OFM at the moment, and I found that the camera does not fit into the lens spacer module. I played with the openSCAD files on OFM gitlab and found that there is no picamera 3 parameter file in
openflexure-microscope-master\openscad\libs\cameras
Has anyone done work in accounting for the hardware change in picamera 3 (in openSCAD) and do you mind uploading them there? Or I might work on it and upload it later. Thank you! 
@Koushouu welcome to the project! at present the Raspberry Pi camera module 3 is not supported by the Openflexure software. The only supported camera is the Raspberry Pi camera v2.1 . As noted briefly earlier in this thread and in more detail in other threads, it requires a considerable re-write of the code to get the important functions of the microscope, like autofocus and colour correction, to work with other cameras. These software changes are something that @r.w.bowman is currently working on but it will not be ready for use for a while. It is intended to be in the next major software release (v3.0).
The physical hardware is more straight-forward. I have made a branch with a draft of the camera parameters and the cut-out required for the camera module 3 : picamera_3_mounting. This is not tested and is not scheduled to be part of the next full release of the hardware (v7.0.0). If the software updates enable us to use the Camera Module 3 then this and other cameras will be added as a minor release, something like v7.1.
Hi WilliamW –
In case you still monitor this thread on swapping the lens in Camera 3, did you happen to have noted the thread size of the lens mount when you took it out? I wonder if it’s a standard M12 thread or smth funkier. I am working on a nanomanipulation microscope and using Camera 3 as a quick start to work out the optics, before I dive in with libcamera and switch to a (hopefully) lower-noise MONO sensor. I need a lens with a much longer focal distance, and I will mostly use my own focusing mechanism driven by a piezo, thus, I am not afraid to lose autofocus.
Of note, according to this paper, replacing the lens leads to the disruption of on-board colour and flat-field correction which is optimized for the stock lens (the paper is for the V2 camera, would one expect the same to occur for the V3 camera?)
@runcyclexcski the thread is not M12, it is about 8.5mm diameter over the threads, which is larger than the Pi Camera V2 which is about 6mm diameter.
The flat field and colour correction for the Pi Camera 2 are handled by the OpenFlexure server software for the microscope, but there are remaining colour saturation issues caused by the lenslet array, as discussed in recent threads:
Focusing and Chromatic Aberration Issues,
First build, basic low cost microscope v7.0.0-beta1 - #10 by Yashka,
and Investigating tube lenses for infinity optics, RPi HQ camera, and a simple upright microscope
I have not yet tested the Pi Camera Module 3 as it is not yet supported by the software, but I would expect it to have similar effects to the Pi Camera 2 because it is a wide sensor with a short focal length lens. The Pi HighQ camera is much better in these respects. You can also get a version for M12 lenses which might help you.
Many thanks, WilliamW. I just ordered the HQ camera since it indeed seems to be better optimized for swappable lenses, but I will keep the Camera 3 as a “positive control”. I cannot seem to find in SONY sensor specs which ones have the CRA compensation (if yes, what the optimal angle is), and which ones do not (no lenslet shift). Do you happen to know how to identify the correct sensor type (no lenslets, or no shift)? I have a board with a Starvis sensor (IMX462); this does have lenslets, but I am not sure about the shift, and the Sony specs are not helpful. My experience in microscopy is with cooled EMCCDs (giant 13-micron pixels), thus, I’ve never had to worry about issues in small CMOS sensors, lenslets etc.
The threads you linked to are, indeed, quite helpful. I just discovered the openflexure resource.
I am not particularly surprised that lenslet details are absent from specifications. Small camera sensors would be most likely to have them because of the large relative area of small gaps between small pixels. Small cameras with short focal length lenses will need a lot of shift of the lenslets relative to the pixels. Sensors like that are not designed for our scientific uses, they are designed for consumer products with a specific lens and a particular price/performance.
With these consumer sensors it will be test and see, but all being well people report what they find, so that there is not too much duplication of effort.