Raspberry Pi Cinema Camera

[schoolpost]

A long time coming…

Since my first Raspberry Pi, many years ago I’ve been determined to combine my passion of filmmaking and my love for programming.

For those that know, high end film/video cameras typically shoot high resolution ( 4K+ ) with very good codecs ( RAW when possible ) and with tons of manual control for high flexibility to manipulate images in the post processing stage.

Out of the box the Raspberry Pi provides a very friendly experience to work with cameras, with convenience features like auto white-balance, auto exposure, efficient h264/jpeg codec. These features cater to a wide variety of general applications, but for high end video work these are often hindrances that restrict you from controlling the quality of your image.

That is why I’ve seeked to bring the best elements of that high end video world to the Raspberry Pi Platform and today I wanted to share some early samples of what I’ve been able to capture. ( It's super late when I shot this, excuse the crude subject matter... oh and yes if you were wondering....I did spill that whole glass all over the table seconds after I stopped recording... )

DEMO VIDEO: https://vimeo.com/495719945


The demo was shot with the Raspberry Pi High Quality Camera + 6mm Lens on a Raspberry Pi 4B 4GB.



The video was captured in 12-bit RAW DNG, 2028x1080 @ 24fps.

The results I think speak for themselves, these are the kind of specs you find on camera's that cost $1000+

Davinci Resolve was used to edit the RAW footage, giving you full control over exposure, curves, highlight recovery, white balance, sharpness, etc….


Here is a link to the RAW DNG Sequence for those that wish to test it out ( the DNG’s are not in a fully fleshed out state, for ex. there are some “false” pixels on the frame edge that need to be masked out among other things, But this is being worked on. )

RAW FRAMES: https://www.dropbox.com/s/1ne0jdhfhixwb ... 4.zip?dl=0

As far as software is concerned...well maybe we won't get there just yet. It’s a cobbleded mess of jank. But...it works! That was my primary goal, to fundamentally show what this could do. Even if it meant approaching it in a less than elegant way. I’ll be providing a link to my source and soon as I can “clean it up” a bit. But that leads to my next point…


I could most certainly use some help! It’s miraculous that this even got here from my point of view given how much subject expertise is required in understanding camera systems, linux, etc...Contributions are very much encouraged and to those that have offered their help in the form of advice, tips or code snippets; you are why this was possible.


I think these results show a very bright and promising future for further applications of the Raspberry Pi as a full fledged Camera system.


Will share more very soon.

[Jack Hogan]

Good work, Csaba Nagy. In theory that should give you a 6.1x multiplier compared to Full Frame
viewtopic.php?f=43&t=295285#p1782788

And you should be able to run that resolution at twice the FPS. Have you tried 50?

[schoolpost]

Good work, Csaba Nagy. In theory that should give you a 6.1x multiplier compared to Full Frame
viewtopic.php?f=43&t=295285#p1782788

And you should be able to run that resolution at twice the FPS. Have you tried 50?

I have been able to stream sensor data at 50fps yes, haven't tried writing to disk though. Would need ~219MB's, which isn't necessarily a problem but it's reaching the max I believe my USB 3.0 SSD media is capable of.

Among a list of issues I have yet to tackle, one of them is more efficient packing of the raw data when saving to disk. Right now the 12-bit data is actually in a 16-bit DNG so there is wasted space, the repacking of the data is considerably taxing on a single thread as I've come to find and is an ongoing investigation of mine figuring out how to do it in less than frame time ( ~10-20ms ) can follow that here: viewtopic.php?f=33&t=296607

Also we're not just limited to this one resolution, we can also do the 2028x1520 mode at up to 40fps which would be nice for Anamorphic shooting dont have any glass to test this on, however.

Oh and I want to correct my initial statement, this is not my source code. It is based off of this specific version of a testing utility from 6by9: https://github.com/6by9/yavta

It works great beyond it's scope as just a development utility because It lets you use the ISP for RAW processing to give you a good live preview. Something that isn't exactly trivial and is computational expensive done yourself otherwise.

I've simply gone in and added some tweaks and modifications to make sure live preview is looking correct and to save DNG frames instead of just dumping raw binary data.

So for those interested in taking a stab at this themselves, I suppose you can look there as a start ( will be posting my fork soon ). I think going forward this project would benefit from implementation of libcamera as that is exactly what it was built for.

[RichShumaker]

The video was captured in 12-bit RAW DNG, 2028x1080 @ 24fps.

2 words
Woo
Hoo!!!

This is exactly the direction I want to go in. I have a few RAW thread that discuss this exact usage, making films with the RasPi. And I agree totally that 12 Bit RAW is still very expensive so a $50 camera module that can do it is amazing!!!

RAW Capture Challenge • Challenge COMPLETE 11.38 FPS • 12mp HQ Max FPS Capture
viewtopic.php?f=43&t=284937&

RAW HQ data compression to reach 24fps goal
viewtopic.php?f=43&t=291005

From my different threads I have learned that the CSI-2 2 Lane is the first issue. Having 4 lanes greatly increases the data into the Pi. You can do this with a Compute 4 a Dev Board and a 4 lane Camera(all theoretical for me right now).

The second issue is getting it saved. Having a PCIX1Gen2 on the Dev board opens up options and NVME is coming in the future.

Thank you so much for sharing as this is what I have been wanting to use the Pi for since I bought my first Pi V1 Camera.

[urpee]

Here is my own take on how to produce video on the Raspberry Pi using the Raspberry Pi High Quality Camera.

Studio setup

20201229_144941.jpg (250.05 KiB) Viewed 15545 times

Camera Lens

The lens, a Som Berthiot Pan Cinor 17-85, was originally used to film events for TV news in the 1960s. It is a parfocal lens, which keeps focus throughout it's zoom range. This led to overuse of zoom on early 70's films, but is considered essential for TV studio production and feature films. It is manually focused using a split screen and microprism ring in the finder.

c-mount 16mm cine lenses typically cover a 12.7mm film plane diagonal. Image circles smaller than this will vignette; circles larger than this will introduce a crop factor. The Pi HQ Camera uses a sensor with a diameter of 7.9mm. This produces a crop factor of 12.7/7.9 = 1.6, similar to using a 35mm lens on a APS-C camera. This shifts the zoom from normal-telephoto to telephoto-extreme telephoto, compressing the depth-of-field.

Camera Rig

The PiCamera for this project comprises a Pi HQ Camera, Raspberry Pi 4B, an external 128GB USB3 SSD, and a 5V USB-C battery pack. A Zoom H4N Pro 4-track audio recorder with built-in stereo microphone along with a slate was used to capture double-system sound.

The Pan Cinor is a heavy lens with a dogleg finder, so the first challenge was to securely mount the lens so that it would not damage the camera or the tripod mount. For this I used a camera rig setup with 15mm rails and fashioned a lens holder from a section of PVC pipe.

Pi HQ Camera with Pan Cinor

20201229_145220.jpg (253.65 KiB) Viewed 15545 times

I compared the results of the video with a Canon 80D APS-C DSLR. A Zoom H4N Pro audio recorder was used to capture audio for both clips. The Canon 80D clip is here: https://youtu.be/CH2CFl2wTGE

Canon 80D with Zoom H4N Pro

20201229_145046.jpg (202.5 KiB) Viewed 15545 times

For my tests, I recorded video at HD resolution (1920x1080) at 30fps h.264, and recorded sound at 48Khz 24bit broadcast wave. Video and sound are recorded on separate micro SD cards and then imported into a kdenlive project. kdenlive can't import h.264 directly; it must first be encapsulated in an MP4 container using ffmeg first. Sound is synced to video using the video slate the audio clap marker. The Pi HQ Pan Cinor clip is here: https://youtu.be/YfMxc8MpmA0. A camera zoom clip is here: https://youtu.be/1xAiqXQikss

Conclusions

The Pan Cinor is rated f2-f11, but my tests found it was only sharp between f4-f8. Because of the crop factor the camera was setup almost twice as far away from the subject than would be the case with a non-crop factor lens, and keeping focus was more difficult due to the compressed depth-of-field. At these settings the lens was as sharp as my Canon 80d using a 18mm-135mm varifocal zoom lens.

The Sony IMX477 sensor uses a rolling shutter that blurs subject movement which is inappropriate for general video. A better solution would use a sensor that covers 16mm with no crop factor and a global shutter.

[6by9]

If you're needing to repack to 16bpp for the DNG, then Unicam (the CSI2 receiver) can do that for you in the hardware. See the difference between V4L2_PIX_FMT_SRGGB12P and V4L2_PIX_FMT_SRGGB12
The niggle will be getting that into the ISP sensibly for your preview. You'll need to tell it that it's 16bpp Bayer, but then the black level block needs configuring to know how to scale the incoming data appropriately. I'll have a look into it when I'm back in the (home) office.

[schoolpost]

If you're needing to repack to 16bpp for the DNG, then Unicam (the CSI2 receiver) can do that for you in the hardware. See the difference between V4L2_PIX_FMT_SRGGB12P and V4L2_PIX_FMT_SRGGB12
The niggle will be getting that into the ISP sensibly for your preview. You'll need to tell it that it's 16bpp Bayer, but then the black level block needs configuring to know how to scale the incoming data appropriately. I'll have a look into it when I'm back in the (home) office.

Quite the opposite actually, I'm faced with the issue that the 12bit data is represented in 16bit word which is wasting space.
I'd need a V4L2 pixel format that is packs the 12bit data sequentially ( contiguously? not sure the right term here )

0000AAAA AAAAAAAA 0000BBBB BBBBBBBB : This is the method I'm currently using that does work with DNG, but wasted upper bits.
AAAAAAAA BBBBBBBB BBBBAAAA : This is the V4L2_PIX_FMT_SBGGR12P format but DNG cant unpack this.
AAAAAAAA AAAABBBB BBBBBBBB : This is what would work with DNG and doesn't waste bits. It would be great to have V4L2 FMT like this.

Having this last pixel format be hardware driven would be ideal! because as I've tested so far; doing this in the same thread in C is quite slow, at least not achievable in less than frame time.


I've made a couple modifications to the MMAL Preview to attempt to scale the 12bit within the 16bit range using some MMAL PARAMTERS:
-MMAL_DIGITAL_GAIN ( basically this is just doing some multiplication? so I scale by 16 )
-MMAL_BLACK_LEVEL ( set to 256 )
-MMAL_CUSTOM_CCM ( I use the offsets to boost the black levels to see a bit more shadow detail.)

All told this seems to produce an acceptable output, but these tweaks feel kind of "janky" if there is a way to change how the ISP is doing the processing itself like you suggest I think that would be a lot better.

Does the MMAL_ISP_OVERIDE Parameters still work? viewtopic.php?t=175711
Cause I've had trouble getting it to bypass certain parts of the ISP, I tried to use it disable it's gamma curve so I can apply my own using: MMAL_PARAMETER_GAMMA but I don't see it working.

[Jack Hogan]

Pardon my ignorance, but is MMAL the interface to the Broadcom ISP? Where might one find some documentation on it?

I've made a couple modifications to the MMAL Preview to attempt to scale the 12bit within the 16bit range using some MMAL PARAMTERS:
-MMAL_DIGITAL_GAIN ( basically this is just doing some multiplication? so I scale by 16 )
-MMAL_BLACK_LEVEL ( set to 256 )
-MMAL_CUSTOM_CCM ( I use the offsets to boost the black levels to see a bit more shadow detail.)

All told this seems to produce an acceptable output, but these tweaks feel kind of "janky"

If I intuit correctly, it doesn't seem janky at all schoolpost. As an ignoramus on MMAL but knowing a thing or two about post processing, the only thing that stands out is using CCM offsets to boost shadows: the 'proper' way would be to change gamma and/or apply a curve instead, as I think you were suggesting below. In fact if you are going to do that you may even want to use log-compatible settings/bit-depths, so that log-mode is already there to be used by the camera component if desired downstream.

Jack

[6by9]

If you're needing to repack to 16bpp for the DNG, then Unicam (the CSI2 receiver) can do that for you in the hardware. See the difference between V4L2_PIX_FMT_SRGGB12P and V4L2_PIX_FMT_SRGGB12
The niggle will be getting that into the ISP sensibly for your preview. You'll need to tell it that it's 16bpp Bayer, but then the black level block needs configuring to know how to scale the incoming data appropriately. I'll have a look into it when I'm back in the (home) office.

Quite the opposite actually, I'm faced with the issue that the 12bit data is represented in 16bit word which is wasting space.
I'd need a V4L2 pixel format that is packs the 12bit data sequentially ( contiguously? not sure the right term here )

0000AAAA AAAAAAAA 0000BBBB BBBBBBBB : This is the method I'm currently using that does work with DNG, but wasted upper bits.
AAAAAAAA BBBBBBBB BBBBAAAA : This is the V4L2_PIX_FMT_SBGGR12P format but DNG cant unpack this.
AAAAAAAA AAAABBBB BBBBBBBB : This is what would work with DNG and doesn't waste bits. It would be great to have V4L2 FMT like this.

Having this last pixel format be hardware driven would be ideal! because as I've tested so far; doing this in the same thread in C is quite slow, at least not achievable in less than frame time.

Not possible - sorry. And if it were possible in Unicam then the ISP wouldn't be able to accept it.
Yes 16bpp wastes storage, but is going to be the fastest / lowest processing overhead approach.

I've made a couple modifications to the MMAL Preview to attempt to scale the 12bit within the 16bit range using some MMAL PARAMTERS:
-MMAL_DIGITAL_GAIN ( basically this is just doing some multiplication? so I scale by 16 )
-MMAL_BLACK_LEVEL ( set to 256 )
-MMAL_CUSTOM_CCM ( I use the offsets to boost the black levels to see a bit more shadow detail.)

All told this seems to produce an acceptable output, but these tweaks feel kind of "janky" if there is a way to change how the ISP is doing the processing itself like you suggest I think that would be a lot better.

All processing down the ISP pipe is at (IIRC) 13bpp to give an amount of headroom in the pipe.
The input formatter and black level block convert the incoming data to match that. The input formatter unpacks any weird formats, and then black level subtracts off the offset at the bottom and expands out from a max value currently defined by the pixel format. Making that max configurable for 16bpp data (or possibly all) would add support for all the unpacked formats.

Doing it in digital gain just means that the numbers have already been expanded up out by black level with the wrong value, and then increased again. It'll work but isn't ideal.

Does the MMAL_ISP_OVERIDE Parameters still work? viewtopic.php?t=175711
Cause I've had trouble getting it to bypass certain parts of the ISP, I tried to use it disable it's gamma curve so I can apply my own using: MMAL_PARAMETER_GAMMA but I don't see it working.

MMAL_ISP_OVERIDE is only for the firmware camera stack, not the ISP component. The ISP component has almost everything disabled by default and a parameter to enable and configure it.

All of these parameters are being used via libcamera, so best to compare against that. The V4L2 parameters match pretty much 1:1 against MMAL because it's wrapping the MMAL component.

[6by9]

Pardon my ignorance, but is MMAL the interface to the Broadcom ISP? Where might one find some documentation on it?

I've made a couple modifications to the MMAL Preview to attempt to scale the 12bit within the 16bit range using some MMAL PARAMTERS:
-MMAL_DIGITAL_GAIN ( basically this is just doing some multiplication? so I scale by 16 )
-MMAL_BLACK_LEVEL ( set to 256 )
-MMAL_CUSTOM_CCM ( I use the offsets to boost the black levels to see a bit more shadow detail.)

All told this seems to produce an acceptable output, but these tweaks feel kind of "janky"

If I intuit correctly, it doesn't seem janky at all schoolpost. As an ignoramus on MMAL but knowing a thing or two about post processing, the only thing that stands out is using CCM offsets to boost shadows: the 'proper' way would be to change gamma and/or apply a curve instead, as I think you were suggesting below. In fact if you are going to do that you may even want to use log-compatible settings/bit-depths, so that log-mode is already there to be used by the camera component if desired downstream.

Jack

The preferred way is using V4L2, but that's only a wrapper over the top of MMAL. Libcamera is using V4L2 and is the camera stack that we're targetting in future.
V4L2 is already supported under 64bit OSes, whilst userspace MMAL isn't due to unresolved issues.

[nootropicMan]

Amazing work Schoolpost!

I've been wanting to do something like this. Can you share your source code on github? I'd love to contribute.

[6by9]

Quite the opposite actually, I'm faced with the issue that the 12bit data is represented in 16bit word which is wasting space.
I'd need a V4L2 pixel format that is packs the 12bit data sequentially ( contiguously? not sure the right term here )

0000AAAA AAAAAAAA 0000BBBB BBBBBBBB : This is the method I'm currently using that does work with DNG, but wasted upper bits.
AAAAAAAA BBBBBBBB BBBBAAAA : This is the V4L2_PIX_FMT_SBGGR12P format but DNG cant unpack this.
AAAAAAAA AAAABBBB BBBBBBBB : This is what would work with DNG and doesn't waste bits. It would be great to have V4L2 FMT like this.

Having this last pixel format be hardware driven would be ideal! because as I've tested so far; doing this in the same thread in C is quite slow, at least not achievable in less than frame time.

Not possible - sorry. And if it were possible in Unicam then the ISP wouldn't be able to accept it.
Yes 16bpp wastes storage, but is going to be the fastest / lowest processing overhead approach.

Not that it directly solves your problem, but I've created a firmware patch (now under review) to add support for the unpacked formats, and https://github.com/raspberrypi/linux/pull/4052 is the corresponding kernel patch.

[2blackbar]

So is Pi USB 3.0 port with SSD able to push about 360MB/s for 4k RAW at 24fps ?
Im new and if RAW recording will work in theory then ill gladly buy some unit, you could build nice setups.Especially extreme zoom (cause of 8mm sensor ) using 35mm sensor telephoto lenses with C mount adapter to basically anything out there.
Currently im using Canon M that crops from aps-c to 16mm film frame in 2.5k RAW thanks to Magic Lantern Devs.
From what i read about half year ago is that all ports on Pi just cant push that much data at 24fps.

Fom the looks of it, sigma FP camera records UHD 4K, 23.98fps, 2400Mbps, RAW 12-bit so is about 300MB per second ( similar setup usb 3 to SSD) but thats regular 3840x2160 frame, not sure what the frame size would be from pi camera.
Anyway that means there is a big chance that SSD drives through usb 3 will be able to handle that raw stream and save it.

[schoolpost]

Updates to come. Made some software improvements and have finally got around to prototyping an enclosure.

Fits nicely in palm of your hands

Stay Tuned.

[schoolpost]

More photos of the design and a preliminary name.

I didn't want to have to re-invent the wheel in terms of creating an entirely new/unfamiliar form factor so I based the design off the Sony ZV-1 which just so happens to have a very identical footprint to a raspberry pi board.

With that you can use existing accessories that were made for that camera, like in this instance I'm demonstrating it being used with a Smallrig Aluminum Cage that allows you to mount more accessories to the camera and adds extra rigidity and strength.

[nootropicMan]

I absolutely love this!

[eat-sleep-code]

More photos of the design and a preliminary name.

I didn't want to have to re-invent the wheel in terms of creating an entirely new/unfamiliar form factor so I based the design off the Sony ZV-1 which just so happens to have a very identical footprint to a raspberry pi board.

With that you can use existing accessories that were made for that camera, like in this instance I'm demonstrating it being used with a Smallrig Aluminum Cage that allows you to mount more accessories to the camera and adds extra rigidity and strength.

Is the body 3D printed or machined? What is the finish on it -- looks like it is textured?

[schoolpost]

Is the body 3D printed or machined? What is the finish on it -- looks like it is textured?

The body is 3D printed, the finish comes from a textured print bed. There is an aluminum cage that wraps the around body but that is an off the shelf product you can buy for the Sony ZV-1 Camera:

[schoolpost]

Some more test footage I shot today. Now that I have an enclosure and being battery powered I can take it outside of the lab.

Shot mostly with the 16mm Telephoto lens but also used a Canon 24-105 for some of the shots for some extreme zoom.

https://vimeo.com/501084285

[morrischu1986]

More photos of the design and a preliminary name.

I didn't want to have to re-invent the wheel in terms of creating an entirely new/unfamiliar form factor so I based the design off the Sony ZV-1 which just so happens to have a very identical footprint to a raspberry pi board.

With that you can use existing accessories that were made for that camera, like in this instance I'm demonstrating it being used with a Smallrig Aluminum Cage that allows you to mount more accessories to the camera and adds extra rigidity and strength.

I have signed up just to tell you how awesome you are!

[dgalland]

@schoolpost

Hi,

I see that you have done a lot of research on HQ, so I would like your opinion on the following problem:
My Telecine application captures super8 frames, we consider 1080P to be enough so with super8 size i gives 1500*1080.
The frames are captured on videport in JPEG are sent over the network to a PC for processing and writing.
On both sides, the application is in Python +Picamera + some opencv on the PC

Currently I use a V1 camera in mode 1 1920*1080 + ROI 1500*1080. Resized to 1500*1080
This mode seems to be a mode with reduced FOV but not binned. The result is very good (sharpness) with about 17fps.
In reality less because we make 3 exposures for a frame and with the shutter delays this gives 1.6s per frame.
The application is carefully multi-threaded and the limiting factor is the fps but not the network or the power of the PI or the PC
I wanted to try the HQ with its different modes but to my surprise the results are not as good as with V1.
The sharpness is not better even in mode 3 and mode 2 binned is even worse.
I dont explain some halo around the edges may be the pipeline + jpeg ??
I haven't tried mode 1 yet,
But HQ has advantages, especially better dynamics and probably better colors.

So the quality of your DNG images makes me wonder, can you explain me the following points:
- You use the mode 1 with a good quality and yet it's a binned mode ?
- How are these DNG images captured in video or still capture on video port.
- In JPEG+RAW + DNG conversion ?
- Which programming language, is it possible with Python + Picamera ?
I've done some tests with V4L2 which lacks some features and also with libcamera but without being convinced in the current state.
To summarize how in practice to get these beautiful DNGs !

Thanks for your advice

[Jack Hogan]

Currently I use a V1 camera in mode 1 1920*1080 + ROI 1500*1080. Resized to 1500*1080
This mode seems to be a mode with reduced FOV but not binned. The result is very good (sharpness) with about 17fps.

I wanted to try the HQ with its different modes but to my surprise the results are not as good as with V1.
The sharpness is not better even in mode 3 and mode 2 binned is even worse.

It depends on the application, but in general you should be able to get substantially better Image Quality out of the HQ than the V1. However it is less than intuitive how to ensure that apples are being compared to apples. For instance if you are comparing V1 non-binned to HQ binned, you have 1.4um pixels in the former and effectively 3.1um pixels in the latter, big difference all else being equal.

To make things simple you would ideally capture the same scene from the same position with the same framing (diagonal angle of view) and view final images at the same displayed size (diagonal, if the aspect ratio is different).

Several parameters are at work here. Off the top of my head, assuming the V1 with stock lens:

1) pixel size (1.4um V1 vs 1.55um HQ, binned or not)
3) lens blur/distortion (many more options and quality with the HQ, at a price)
4) f-number (2.9 V1 vs 1.4+ HQ, unaberrated lens blur is proportional to this)
5) focus/DOF (harder with higher quality lenses at lower f-numbers)

Just to give you a head start here is a scenario comparing the V1 in mode 1 to the HQ in mode 2, with a few assumptions:

V1_md1 diagonal = 1.4*sqrt(1500^2+1080^2) = 1.848mm
HQ_md2 diagonal = 1.55*sqrt((2*1500)^2*(2*1080)^2) = 5.729mm

The ratio is 3.1x, this has strong implications for choice of variables above and their effect on final image IQ. For instance to obtain a similar field of view you would need an HQ lens of about 11.1mm focal length (3.6mm*3.1).

What HQ lens did you use and at what f-number? Was the taking distance and field of view the same as in the V1?
Did you do a straight crop of mode 3, did you resize it or did you compare at different resolutions?
A couple of images would be useful to illustrate what you mean.

Jack

[cpixip]

Jack,

"Did you do a straight crop of mode 3, did you resize it or did you compare at different resolutions?
A couple of images would be useful to illustrate what you mean."

I think some images showing what Dominique is talking about can be found here, at the Kinograph forums https://forums.kinograph.cc/t/hdr-expos ... /1671/17?.

[Jack Hogan]

Thanks cpixip, I did not read through the whole thread but it would be useful to see how a V1 image compares to those when shot from the same position at the same field of view. Ideally with the -r switch, to see the raw files. I believe differences would be mainly due to technique, lens and f-number, with the HQ having the potential to capture substantially better IQ in the raw data, depending on setup.

As for processing in the HQ, yes, I seem to have read a a post around here suggesting that parameters vary somewhat arbitrarily based on the chosen mode. But that's easy to fix and not what I am referring to.

Jack

[dgalland]

Hi Jack,

Cpixip and I capture super8 frames (about the size of the sensor).
What we are looking for is resolution/sharpness with a decent fps.

So I use for the V1 and the HQ the same good quality 35mm CCTV lens open to half F4 with a ring extension (between 15 and 20mm).As the goal is to get 1080P in vertical I capture with a ROI in the center of the sensor.
In the center of the sensor the quality of the lens is better and there is almost no vignetting.
In the application the capture is done in Python/Picamera on the video port (for a better fps).
I also made the captures with raspistiil for comparison.

I have just replayed all my tets and my conclusions are the following:

- As you can expect the quality of the HQ in mode 3 full resolution is very good but the fps is low from 3 to 4 fps.
- HQ in mode 2 2028*1520 binned gives a bad result with a good 14fps
- HQ in mode 1 binned gives the same bad result with a good 19fps

- The V1 in mode 2 full res 2592*1944 gives me as good a result as the HQ full res with a good 12fps with the ROI
- The V1 in mode 1 1920*1080 gives me the same good result with a very good 17fps
So for my application the V1 remains the best choice.

Mode 1 of V1 is not binned and has no equivalent with HQ.
The HQ has no non full res non binned mode
These modes seem to exist in the sensor documentation but not implemented ?

That's why I was interested in schoolpost's workflow which seems to get quality images with HQ in 1080p.






Translated with www.DeepL.com/Translator (free version)