New HQ Raspberry Pi Camera with C/CS-Mount

The Raspberry Pi Foundation just released this new camera module that has a C/CS-Mount for interchangeable lenses and a better sensor than the V2 (and certainly the V1) camera module.

I think this might be exactly what some of us are looking for to build a scanner for 8mm (or even 16mm) film around a Raspberry Pi. It’s certainly a much better and still affordable alternative to unscrewing the lens on the V1 camera module.

What are your thoughts on this?
Has anyone had a chance to try it yet?
Do you have an opinion what lens might work well with it for building a telecine machine?

1 Like

This looks cool, I wonder what lens would be good for 16mm?

that looks promising. From the data sheet: “this product is designed for use in consumer use camcorder”.

So it seems that this is the first Raspberry Pi camera chip without a CRA-compensation by microlenses. That would be fantastic, as the CRA-compensation (a usual technique for short fixed focal length setups like mobile phones) always led to color drifts and desaturation issues if you replace the standard lens. These issues are impossible to compensate fully in post production. Nevertheless, quite a few people based their movie scanner on Raspberry Pi cameras and got resonable results (I got only acceptable results with the v1-camera, which has a lesser CRA-compensation than the v2-camera.)

If you match one of the v1- or v2-cameras with a Schneider Componon-S 50 mm, with the lens placed about 100 mm from the chip and 100 mm from the movie frame, you will image the usual Super-8 format perfectly, even with a little headroom for sprocket detection and the like. This chip has double the size of the v2-camera, so the optical setup (distance chip-lens + distance lens-frame) will need to be adapted. It would actually shift the Componon-S slightly out of the working range this lens was designed for. Should still work however. Otherwise, the lens could always be reverse mounted to solve this issue.

One will have to be see how the software support of the new v3-camera will work. I guess only time will tell. One standard approach of utilizing these Raspberrry Pi cameras, the picamera-library (Python-based), hasn’t seen much update activity recently. Using the standard software supplied with the Raspberrry Pi (raspistill or -video) is way too lame for most film scanning applications.

From my experience with the v1- and v2-cameras, the Raspberry Pi processing pipeline does employ a lot of automatic processing. It is not easy to circumvent these automatic processing steps - and they can easily introduce flicker and the like in your scanning results if not switched off. I never succeeded in turn off all processing deemed necessary by the Raspberry Pi foundation or the chip manufacturer for proper use. For example, the v1- and v2-cameras employ noise reduction algorithms which actually work not only on the digital noise of the image sensor, but also on the noise introduced by the film grain. Well, depending on your taste, that might even be considered a valuable feature. However, a chip designed for “consumer use camcorders” is certainly a different beast than a machine vision camera and might feature some processing steps which you do not want to have in a scanner application. I will certainly have a look at the new camera chip.


Glad we have you to walk us through all the considerations, @cpixip! Looking forward to seeing what people come up with.

Ok, just a quick update here: the new HD camera is not too bad.

Contrary to what I suspected, the camera started to work right away on one of my Raspberry Pis which still uses an old Summer 2019 “buster” version of the OS (the guys at the Foundation are at a Feb 2020 version already).

My copy of the picamera-lib is a fork with lens-shading build in, otherwise it is not so up-to-date compared to the current picamera-lib.

So in fact, I expected total failure with the new camera.

Well, that was not the case. At least in the resolution I tried, which is 1296x972 pixel, I could stream video from the device using my old software based on the picamera-lib. I could trigger most function that I do not need, for example the image effects. Exposure settings as well as settings for brightness, contrast and saturation (via picamera) were accepted. In video-streaming, I could vary the quality of the MJPEG-encoding over quite some range, effecting as expected the average frame size send to the receiving computer.

I have the impression that the whitebalance algorithm still needs some tuning, but it works sufficiently well in most cases.

What did not work is setting a lens-shading table (well, you would not need that with the HD camera anyway) and activating the capture via the still-port. That might be rather an issue with my software than with the picamera-library. What most probably worked, judging from the slow-down in framerate, is the switch to raw-mode. To be sure about raw mode, I need to write code for reading and decoding the raw image size of the new sensor - that will need some time and effort.

So, in summary, I am surprised how much of the old software interface is available right out of the box for the new HD camera. Here’s an example image to show the color output of the new camera. It was taken with all “autos” on: autoISO, autoExposure and autoColorbalance. Daylight exposure. A 16mm lens @ 1:1.4 setting was used, with an exposure time of 1/30 sec and ISO 130:

(Remember, that is a single video frame, from the videoport, not a still frame (traditionally, the video and still port have different image characteristics, due to different processing pipelines))

Update: I switched resolution now to 2592x1944 pixels, which is an old resolution mode of the v1-sensor. AutoISO is now 183, exposure time 1/64 sec, video streaming at about 7 fps. Here’s a cut-out of the frame

which shows some heavy sharpening happening here. Furthermore, here’s the also enlarged image of a screw drive. Note the staircase-like appearance of bright line visible in head of the bit screw - that should ideally be a single smooth line:

This is the kind of “advanced image processing” you will probably have a hard time to get rid of within the Raspberry Pi software environment. Here’s the full frame were the above cut-outs were taken from:


It’s great to hear about some actual first hand experience with the new camera!

The 16mm lens you were using isn’t by any chance the 16mm lens that is offered alongside the HQ camera? I would love to hear if anyone has had a chance to try that or the 6mm lens (with respect to 8mm film in particular).
I am still looking into what lens to get for my 8mm film scanning setup (somewhat on a budget), so I was reading up on the 6mm and the 16mm lens. In The Official Raspberry Pi Camera Guide they recommend the 6mm lens for macro photography, which seemed odd to me. From what I gather from these data sheets (6mm data sheet / 16mm data sheet) their MODs are the same at 0.2m. That should make the 16mm more suitable. Do please tell me if I am mistaken.

Would this help?

1 Like

@jankaiser: well, yes. I was using the “offical” 16mm lens. The image of the camera box I posted above is actually the shortest distance you can focus this lens (with the lens screwed in fully).

The lens is not that bad, but if you look closely on the color chart also posted above, you can see some barrel distorsions.

In case you want to image the Super-8 frame with this camera chip and lens, you will need somehow to extend the distance between lens and chip.

For the v1- and v2-cameras, the sensor size is actually just about the same size as the frame area (plus sprocket) of a Super-8 frame. Therefore, any lens can be used in an arrangement which images the frame 1:1 onto the sensor chip. Simplifying a little bit: given a lens with a focal length f, you get this 1:1 imaging if the distance between sensor and lens is 2 time f. And you will discover that the distance you need between lens and Super-8 frame is also 2 times the focal length of your lens.

Now, there’s a twist hidden here. Lenses are manufactured to work optimal in a certain regime. So, of course you can use a normal lens for macro photography, by using just extension tubes. But you won’t get the optimal lens performance out of this setup. Your normal lens is optimized for a distance of one focal length between lens and camera chip. That is the reason some people reverse the lens they are using in doing macro photography.

The choice I made was to pair the camera sensor with a Schneider Componon-S 50 mm. For two reasons: first, this is an old enlarger lens which is optimized exactly for the distances I am using it. Second, I have two of these lenses available from my old analog photolab :smiley:

Whether the Raspberry Pi foundation lenses perform sufficiently well in macro conditions needs to be seen. If I would have to choose between the 6 mm and the 16 mm version, I would probably go with the 16 mm version. First, it is easier for the optical designer to optimize a long focal length, so I would expect the tele-version to have less a distorsion problem than the wide-angle version. Second, if your camera would be in the 1:1 setup (which is not the appropriate one for the new HD-camera, because the sensor size is larger)it would be about 32 mm away from the film gate with the tele-lens, but only 12 mm away when using the 6 mm wide-angle lens. More space around the film gate is usually of advantage, because, for example, you might want to clean it occationally.

All in all, I would recommend not using these kind of lenses, as they are designed to be used in surveilance applications - you will probably have a better image definition if you use a better lens. Even the above mentioned Schneider Componon-S 50 mm has a sweet spot: you get the sharpest image definition at an f-stop of about 5.6 to 8.0. Lower f-stops start to blur the image, quite noticable already at 2k to 3k scan resolution, because the outer parts of the lens focus on a different plane that the central parts. Pushing to higher f-stops leads also to defocusing because the light rays are bend around the small f-stops. All in all, one probably just has to try out the lens.

1 Like

@WDaland: wow, that’s an interesting find! Waited for something like this to happen for years. That might give the opportunity to optimize the available Raspberry Pi cameras for the task at hand, namely scanning movie frames with optimal fidelity. The v1- and v2-sensors are already supported, but frankly, they only can be used with their original lens. The new HD-sensor is a different beast and will be supported shortly. Cool :sunglasses:

@cpixip: Thank you so much for this great insight! It’s very helpful.

I’ve seen the Schneider Componon-S 50mm being a fan favourite around the Kinograph forum for a while now. I had always assumed it’s on the pricier side, but it seems a decent used one can be had on eBay (in Germany) for as little as 50€. This puts it in the same ballpark as the 16mm Raspberry Pi lens and presumably makes it the better “deal”.

Have you had the chance to try the Componon on the HQ Camera as well?
I’m guessing it would need at least a 43mm filter thread to C-Mount reverse adapter to mount the lens in good setup for 8mm film scanning.

Well, have a look at my current setup, utilizing a see3CAM CU135 ( AR1335, sensor size about 1/3.2", or 4.54 x 3.42 mm, diagonal 5.68 mm, max 4096 x 3120 px), mounted onto a Novoflex bellow via a 3D-printed adapter. On the other side, the Componon-S 50 mm is placed - not in reverse mode.

As you can see, the distance between sensor and lens is about double the size of the focal length of the lens, and the distance between lens and movie frame is about the same. Such an optical setup leads to a magnification scale of about 1:1. In truth, the optics are adjusted to a scale factor of 1:1.7. So the camera sensor sees an area of about 8 x 6 mm. This allows me to image the sprocket neighbouring the frame and have a little headroom for the frame position. The actual camera frame of a Super-8 movie is 5.69 x 4.22 mm, the projector is supposed to use only 5.4 x 4.01 mm of the camera frame.

Now, I have used the same setup with the Raspberry v1-camera (OV5647, 1/4", 3.6 x 2.7 mm, diagonal 4.5 mm, max 2592x1944 px) as well as the v2-camera (IMX219, same dims as OV5647, max 3280x2464 px). For these sensors, the lens only has to be moved a little bit to get the same scale as with the see3CAM.

Here’s a more detailed view of the see3CAM mounted on the 3D-printed adapter which fits directly into the standard Novoflex mount:

I would prefer to use the same setup for testing the new Raspberry HD-camera (IMX477, 1/2.3", 6.17x4.56 mm, diagonal 7.66 mm, max 4096x3040 px), but the bulky C-mount of the camera is getting into the way of designing an adapter. Currently, the only option I see is to unscrew the whole aluminium mount and just use the bare sensor - I am not sure at the moment if I want to go along that path. Otherwise, I might opt to design a totally different camera setup.

Both routes will take some time, I am afraid, as I am currently using the scanner to digitize Super-8 material. I would also need to partially rewrite my old software to handle an appropriate camera mode for the new HD-camera. So it will take some time for me until I can share scan results with the new camera chip.

I am currently using the see3CAM in a resolution of 2880 x 2160 px, running at about 16.4 fps. From the specs of the Raspberry HD-camera, I think you would get maximal 10 fps out of the HD-camera at that resolution (in fact, I got about 7 fps with my python-based client-server software). So frame-rate wise, the new HD-camera is not better than my current setup.

My primary goal is to do fast HDR-scans - and the major bottleneck here is the time a camera needs to reliably settle onto a given exposure value. Not sure whether the new HD-camera behaves in this respect better than the old ones. Maybe the new libcamera-interface is helpful here. I will update on this as soon as I know more.