My first post here, and not exactly a FOSS question, but as I’m coming from a Linux background I’m hoping for some advice on camera hardware that will do what I want and work well with Linux.
I’m looking for inexpensive camera hardware, used or semi-DIY, with the following capabilities:
Capture and transfer raw sensor images to an RPi or similar SBC in real time, continuously, at a minimum 0.5 Hz rate (i.e. for exposures of 2 s or longer). Higher bandwidth, permitting shorter exposures like 0.5s, would be preferred.
Do #1 with very little dead time between frames. For example, taking a 1.9s exposure every 2s is OK, but a 1.5s exposure every 2s is not OK. The temporal fill factor should be comparable to normal video, just at a much lower frame rate (and with raw sensor data on each frame).
Sensor area >= micro four-thirds format, noise performance on par with the last 10-15 years of DSLR/mirrorless cameras, and easily adaptable to cheap manual-focus lenses.
Camera capable of doing #1 and #2 without mechanical shutter actuations.
The proximate application is shooting aurora timelapse video, but I would like to set up something similar for routine all-sky surveillance and better quality than one can get with mass-market IP cameras.
Any suggestions? I’m thinking a used DSLR, but it’s hard to find good information on which ones are most suitable. My Olympus E-PL7 is not up to the task (too much dead time), and anyway, I’d rather keep it as a carry camera and put together something else on the roof.
It’s a long time back, and it isn’t something I know too much (OK, anything) about. However, I was once in a discussion on astro-modified cameras. They are a thing, and available from a number of vendors.
Does anyone know which DSLRs of 2010+ vintage featured an electronic shutter? That might be a good place to begin. I read somewhere that Nikons sometimes had electronic shutter, while Canons did not.
Alternatively, does anyone know what would happen if you just disabled and removed the shutter from a DSLR? Couldn’t you still use it at night successfully? I wouldn’t think the electrons accumulated during the read-out process would be significant, but I am not expert on image-sensor physics.
Another option is one of the ZWO cameras with an adapted lens. But I think one can get better sensor performance per $$ spent with a used DSLR. Only question is whether one can abuse it sufficiently with gphoto, etc. to achieve the desired ends.
gphoto may not live up to your “real time” expectations. I have not used it in years, but it may be limited to MTP (or PTP) on the wire. I always found those protocols slow. gphoto may also imply a file write/read cycle at the camera end, involving the memory card.
I never coded for tethered “consumer” cameras and can not advice on the matter, but you may want a camera that can feed raw files or even raw pixel values directly from camera buffer memory.
You may be able to find a budget priced second hand “industrial” camera. Especially if you can compromise a bit on sensor size. Don’t forget to account for additional modules required for a functional rig.
I think you should draw yourself a detailed time-line from the end of camera exposure period to raw image data written to storage in the receiving end.
Thanks for the gphoto2 issue link. That is a bit disappointing. I actually have a similar camera on coming soon for testing (a used Canon T7 aka 2000D) and have been told that it can expose and transfer at the same time (from RAM in the camera). Supposedly near-continuous 2s exposures are doable with continuous data flow. We’ll see.
With slightly longer exposures, it would be feasible to fill up a 256 or 512 GB card every night and download/process the images in the morning (using an automated pipeline, of course!). But I don’t know how long a typical memory card can take that kind of abuse.