Resolution of camera modules inclusive dependency of the lens

Hi!

I placed following comment below the 108MP resolution USB camera module, what is announced from Arducam. Please users, use forum here in case, you want to give your opinion for this comment. I think, I’m not alone with the problem, that Arducam published sensor resolution of camera modules inclusive fixed mounted lenses, but no information about the resulting resolution of senor and lens in combination. Especially in the range of image corners.

------------- My comment:

Hi,

Your new very high pixel rate camera modules are a very good idea for a lot of applications which need resolution for image analysis in details. For example, I plan to build an automatic insect monitoring trap based on image date. So I need a big monitoring range of a 1.5 … 2 m³ surface. In low resolution, I can detect objects in this range, set ROIs and than take only the ROIs in high resolution. Either, I use a normal resolution camera for recognizing ROIs and a pan-tilt tele camera to get the content of ROIs in high resolution. Or, I take an array of cameras over the complete observing surface. Or, such a high resolution solution. I think, this use case explains a lot of typical scenarios for high resolution cameras as an replacement of camera arrays and automatic pan-tilt mechanism solutions what are expensive and susceptible to failures.

But a question to Arducam team:

If I plan such a project, so I know the resolution what I need at least in the image. We know the resolution of the camera. But the second object of interest is the lens in front of the camera. ‘Resolution at least’ means in this case the resolution what can deliver the lens over the complete image ‘at least’.

For the 64MB camera, Arducam published a comparison image between some camera types. But there are no absolute dimensions at this images. And, I assume, this is in the middle of the image. For some cameras, we can recognize the pixel size in this images. But this is not seriously. Any resolution information about the really resolution over the radius are missing at all camera modules inclusive lens(!). Some sample images in the nature, like for the 64MP camera, are not enough to decide if my project needs a 16MP, 64MP or 108MP camera module to get the needed resolution in the corners of the images.

Maybe, such facts are not strong interesting for hobby makers. But your justification for the high resolution models are special use cases.

Your work is very good for use cases what needs only less pieces (one prototype). Is very good for use cases in different scientific areas, where are no professional devices on market. But for such people it is not interesting, how is the pixel resolution of the sensor alone: Interesting is the minimum resolution what we get all over the image depending of sensor AND lens system.

Please: Publish some material for your camera modules usable with RasPi/Jetson/USB-SDK. So that we can plan our solution without ordering all of your modules to test this by our-self. I, and I think a lot of other persons, would like decide about the right camera module, before we order this.

Would this be possible? Also for this 108MP module?

A really measurement like defined in standards is not essential. Such test images like your 'A’s for the 64MB module but inclusive pixel size legend and for different positions in the image inclusive all 4 corners would be a good starting point. And please, gives the guarantee that the same lens is installed in the delivered modules.

Best regards, Frank

Hi again,

Please don’t misunderstand my questions about real resolution not as any kind of critic for the camera modules and the business of Arducam. What Arducam offers for us is exclusive in comparison to other solutions! Nobody of us is in the position to order high tech cell phone camera modules inclusive a SDK or a ready to use driver to reuse this for other applications. It needs such a player like Arducam to get such products for small development tasks.

But I would like to get more precise information about the modules in order to make some right development and order plannings and decisions instead of a long process of an order-trial-and-error-new-order-and-trail-process.

Frank