I've encountered lenses with that sort of connector on from my days working on analogue CCTV systems. Some camera modules had a drive signal output for those lenses. They were pretty trivial in looking at the analogue video signal (minus sync pulses) and driving the iris to try and get a preconfigured level of output signal.jbeale wrote: ↑Fri May 01, 2020 1:33 amBy the way, some C/CS mount lenses are "DC Auto Iris" in which the iris is servo controlled. The lens has a cable with a small square 4-pin connector. I don't know how standard the configuration is but on the two such lenses I have https://photos.app.goo.gl/GVZBKhP5L61nSKD2A the iris is fully closed when the cable is detached. So to use these lenses with the new Pi camera, I would need some kind of a drive circuit to at least hold the iris open, if not drive it in some controlled way.
I haven't found much detail, but supposedly two pins are a drive solenoid (0..30 mA?) and the other two pins are a feedback coil with a signal proportional to iris velocity (not position), sometimes labelled "damp" or "brake". So maybe a DC-Auto-Iris Lens control circuit could be another Pi accessory someone could come up with. Edit: 3V @ 18 mA seems to open one of my lenses all the way, except the drive polarity on pins (3,4) is opposite what the diagram shows.
https://www.ebay.co.uk/itm/M12-to-CS-or ... 3038966647 as one of many results if you put "cs to m12" into Ebay.
If I'm reading this right, there may even be a 3D-printable adaptor to use M12 lenses on a C-mount flange. Not as accurate or strong as metal, but probably weighs less. https://www.thingiverse.com/thing:940406M12-mount instead ? CS lenses are a bit overweighted to fly
That can be done with raspiraw, I stated in initial posting of this thread that it was the reason I bought HQ camera -- I2C traffic from camera needs to be decoded by someone.blieusong wrote: ↑Fri May 01, 2020 8:42 pmI'm wondering if it's possible to read only two horizontal rows input from the sensor (and discard all the other pixels), but at a faster rate (like thousands of times per second)? I don't necessarily need the demosaicking on the fly, just recording the input on these two rows, and then do the demosaicking later, likely on a more powerful computer if the resulting is a several dozens of megapixels picture.
The ability to define your own lens shading tables had been in the firmware for a couple of years, you could have used those rather than moving to USB.XFer012 wrote: ↑Fri May 01, 2020 10:54 pmI'm excited by this new HQ camera module.
I have a number of V1 and V2 modules and an assortment of unofficial ones (because of CS mounts!) with many C, CS and C-adapted lenses.
My no.1 question, to jamesh and 6by9:
Previously, when mounting an high quality C/CS lens on a (mount-)hacked camera module, I experienced bad quality at the image borders (not because of my top-line Computar lenses...).
At the time, I did a number of tests to investigate if it was the "internal correction" applied by VideoCore (to compensate for the less-than-stellar quality of the stock lens) or an effect of sensor microlenses interacting (badly) with C/CS lenses geometry.
Looked like a mix of both; so I had to switch to USB industrial cameras for my purposes (sadly).
Is an "internal lens correction" still applied to this new HP camera module?
Any image quality test with different C/CS Lenses, other than the "official" ones? Does image quality hold up at the borders?
Thanks in advance; and congratulations for what it looks like an outstanding module!
Why worry? It works fine., These lenses suffer from very minor aberrations compared with the V1/2, so the auto correct on top of the basic table works really well. I think you can turn it off anyway but that will produce worse results.XFer012 wrote: ↑Sat May 02, 2020 2:12 pmUnfortunately, even with the ability to load my own correction table in the firmware, I could never get decent results with my high quality C-mount lenses, which conversely work as intended on USB cameras.
As I wrote, it must have been a mix of issues with the correction model and with (bad) interaction between sensor and lenses (the sensor was designed for very different lenses).
So no, I was actually forced to drop Camera Modules V1 and V2.
The fact that you still apply internal corrections via VideoCore even with the new HQ camera module makes me worry.
I hope it can be totally disabled.
I am not using your official Cmount lenses (they don't suit my needs).
No, it would not.I think you can turn it off anyway but that will produce worse results.
HDR requires hardware that can process the different frames into one combined frame. The Pi ISP can't, therefore whilst we could in theory read out HDR frames, there's not much you can then do with them on the Pi. There may be a case for storing the raw frames for post-processing, but that isn't a mainline use case.HermannSW wrote: ↑Sat May 02, 2020 7:13 pmThere is no mentioning of HDR in this thread, the General board thread, nor on HQ product brief.
But imx477 sensor supports HDR -- will there be some HDR support for Raspberry HQ camera?
https://www.sony-semicon.co.jp/products ... _Flyer.pdf
It's been there for 3 years - viewtopic.php?f=43&t=175711XFer012 wrote: ↑Sat May 02, 2020 7:46 pmIs it possible to check if totally disabling the VideoCore lens correction (without also disabling the sensor bias correction) is actually an option?
It would make a big difference for me in judging if the new HQ camera module would suit my needs.
Thanks in advance!