viewtopic.php?t=190314Kozuch wrote: ↑Fri Apr 13, 2018 1:40 pmDo I understand this correctly that with some sort of setting ("disable_camera_led=3") and a setup described above one can get a GPIO signal when a frame exposure starts? Does this work only with still capture more or also in video (sensor running freely) mode (still/video MMAL ports)?
As 6by9 explained (read the linked info) you can't use strobbed illumination with the rolling shutter at shutter times shorter than the full frame time. If you try you will only illuminate some strip of lines. The scan lines expose at different times. This is nothing like a film camera or gloabl shutter sensorInsurmountable wrote: ↑Tue Apr 03, 2018 5:41 pmYes it seems to work better just using the Camera LED signal to switch the FET directly on and off. When you do as I have done you get a small band at the top of the picture which is the delay in switching on the FET using my python code. I will put a scope on it tomorrow and see what the differences are between the two methods.
The reason I did it this way was I wanted to have better control of the lights on time, if you drive directly from the camera LED signal then you always switch the lights off when the last frame is received regardless of the shutter time but it seems that at high shutter speeds this is practically one and the same.
Insurmountable wrote: ↑Fri Apr 13, 2018 7:15 pmI am using this for a Computer Vision project, the results I am getting do have banding so you could never use it for film or TV but considering I am capturing images of stuff moving fast in total darkness, the results are great and I have achieved what everyone else said you need a physical shutter to do.As 6by9 explained (read the linked info) you can't use strobbed illumination with the rolling shutter at shutter times shorter than the full frame time. If you try you will only illuminate some strip of lines. The scan lines expose at different times. This is nothing like a film camera or gloabl shutter sensor
And you didn't say anything about how you were using the images or how you were compensating for rolling shutter effects.If the exposure time of the camera is 1ms then it should only need the lights to be on for 1ms not 15ms.
??! Neither Pi cameras are CCD, they're both CMOS based. Both have exposure control (time between resetting the line and reading it out) and gain control.
It really is exposure time. It's just that each line of the image exposes at a different time,, one after the other, but each line exposes (gathers light) for the specified exposure time. Gain is something else entirely.
That is a challenge. One limitation in using an SLR lens with a Pi camera is the size of the pixels / the resolution of the projected image. An SLR/DSLR has a large photo sensitive area and doesn't need such high resolution to get nice sharp results. The pixels on the Pi sensors are very small beyond the limit of resolution of most lenses. Any large format lens that is properly matched to those sensors will be relatively expensive.Insurmountable wrote: ↑Sun Apr 15, 2018 9:29 pm
Also you can get a zillion different hi-quality camera lens on gumtree or craigslist for less than $100 while hi quality CCTV lens are expensive and because of their size don't let in enough light. You want to try and get lens that are NOT full format, if you do use one then your picture will be zoomed in like a 1000 times and you will have a very narrow field of view.
Insurmountable wrote: ↑Sun Apr 15, 2018 11:19 pmHere is one of my freeze motion shots, taken from the shore.Are you trying to freeze motion? It doesn't look like anything is moving in the image from the Pi camera with LED lighting.
I was asking about whether you were using strobbed LEDs to freeze motion, which is where rolling shutter gest particularly problematic.
Any motion will result in some distortion but it's not noticeable in most scenes and slow speeds. As you know it gest obvious with fast moving edges like propellers. You can't use a strobe to get a freeze-frame image of a propeller on a rolling shutter sensor.
I'm no expert on CCDs hence surmised from your comment that there could be a limitation where they couldn't control exposure time. I'd be surprised as exposure time gives a significantly greater degree of control over the amount of light sensed than gain does.
Have a read through https://picamera.readthedocs.io/en/latest/fov.html for a decent description of how the sensors implement rolling shutter with exposure time.Insurmountable wrote:Yeah I was wondering how it would be possible to implement using gain, I figured it was something akin to switching the power on then off to achieve. The reason why companies like FaceBook and Apple make so much money is the inability of todays computer engineers to make manuals that make sense. When I had my BBC model B in the 80s there was no Internet, no one to ask, I had a few manuals which explained everything in detail and that was that, never needed to ask anyone anything. Look it up in the manual which would say stuff like this command causes the CPU to first set these registers to this then these lines to that, it literally told you how it worked, these days manuals attempt to simplify stuff and fail miserably.It really is exposure time. It's just that each line of the image exposes at a different time,, one after the other, but each line exposes (gathers light) for the specified exposure time. Gain is something else entirely.
Er, try -ag and -dg in raspistill/vid to explicitly set analogue and digital gains, and -ss to set the shutter speed. (NB omit any of those and the automatic algorithm will be adjusting those controls to try and achieve what it sees as correctly exposed).Insurmountable wrote:A good point is how it is seemingly impossible to set the Pi camera into manual mode, any adjustments are made using whatever the last automatic settings produced, you cant say take a picture with this ISO and then add 2 stops of extra exposure, if you tell it to increase the exposure by 2 stops then it takes the last automatically obtained exposure setting and adds 2 stops to that. like WTF? do these guys even do photography?
Frame rate is more significant than exposure time. The fastest I've seen the current Pi camera run in 665fps which is 5.5ms but unless you are setting the frame rate you will have the standard 60fps 16.7ms or 30fps 33.4ms. Of course frame rate and exposure time are related
Huh? What's your definition of frame rate vs effective frame rate then?Insurmountable wrote: ↑Wed Apr 18, 2018 9:00 pmThere you go, frame rate is not actually frame rate but effective frame rate.Frame rate is more significant than exposure time. The fastest I've seen the current Pi camera run in 665fps which is 5.5ms but unless you are setting the frame rate you will have the standard 60fps 16.7ms or 30fps 33.4ms. Of course frame rate and exposure time are related
The camera board has a 25MHz oscillator on it. The sensor then has PLLs and divsors to increase that to a requested pixel clock rate, as programmed via a large number of I2C writes when you start using it. The sensor manufacturers will specify various maximum values for PLL settings and pixel rates. Feel free to delve into those register sets, but be aware that they frequently defy logic.Insurmountable wrote: ↑Wed Apr 18, 2018 9:22 pmAnother option would be to use the Asus Tinker SBC instead of a Pi, I see they work with the Pi Camera. Anyone any idea on what the actual frame rate they can read from the camera is? The new updated version is meant to be stupid fast at processing video. Can you overclock the Pi camera? does the camera set the data transfer rate or the Pi ?