User avatar
kolban
Posts: 143
Joined: Fri Dec 04, 2015 1:45 am
Location: Texas, USA

Re: New 8MP Camera - Q&A thread

Wed Apr 27, 2016 6:26 am

Are there any specifications on manual exposure? I'm specifically interested in how long I can expose an image for astro-photography.
FREE book on Raspberry Pi usage and programming

https://leanpub.com/pi

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6683
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: New 8MP Camera - Q&A thread

Wed Apr 27, 2016 6:47 am

kolban wrote:Are there any specifications on manual exposure? I'm specifically interested in how long I can expose an image for astro-photography.
Please read the first post. 10 second exposures maximum (0.1 to 15 fps at full 8MP resolution).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

edzieba
Posts: 25
Joined: Fri Jul 29, 2011 6:59 pm

Re: New 8MP Camera - Q&A thread

Wed Apr 27, 2016 10:04 am

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.
No software method, just both cameras aimed at the same high-speed binary counter.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6683
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: New 8MP Camera - Q&A thread

Wed Apr 27, 2016 11:05 am

edzieba wrote:
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.
No software method, just both cameras aimed at the same high-speed binary counter.
Thanks. I can probably grab an exposure time calibration device to check, or more likely hack the firmware to log frame start interrupt times :D

I did have a look at the code yesterday and there was one quirky thing in the config which may have slowed things down (OV5647 had a lens driver specified!). I threw a speculative change at Pi Towers to correct that but didn't have a chance to check whether it improved the time offset or not. It's been merged and released, so rpi-update would pick that up if you fancied retesting.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6683
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: New 8MP Camera - Q&A thread

Wed Apr 27, 2016 11:08 am

6by9 wrote:
UKSecretBases wrote:
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?
It would seem this is indeed a 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.
See viewtopic.php?f=43&t=145980 - yes a bug.
Fixed if you "sudo rpi-update" (note that will get 4.4 kernel, so only do it on non-critical systems)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
jbeale
Posts: 3379
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

IMX219 spectral sensitivity curves

Wed Apr 27, 2016 4:26 pm

I notice that the IMX219 description http://www.sony.net/Products/SC-HP/new_ ... 219_e.html says it has the same spectral sensitivity characteristics as the IMX111 sensor, which in turn is described here http://www.sony.net/Products/SC-HP/cx_n ... _111pq.pdf including the sensitivity plots, which I have excerpted below (IMX111 / IMX219 is the solid lines). OmniVision never published equivalent data for their OV5647 as far as I know, so for the first time, we actually know this information for a RPi camera. It seems the three colors are normalized separately, so the absolute response, and the sensitivity beyond 400-700 nm is still left as an exercise for the reader.

Image

ivannaz
Posts: 13
Joined: Fri May 22, 2015 7:42 pm

Re: New 8MP Camera - Q&A thread

Wed Apr 27, 2016 9:30 pm

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.
VGA90.
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.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6683
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: New 8MP Camera - Q&A thread

Wed Apr 27, 2016 10:11 pm

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.
Going off-topic, so limiting this to one response on this thread.
I hope you've got a few years to dedicate to writing your own then. The tuner is dealing with not just exposure and gain control, but white balance, lens shading, denoising, colour conversion matrices, demosaicing, false colour correction, distortion correction, chrominance stretch, defective pixel correction, dynamic range compression, and sharpening. Also the outside world doesn't get access to any of the statistics that are produced by the hardware, so you'd be having to recreate them when you potentially haven't got the required data to recreate it for yourself.

You already have the option to specify a manual exposure time and ISO (gain) anyway (raspistill/vid options -ss and -iso). And if you want to know the exposure time and gains, then those can be read back, or you can get callbacks every time they change (raspistill/vid option -set). That's been true on the old sensor for quite a long time (>2 years).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6683
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: New 8MP Camera - Q&A thread

Thu Apr 28, 2016 12:29 pm

6by9 wrote:
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?
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.
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.
HOWEVER, it seems that that signal is not brought down the small flexi from the sensor itself to the Pi camera board, so there is no opportunity to do any form of hacking on it. It'll be tied to ground underneath the sensor itself.

If it's like Omnivision, Sony only make the sensor and others make the flexi to mount the sensor on and sell the combined bundle. There may be other companies that do bring this signal down, but for now it is a dead-end on the Pi camera module.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Romuald
Posts: 6
Joined: Sun Jan 31, 2016 12:51 pm

Re: New 8MP Camera - Q&A thread

Thu Apr 28, 2016 2:51 pm

Hello,

Do you know if the Picamera python library will work out of the box ?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6683
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: New 8MP Camera - Q&A thread

Thu Apr 28, 2016 2:59 pm

Romuald wrote:Hello,

Do you know if the Picamera python library will work out of the box ?
viewtopic.php?f=43&t=145815#p960956
https://github.com/waveform80/picamera/issues/278
Yes, although potentially only up to 5MP.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

UKSecretBases
Posts: 5
Joined: Tue Apr 26, 2016 5:03 pm
Contact: Website

Re: New 8MP Camera - Q&A thread

Thu Apr 28, 2016 3:43 pm

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.
Thanks for the horizontal flip fix. I have updated firmware and can now get the new raspistill 3280x2464.

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?

User avatar
scott_pdp
Posts: 15
Joined: Thu Apr 30, 2015 1:12 pm
Location: Port-de-Paix, Haiti

Re: New 8MP Camera - Q&A thread

Thu Apr 28, 2016 5:15 pm

My apologies if this question is too far off topic.

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?

Thanks!

sorbonne
Posts: 49
Joined: Thu Jan 14, 2016 10:25 am

Re: New 8MP Camera - Q&A thread

Thu Apr 28, 2016 5:33 pm

6by9 wrote: - 1640x1232 full FOV binned mode, up to 30fps.
Will 1632x1232 or 1664x1232 give ~FOV binned mode?

User avatar
jbeale
Posts: 3379
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: New 8MP Camera - Q&A thread

Thu Apr 28, 2016 5:38 pm

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 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.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6683
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: New 8MP Camera - Q&A thread

Thu Apr 28, 2016 8:33 pm

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?
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],
V4L2 and raspividyuv have both been able to produce 5MP15 as I420 for about 2 years (need to add "max_video_width=2592 max_video_height=1944" to the module config).
I'll fire up a system in a moment and see what results I get from v4l2-ctl at 8MPix.

edit Tried and get 11fps streaming 8MP as I420 via V4L2 to /dev/null. The sensor itself appears to be framing at the correct rate as selecting 10fps does give 10fps. A comment was made today over resource contention, so my first guess is that it is what is limiting things with the format conversion. There is an optimisation that can be done with raspi[still|vid|vidyuv] that may make a difference, so it's another to add to the list of things to check.

edit2 Just tried with raspividyuv and get a nice solid 15fps (66ms between frames), although I did have to up gpu_mem to 192MB. "raspividyuv -w 3280 -h 2464 -o /dev/null -t 10000 -fps 15 -n".
It's slightly curious that that is better than V4L2 as that normally does less, but that could be due to a number of things.
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?!
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..
Run your script on your current camera, and use "sudo vcdbg reloc" whilst it is running to show the buffers allocated. Any that are correctly sized for 5MP (and they could be 10bpp, 12bpp, 16bpp, 24bpp, or 32bpp), increase them to 8MP resolutions. Does that fit within the free memory listed?
sorbonne wrote:Will 1632x1232 or 1664x1232 give ~FOV binned mode?
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.
Both of those resolutions will almost certainly select the 1640x1232 binned full FOV mode. I assume you've rounded the width up/down to a multiple of 32 due to misunderstanding the buffer requirements. Please search the forums for the difference between the buffer sizing and line stride/pitch, vs the active resolution within that buffer.
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.
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.
I'm not sure where you got 2fps being the minimum frame rate. It shouldn't be, although I haven't the foggiest what the bitrate control will do. Yet another thing to try. I do vaguely recall James referring to only getting 2fps working, but I think that was before the long exposure mode was added. You do need to have specified a manual exposure time to get > 1s.

edit Seeing as I had raspividyuv working, just tried "./build/bin/raspividyuv -w 3280 -h 2464 -o /dev/null -t 10000 -fps 1 -ss 1000000 -n" and get 999971usecs between frames.
Hack the code to divide the framerate provided by 10 (because it is only reading it as an integer - change VIDEO_FRAME_RATE_DEN from 1 to 10), and run

Code: Select all

./build/bin/raspividyuv -w 3280 -h 2464 -o /dev/null -t 100000 -fps 5 -ss 2000000 -n
and I get 1951220us between frames (0.5fps).
Requesting >0.3s did give me a timeout, so there is something wrong either with my hacks or the driver. Setting a short exposure time and slow framerate also seemed to fail, so I think I'd missed something in my hacks.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
jbeale
Posts: 3379
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: New 8MP Camera - Q&A thread

Fri Apr 29, 2016 12:08 am

Thanks for all the good info 6by9. I was only remembering this comment from JamesH back in May 2013:
viewtopic.php?t=43825&p=349527#p349585
"raspivid -t 1000000 -fps 2 -o fastmo.h264
OK, it's 2fps, which is a sort of timelapse...I've not got it to go below 2fps yet"

fannta
Posts: 2
Joined: Fri Apr 29, 2016 4:52 am

Re: New 8MP Camera - Q&A thread

Fri Apr 29, 2016 5:08 am

First a very big hello to all forum members from an absolute newbie, this actually is my very first post here 8-)

I have heard of the Raspberry Pi before but the new camera module info just got me. The specification of the Sony IMX219 imager used allow for full angle and FOV readout @30 fps (@8MP!!)

As I aboslutely have no experience with the Pi there are a few question before I jump on to a Pi with the new camera module:

- in combination with the Pi 3 board can you achieve 30FPS readout @8MP ?
- is the Pi 3 capable of dumping the data to a storage (SD/SSD?)
- how long can the 30FPS maintained (bottle neck?)

All questions are with regards to photo mode.

Basically what I am interested in is whether the PI is capable of maintaining/achieving 30fps photo capture @8Mp.

Cheers

naushir
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 10
Joined: Mon Apr 25, 2016 10:21 am

Re: New 8MP Camera - Q&A thread

Fri Apr 29, 2016 5:13 am

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.
I did test out long exposure (upto 10s) through raspistill, but not raspivid or raspividyuv.

Koepi
Posts: 65
Joined: Fri Apr 29, 2016 7:18 am

Re: New 8MP Camera - Q&A thread

Fri Apr 29, 2016 7:24 am

Serious mess-up the new drivers are! (c)Yoda.
A little bit dissapointing.

Unsharp on the left side:
http://www.pic-upload.de/view-30493651/ ... 8.jpg.html

Then the night came. I could tweak the raspistill-call to give a really nice and decent result.

Then the sun rose ...
http://www.pic-upload.de/view-30498036/ ... 9.jpg.html

No tweaking helps. Setting -ev to -4 for example makes the image just darker, no gain in details/exposure correction.
Call: raspistill -mm matrix -n -t 1 -q 82 -w 1920 -h 1080 -o $FILE
Other measurement metrics gave even worse results.

If i were into art, I could make Warhol-like pop art:
http://www.pic-upload.de/view-30498254/ ... t.jpg.html

Just in comparison how well the old OV5647 coped with exactly the same light situation:
http://www.pic-upload.de/view-30498065/ ... 5.jpg.html

I hope there is a simple switch which would help me getting nicer results. In the sun, the image is overexposed. When it's a bit darker due to clouds and rain, the image gets quite dark. If the sun comes from front, it's just shapes in front of light what ends up in the jpeg. Only in the night it's usable a bit ....

Edit: Just for reference - that should look like blue sky mostly - as you can see from the luminosity curve, no clouds ...
http://www.pic-upload.de/view-30498589/ ... y.png.html
Last edited by Koepi on Fri Apr 29, 2016 8:13 am, edited 3 times in total.

Koepi
Posts: 65
Joined: Fri Apr 29, 2016 7:18 am

Re: New 8MP Camera - Q&A thread

Fri Apr 29, 2016 7:28 am

naushir wrote: I did test out long exposure (upto 10s) through raspistill, but not raspivid or raspividyuv.
With raspistill, there was a difference between 10 or 15 seconds which amazed me!

raspistill -ISO 3200 -ev 18 -ss 1500000 -t 1 -n -q 82 -ex night -drc high -w 1920 -h 1080 -o $FILE

mvdswaluw
Posts: 1
Joined: Thu Jun 13, 2013 12:43 pm

Re: New 8MP Camera - Q&A thread

Fri Apr 29, 2016 8:07 am

Will roi via v4l2 be supported for the new camera?

gordon77
Posts: 3912
Joined: Sun Aug 05, 2012 3:12 pm

Re: New 8MP Camera - Q&A thread

Fri Apr 29, 2016 8:19 am

Koepi wrote:
naushir wrote: I did test out long exposure (upto 10s) through raspistill, but not raspivid or raspividyuv.
With raspistill, there was a difference between 10 or 15 seconds which amazed me!

raspistill -ISO 3200 -ev 18 -ss 1500000 -t 1 -n -q 82 -ex night -drc high -w 1920 -h 1080 -o $FILE
3200 iso, 15secs?? What are the new limits?

Koepi
Posts: 65
Joined: Fri Apr 29, 2016 7:18 am

Re: New 8MP Camera - Q&A thread

Fri Apr 29, 2016 8:46 am

gordon77 wrote: 3200 iso, 15secs?? What are the new limits?
You asked for it! ;) https://www.youtube.com/watch?v=RkEXGgdqMz8

Seriously though, the limit should be at 10s and ISO800 for manual settings. It made a difference on the resulting image though.
Also mind that contrary to the microseconds the SS parameter takes, this should result in 1.5s instead of 15s shutter. The command prompt vanishes for 15s though, so the parameter does offer 15s this way.
Maybe the specs are updated in the driver from yesterday. Somehow apt-get upgrade bumped my kernel back to 4.1 two days ago; did a rpi-update yesterday again and got the 4.4.8-kernel. Now sudo apt-get [update|upgrade|dist-upgrade] shows everything is up-to-date.

GeeTee
Posts: 10
Joined: Thu Oct 18, 2012 11:45 am

Re: New 8MP Camera - Q&A thread

Fri Apr 29, 2016 10:43 am

Hi guys,
Excellent work with the new camera board.

A couple of findings. I first mounted the camera on a Pibow Camera Mount. Although the Board size is the same, and the mounting holes. the new lens mount is actually slightly larger than the previous version, so the camera did not fit in the case. I managed to tighten the bolts, carefully. However my images had a lack of sharpness in them on the right hand side. After a mail to the case supplier they suggested filing out the central hole to mount the camera. I also, read a comment that if the board is flexed it can distort images. I must of forgotten this because I never experienced it with the V1.3 camera board.

I filed out the hole on the camera case mount and the camera now fits in ok. I used some nuts as spacers to ensure that the camera is held off the board at the same distance round each of the 4 pegs.

This immediately solved the problem of lack of sharpness in the images, so if you have a lack of sharpness in your images check for stress on the board. I think the new board is more sensitive to flex and stress than the old one, or maybe just the sensor. NB. I was v. careful in affixing it the first time. (I hope I haven't damaged it - appears not.)

I am still working my way through my other camera mounts, so see which is giving the best results with the various lenses that I have. My SmartiPi camera case is not giving good results, which is a shame.

Initial observations are that the v2 camera is producing much better 'real world' results than than the v1.2 (Doh!) The increase in frame size is a noticeable benefit. The low light performance is far superior. The colours on the video look so much better, but I have done very little with video so far. I did notice what I thought was fast playback! I am using a Pi 3, and I thought my video was playing back faster than real time. I will record more video and report back if that is the case.

It is early days for the drivers so as with all things Pi, it is good now, and will only get better :)

Thanks guys, keep up the good work.

Return to “Camera board”