Arducam Pi Hawk-eye is a 64MP camera for Raspberry Pi 4/CM4 | Hacker News Reader

Arducam Pi Hawk-eye is a 64MP camera for Raspberry Pi 4/CM4

cnx-software.com

44 pointszdw48 comments

At what point do you start seeing diminishing return on pixel-count with such a small sensor? (Or can you always get value if you're willing to bump up your exposure time)

I guess if you don't mind reducing the resolution, you can e.g. average 4 pixels to reduce the noise (but I don't know if that gives you a lower noise floor than just a 16MP sensor in the first place...)

You would actually have more noise, or at least, not less noise. There is readout noise associated with reading the information out from each pixel. Using one bigger pixel would give you less noise than four smaller ones :)

The summed value scales linearly with the pixel count but the combined readout noise only with the square root of the pixel count. Though, there are indeed other reasons to prefer a 16MP sensor in the first place (most notably, dynamic range, but also allowing slower readout).

I'm no physics or optics expert but this paper seems to suggest you're wrong?

https://www.sciencedirect.com/science/article/pii/S026322411...

"...show that an array of small independent sensors is always less noisy than a large sensor of the same size."

So it would seem! Thanks!

It’s mostly a problem of pixel size. The smaller the pixels the less light the pixels get. That means really terrible low light performance. And no software can’t magically make that as good as a pixel 4x the size.

The only advantage here is it allows you to get away with more crime like cropping and digital zoom in brighter lights. That may be an advantage depending on the application.

I’d rather have a 12MP sensor twice that size with some glass in front though for most applications. Far more useful.

> with some glass in front though

Since it sounds like you're familiar with the field, any chance you've come across a CS- or C-mount lens with an autofocus motor? I've looked around a bunch and haven't had much luck. The current solution is a full C-mount-to-Canon-EF-mount adapter that has drive electronics in it, but it's eye-wateringly expensive and huge & heavy.

Haven’t gone near those mounts. All mine is Z mount recently and F mount going back to the dark ages.

Never had a reason to use them, but I do recall that Edmund Optics has some C-mount units with liquid lenses in their catalog. The driver modules will allow control over USB or I2C.

I've used them in some industrial vision applications with Dalsa cameras. They worked fine, I would have preferred a fixed focus and a manual adjustment when the requirements changed (it was much more difficult to get good real-unit measurements and to compensate for distortion) but they worked fine.

Awesome, good to know! Yeah, the EO Liquid ones came up in my searches too, but I'm completely unfamiliar with that tech (coming from a conventional DSLR world). Thanks!

IDK, have you looked at Kurokesu's offerings?

https://wiki.kurokesu.com/shelves/cameras

Oh wow, I have not come across these folks! Very cool, yeah, these are definitely worth a closer look! Thank you!

My original canon digital rebel XT, I think, is 6MP, and its output can be printed poster size with no visible degradation at any normal viewing distance (like six inches or farther).

So yeah, I'll take some good glass and literally any sensor post-2005 (when I paid $1100 for that 6MP)

This camera does indeed have too many pixels.

If you use the Rayleigh criterion to calculate the maximum angular resolution based on aperture (θ = 1.22 * λ / d) using green light for the wavelength (and focal length / focal ratio to get the aperture) and use the resulting angular resolution and the given diagonal 84 degree field of view... you end up getting that there are about half as many pixels as the maximum theoretical angular resolution. Combined with lens imperfections and other sources of distortion (as opposed to the other commenters talking about exposure times) the result is that the extra pixels are really probably not adding any new information, or that they're right at the levels of diminishing returns where the returns are more or less zero for extra pixels.

>can you always get value if you're willing to bump up your exposure time

No, there are hard limits on how much extra information you can get with more exposure time.

What about pixel size compared to light wavelength?

If my maths is right, 7.4mm sensor side divided by 9,150 pixels is about 800nm size. Visible light is 400-700nm. And presumably not all of the pixel is actually light-sensitive.

Is this a valid comparison though? I’m not good at quantum...

The Rayleigh criterion above is exactly what is used to answer the question you're asking :) it tells you what size objects you can resolve with a given wavelength of light, which if you think about it in a different manner also tells you what the smallest useful pixel size you can have is. Two smaller pixels next to one another would be able to distinguish no more information than a combined one.

Actually, that's not true. However, going beyond requires deconvolution of the wavelength-scaling diffraction pattern, so it's only practical if you have narrowband radiation (stops working at 10~20% FWHM bandwidth).

Suitable sources include monochromatic LEDs, most lasers, and some gas discharge lamps (notably low pressure sodium).

> Turning your Raspberry Pi into a DSLR-like camera.

This is stretching the truth. From the sample images the low image quality is what I expected from a cheap tiny sensor and lens. Zooming in just gives you noise instead of detail. It's like the cheap "4k" IP CCTV cameras I have at home that aren't much sharper looking than HD 1920x1080 cameras I had.

Though perhaps hacks like sensor cooling to reduce noise and replacing the cheap optics with quality could improve quality.

I'm hoping this will meet expectations for a home security camera. Too bad none of their sample photos have a face in it.

You’d want good low light performance there which means a smaller number of larger pixels.

Noob question: why can't you aggregate 4 pixel values to emulate a single, 4x-larger pixel?

Well you still end up with less sensor surface area with 4x as many pixels on the same substrate because there’s a gap around each cell and the micro lenses are smaller. So you can aggregate them but you’re still getting less light.

There’s a happy medium somewhere on density vs performance. I think the iPhone 13 pro seems to have it about right for “reasonable compromise”

>"Future Raspberry Pi board may be able to take advantage of the higher video resolution and framerate enabled by the new camera module."

This is interesting, the community it's been asking for more powerful Raspberry Pi models, with more PCI lanes too. Models like that would be amazing for building NAS, routers and IoT devices

I’ve always wanted to run a small pi box as a router with pfsense. Right now my only other option for a small all in one, low power pfsense box is maybe an Intel NUC?

Your biggest hurdle there is that pfsense requires x86-64

For pfsense you'd really do a lot better with a small x86-64 system (mini-itx motherboard) that has four or more gigabit ethernet ports with Intel chipset onboard, attached to PCI-E 3.0 bus. In a small mini-itx case it would definitely be a lot bigger than a raspberry pi but also a great deal more capable.

Depending on your needs you can also get systems that have several 10GbE SFP+ cages on-motherboard.

If you search "mini firewall appliance" or "pfsense router" on your favorite marketplaces you'll get results for some custom intel hardware that has all of everything you need in a package smaller than mITX.

yes, the usual industrial/embedded motherboard manufacturers build such things, some are NUC sized.

If you're looking for something cheaper than a Pi try finding used thin clients, which are basically x86 industrial PCs. With a managed switch behind it you can use seperate VLANs so that you can run pfsense with both WAN and LAN on a single NIC. Obviously this will cause reduced speed on the WAN-LAN interface due to the single shared NIC, but if you're looking at a Pi anyways the networking performance of the thin client may be adequate for your needs.

or free 8 year old laptop with a cracked screen

the 4-camera kit is interesting. seems like a decent way to capture high resolution depth images using offset

And multispectral images

Wonder if you can combine it with the multi-flash technique for better results?

https://web.media.mit.edu/~raskar/NprCamera/

"(almost)"

i'm mostly interested in composed portraits and still subjects. a little time delay is fine with me, and could even be used creatively.

Nice, I'm right now working on a raspberry pi camera solution to create a timelapse of something I'm building that will take about 6 months. I have the original camera module (raspberry pi camera rev 1.3) but I'd love to try this 64mb one out someday.

Does anyone have any idea why this camera is limited to 1080p30 when playing video?

After all, 1080p30 is only 0.5Gbps, and with the CM4's 4 MIPI lanes at 1Gbps each, there's enough input bandwidth for 4k 60fps.

>1080p30 is only 0.5Gbps

You sure about that? It should be 1920 * 1080 * 3 subpixels * 8 bits * 30 fps = just under 1.5Gbps

I assume they use chroma subsampling to make it work

Yeah, I'm pretty sure.

The sensor will have a Bayer pattern [1] and the data will go across the bus in Bayer format. The processor will then perform debayering. So no need to multiply by 3 channels per pixel :)

While many image sensors will perform debayering for you if you want, doing so means you need 3x the bandwidth for not much benefit, so very few people do it.

[1] https://en.wikipedia.org/wiki/Bayer_filter

So you are working in monochrome? Even after you have applied the Bayer filter you still need 24 bits per pixel do you not?

No - go check out that Wikipedia link about Bayer filters.

For the vast majority of cameras, if you buy a "4 megapixel" image sensor, you get 1 million red pixels, 2 million green pixels, and 1 million blue pixels.

When you load the image into your image editor and see 3 colours per pixel, 2 of the 3 are interpolated from neighbouring pixels.

really wish they had put a C-mount for lenses on it. Also, every single raspberry pi CSI connector or camera I have (in the tens now) has broken under light handling.

Eh, C-mount means sacrificing autofocus.

IME many applications get a big performance benefit from autofocus - in both home and industrial applications.

I want to use this in a situation where I can control the focal distance (microscope). In principle you could even make an autofocus system with a zoom lens and a servo although the engineering is definitely non-trivial.

Is there a standard mount (other than DSLRs) that supports autofocus?

>Sensor – Sensor with 9152 x 6944 pixels resolution

Well, that clears that up!

It's very close to a Sony IMX686, which would be really nice.

Reply on news.ycombinator.com