Please read the first post. 10 second exposures maximum (0.1 to 15 fps at full 8MP resolution).kolban wrote:Are there any specifications on manual exposure? I'm specifically interested in how long I can expose an image for astro-photography.
No software method, just both cameras aimed at the same high-speed binary counter.6by9 wrote:I'm guessing you had to use external kit to measure the difference, rather than reading the offset from any software. Let me know if not as it'd save me some effort.
Thanks. I can probably grab an exposure time calibration device to check, or more likely hack the firmware to log frame start interrupt timesedzieba wrote:No software method, just both cameras aimed at the same high-speed binary counter.6by9 wrote:I'm guessing you had to use external kit to measure the difference, rather than reading the offset from any software. Let me know if not as it'd save me some effort.
Fixed if you "sudo rpi-update" (note that will get 4.4 kernel, so only do it on non-critical systems)6by9 wrote:See viewtopic.php?f=43&t=145980 - yes a bug.UKSecretBases wrote:It would seem this is indeed a bug.UKSecretBases wrote:I’ve just received my v2.1 cameras (one each of the normal and Noir models). I realise I have to wait for the new libraries to roll out, in order to get the extra pixels. But I’ve noticed that the default image is horizontally flipped and the image is in reverse. So to bring it back to normal I have to use the -hf option. Bug?
I'm bemused how nobody spotted the fact that the image was reversed on the new 8MP camera board before it was bulk shipped to RS Components et al.
Surely it was tested before shipping? Given that all my Pi software and firmware was already up to date and I was simply dropping in the replacement camera board instead of the one I already had, it should have exhibited identical behaviour, except obviously the difference in pixels and field of view, etc.
I have bad recollections from the days of Clive Sinclair and the QL.
What does the tuner do? Is this tuner the thing that mess with sensor gains? If it is, it would be awesome to be able do disable it.6by9 wrote: One part that we know needs work is optimising the tuner code. After each frame the resulting statistics are analysed and update the values to be used for the next frame. That processing is currently taking a good few milliseconds. When running at 90fps, there's only 11ms for each frame, so with the ISP now taking slightly more time due to the increased number of pixels, things are going to be getting very tight! At high framerates we'll be looking to run the tuner every other frame - Naush has said he will look into that, otherwise I will.
Going off-topic, so limiting this to one response on this thread.ivannaz wrote:What does the tuner do? Is this tuner the thing that mess with sensor gains? If it is, it would be awesome to be able do disable it.
For a few imaging applications, all one needs is manually specifying a time. And aperture, but that is fixed.
Perhaps some sensor gain, if one wants something similar to "bigger ISO". And that's it.
If the image then gets too dark, it is because it is dark for the current settings. And this can be a nice information to have; not only "is dark", but how much dark it is. Now this information is lost because when it is dark in the whole frame the sensor increases the gain automatically. And when suddenly the light comes back to normal, we loose a few frames with the saturated output until normalizing again.
I've now had a squint at the datasheet. In the block diagram there is a "3D Control" block with a single pin that can electrically be either input or output. To my mind that is going to be some form of master/slave synchronisation control, but I can't see anywhere else in the document that references it with details of how to configure it.6by9 wrote:There are no exposed options for synchronisation. I've asked those with datasheets for a nosy about what external sync options are available, but that is the spec of the sensor silicon, not necessarily the packaging that is in use. Certainly it is not a signal that is brought back to the Pi.edzieba wrote:One issue with the previous camera module was that frame capture on multiple cameras could not be synchronized, which made many dual-camera uses impractical or impossible (e.g. stereo camera object tracking with the compute module). Is this a function the new module can perform?
Do you know if the Picamera python library will work out of the box ?
Thanks for the horizontal flip fix. I have updated firmware and can now get the new raspistill 3280x2464.6by9 wrote:
There are some features still in progress, but the basics are:
- Sony IMX219 8MPix sensor.
- Fixed lens.
- Various readout modes defined off the sensor. I haven't been directly involved in these, but reading out from the driver source, these are in order:
- 1280x720 binned and cropped up to 60fps.
- 1280x720 binned(? may be skipping) and cropped, at 60-120 fps. Please note that the H264 encoder will not be able to consume video at above 720P60, although we're looking into where the limit actually sits. Currently the codec will enforce a max of level 4, which is 720P at max 68.3fps (see https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels). I'm not expecting to be able to claim 4.2 and 720P145 even with mega overclocking, but we'll try to push the limits.
- 1080P cropped up to 30fps.
- 1640x1232 full FOV binned mode, up to 30fps.
- 3280x2464 full FOV, allegedly 0.1fps to 15fps. (Yes, that in theory means 10second exposures).
- Firmware has supported the sensor for a while, but there have been updates in the last couple of days. Raspistill app and V4L2 driver have been updated to ask the GPU what the max sensor resolution is and set default/max resolutions appropriately - source repos are both updated.
The post I'm seeing says " 3280x2464 full FOV, allegedly 0.1fps to 15fps"UKSecretBases wrote:You say in your OP that 3280x2464 video can be captured full FOV at up to 15fps and 1640x1232 at 30fps. But the raspivid command is still limiting the -w and -h values to 1920,1080.
The H264 codec has always been limited to a maximum width of 2048 - not going to change. I've not tried it, but MJPEG may be able to cope with [email protected],UKSecretBases wrote:You say in your OP that 3280x2464 video can be captured full FOV at up to 15fps and 1640x1232 at 30fps. But the raspivid command is still limiting the -w and -h values to 1920,1080.
Have I misunderstood completely, or do I just have to wait for more firmware updates?
8MPix images take up more memory. You'd have to ask waveform80 as the author of Picamera about the setup and memory usage. It will depend on how many output streams and things you're requesting, so there probably isn't a straightforward answer..scott_pdp wrote:I use a python script using picamera with the current 5MP camera on an A+ (256MB). I would love to upgrade my projects to the 8MP cameras, but can anyone tell me if I'll need to adjust the memory split or if I can expect a performance hit because I'm capturing more data? I know the A+ (512MB) is coming and I'm anxious for a Model 3A, but I have what I have and my projects will be given as gifts. So, more megapixels is good, but slower shot to shot performance would be bad. Anyone using a new camera with an A+? What split are you using?!
I've listed the readout modes configured off the sensor. The ISP hardware in the SoC will crop and scale any input resolution to any output resolution, maintaining aspect ratio.sorbonne wrote:Will 1632x1232 or 1664x1232 give ~FOV binned mode?
Read it as "I personally haven't tried it, but that's what the driver advertises". Naush (also ex Broadcom and has done most of this driver and tuning) has said he has had 10second exposures, however that is possibly from a lower level test app than raspistill.jbeale wrote:The post I'm seeing says " 3280x2464 full FOV, allegedly 0.1fps to 15fps"
I interpret "allegedly" as "claimed possible by hardware, but as yet unsupported / untested in practice"
Also I didn't see this explicitly claimed as a video mode. With the older sensor anyway, 2 fps was the slowest H.264-output video mode possible, any longer exposure required still frame output.
Code: Select all
./build/bin/raspividyuv -w 3280 -h 2464 -o /dev/null -t 100000 -fps 5 -ss 2000000 -n
I did test out long exposure (upto 10s) through raspistill, but not raspivid or raspividyuv.Read it as "I personally haven't tried it, but that's what the driver advertises". Naush (also ex Broadcom and has done most of this driver and tuning) has said he has had 10second exposures, however that is possibly from a lower level test app than raspistill.
It is listed as working as both a stills and video mode.
With raspistill, there was a difference between 10 or 15 seconds which amazed me!naushir wrote: I did test out long exposure (upto 10s) through raspistill, but not raspivid or raspividyuv.
3200 iso, 15secs?? What are the new limits?Koepi wrote:With raspistill, there was a difference between 10 or 15 seconds which amazed me!naushir wrote: I did test out long exposure (upto 10s) through raspistill, but not raspivid or raspividyuv.
raspistill -ISO 3200 -ev 18 -ss 1500000 -t 1 -n -q 82 -ex night -drc high -w 1920 -h 1080 -o $FILE
You asked for it! https://www.youtube.com/watch?v=RkEXGgdqMz8gordon77 wrote: 3200 iso, 15secs?? What are the new limits?