User avatar
Gavinmc42
Posts: 4062
Joined: Wed Aug 28, 2013 3:31 am

Re: New 8MP Camera - Q&A thread

Sun May 15, 2016 4:43 am

Just did the this on a V2,
raspistill -w 3280 -h 2464 -o testv2-2.jpg
raspistill -o testv2-3.jpg

Interestingly the first image is more blurred.
Never done RAW images before, reading up on the forums.

Won't be able to get best focus if raspistill jpg is blurring things.
V2 jpgs are not much bigger than the V1's, I would have expected a larger difference.

Real digital photo guys use RAW because the post processing software on a PC usually has better algorithms than the camera ISP.
Are we expecting too much of the GPU?

Has anyone checked the RAW from a V2?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
Gavinmc42
Posts: 4062
Joined: Wed Aug 28, 2013 3:31 am

Re: New 8MP Camera - Q&A thread

Sun May 15, 2016 5:30 am

Just did raspistill --raw -o testv2-5.raw

Using ImageMagick on a Linux Box I can see the RAW data is much better than the jpg.
ImageMagick takes the RAW files no problem.
Best image from a V2 so far, now I know why pro's use RAW.

Now to compare it to a RAW from a V1.
Rats, V1 RAW is much better.
Focus needs more tuning on the V2?
Time to swap lens?
Losing the light, next weekend- focus, focus.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
Gavinmc42
Posts: 4062
Joined: Wed Aug 28, 2013 3:31 am

Re: New 8MP Camera - Q&A thread

Sun May 15, 2016 6:03 am

Quick test swapping lens.
Not properly focused, but first impression V1 lens is better than V2 lens.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
Gavinmc42
Posts: 4062
Joined: Wed Aug 28, 2013 3:31 am

Re: New 8MP Camera - Q&A thread

Sun May 15, 2016 6:45 am

Wonder what a V2 lens on V1 camera looks like.

Thread getting very hard to turn, it is now a wide angle macro V1 camera 10mm focus with 0.5mm DOF.
Worn out my credit card spanner.

For security use, a V2 lens on a V1?
For good images V1 lens on V2?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

pootle
Posts: 340
Joined: Wed Sep 04, 2013 10:20 am
Location: Staffordshire
Contact: Website

Re: New 8MP Camera - Q&A thread

Sun May 15, 2016 9:50 am

jbeale wrote:@pootle - your link gives me 404 Not Found.
Argh! flickr changed my settings - should be OK now - I've edited the post and
https://flic.kr/s/aHskwxMJTM

User avatar
Gavinmc42
Posts: 4062
Joined: Wed Aug 28, 2013 3:31 am

Re: New 8MP Camera - Q&A thread

Sun May 15, 2016 10:48 am

What lens did you use on that last one, very clear?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

pootle
Posts: 340
Joined: Wed Sep 04, 2013 10:20 am
Location: Staffordshire
Contact: Website

Re: New 8MP Camera - Q&A thread

Sun May 15, 2016 11:50 am

Gavinmc42 wrote:What lens did you use on that last one, very clear?
All 3 are the same Canon 70-200 F2.8 L, the last one used a 7D instead of the pi camera - the pi looks soft 'cos I hadn't properly light sealed it......

David Crawley
Posts: 5
Joined: Thu Apr 21, 2016 4:07 pm

Re: New 8MP Camera - Q&A thread

Sun May 15, 2016 6:20 pm

Unless by blur you mean rolling-shutter artifacts (vertical features moving sideways become diagonal). If you know your velocity, you can correct that with a software de-skew.
jbeale has already correctly stated that exposure time is the main factor on motion blur.
We suffer both from motion blur and rolling shutter artefacts.

Perhaps I am missing something here. The way that we got shorter exposure times is to use a high frame rate mode at low resolution. We dump most of the images because our image processing pipe can only handle about 5 fps on the pi. We don't need particularly high resolution, but we do need wide field of view - so center cropping is problematic for us. At the speeds that we'd like to operate at the shutter speed is limited by download rate of the link - hence the desire for low resolution but fast images. Is there a more intelligent way to do this? Perhaps you'll tell me that I should either:

1) Take 1280x720 binned and cropped up to 60fps. - live with the narrower FOV - I don't understand the binning scheme here but experiments will likely reveal whether it will work.

2) Take 1640x1232 full FOV binned mode, up to 30fps. and make them work. my sense is that as 72fps just about works now 60fps is likely to work, 30fps is likely not to. We might be able to improve performance at 30fps by experimenting with exposure times eg following viewtopic.php?t=48853&p=381189

As to correcting for motion blur. - This actually could be problematic as we use the images to tell how fast we are going. There are other problems with this too namely you don't actually know how far away the fiducial markers are until you process the image etc. However our robot does have other sources of data on how fast its going - they just aren't as reliable nor as good as our "optical odometery" method.

3) Do ABC to get wide field of view images at low resolution with high frame rate. Of course we'd love full FOV with binning to get to a higher frame rate, but I don't know if that is supported, practical, reasonable. I don't know if it ever will be.

4) Some other option.
Last edited by David Crawley on Sun May 15, 2016 6:45 pm, edited 1 time in total.

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

Re: New 8MP Camera - Q&A thread

Sun May 15, 2016 6:39 pm

David Crawley wrote:Perhaps I am missing something here. The way that we got shorter exposure times is to use a high frame rate mode at low resolution. We dump most of the images because our image processing pipe can only handle about 5 fps on the pi.
OK, well I'd say you are missing the shutter speed parameter, the -ss option. The parameter is in microseconds, so for example
raspivid -ss 5000
sets a 5 millisecond exposure time. If rolling-shutter skew is a problem, you might try turning the camera 90 degrees. That might fix skew almost completely, unless your robot moves fast up and down as well as horizontally. (however, instead of skew you get compression or extension, depending which way you travel relative to the camera scan direction.)

David Crawley
Posts: 5
Joined: Thu Apr 21, 2016 4:07 pm

Re: New 8MP Camera - Q&A thread

Sun May 15, 2016 6:48 pm

jbeale wrote:
David Crawley wrote:Perhaps I am missing something here. The way that we got shorter exposure times is to use a high frame rate mode at low resolution. We dump most of the images because our image processing pipe can only handle about 5 fps on the pi.
OK, well I'd say you are missing the shutter speed parameter, the -ss option. The parameter is in microseconds, so for example
raspivid -ss 5000
sets a 5 millisecond exposure time. If rolling-shutter skew is a problem, you might try turning the camera 90 degrees. That might fix skew almost completely, unless your robot moves fast up and down as well as horizontally. (however, instead of skew you get compression or extension, depending which way you travel relative to the camera scan direction.)

Whoa!! you're fast!!! By the time that I realized the silliness of my original post and started to edit it you'd already replied!

David Crawley
Posts: 5
Joined: Thu Apr 21, 2016 4:07 pm

Re: New 8MP Camera - Q&A thread

Sun May 15, 2016 6:54 pm

jbeale wrote: sets a 5 millisecond exposure time. If rolling-shutter skew is a problem, you might try turning the camera 90 degrees. That might fix skew almost completely, unless your robot moves fast up and down as well as horizontally. (however, instead of skew you get compression or extension, depending which way you travel relative to the camera scan direction.)

MMMM - good thought. The robot drives along the ground and the camera is pointing up to the ceiling. The conditions that are idea for optical odometery are necessarily the exact opposite of the conditions that are idea for avoiding motion blur and rolling shutter effects. You want the camera pointing up to the ceiling because that's going to give the most accurate measurement of where you are and how fast you are going.

OK - thanks for your help - I think I have a bunch of experiments to do.

User avatar
Gavinmc42
Posts: 4062
Joined: Wed Aug 28, 2013 3:31 am

Re: New 8MP Camera - Q&A thread

Mon May 16, 2016 1:32 am

David,

I have wanted to try a fisheye pointed up on a robot and have overlayed motion vectors.
Based on results I get from this,
http://billw2.github.io/pikrellcam/pikrellcam.html
The h.264 GPU derived motion vectors look like a much faster way to do things.
It also give the robot 360 degree eyes, hemispherical vision.
Look at some 360 degree facebook/youtube videos.

For security, a 8MP with software pan, tilt, zoom with a wide angle/fisheye?

Not easy to get wide angle lens for Pi cameras, why not use a mirror.
http://www.ebay.com.au/itm/2-Car-Rearvi ... xy~ilSPAPG

In University Optical Flow research, they use standard cameras pointed at optical mirrors.
They use a lathe to make a convex/dome/parabolic/hyperbolic? lens shape from aluminum and then polish it to a mirror finish.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

lowflyer
Posts: 78
Joined: Sat Jun 01, 2013 2:27 pm

Re: New 8MP Camera - Q&A thread

Mon May 16, 2016 10:29 am

My vote for camera v2.2 is for the viscous compound to allow users to manually refocus plus a plastic focussing spanner plus the option to exchange the normal cable for a PiZero cable.

And all the same price!! And soon!

Then v2.3 should have more (better) lens options and the camera should be mounted firmly and horizontally on the PCB (to make it much easier to use M12 or DSLR lenses.

User avatar
Mettauk
Posts: 238
Joined: Mon Dec 10, 2012 12:40 pm
Location: Zarg

Re: New 8MP Camera - Q&A thread

Mon May 16, 2016 11:47 am

lowflyer wrote:My vote for camera v2.2 is for the viscous compound to allow users to manually refocus plus a plastic focussing spanner plus the option to exchange the normal cable for a PiZero cable.

And all the same price!! And soon!

Then v2.3 should have more (better) lens options and the camera should be mounted firmly and horizontally on the PCB (to make it much easier to use M12 or DSLR lenses.
Agree ish...
Camera should take fine pitch connector, be 12-18 mp with a 1/3" sensor, slightly smaller footprint, better low light sensitivity and finally cost just a few pence more.
EDIT: Oh and of course it should focus without having to be ripped apart!
As humans we have been the same for a very very long time, technology changes how we do... not who we are as people.

amuxie
Posts: 4
Joined: Wed May 18, 2016 6:34 am

imx219 fps

Wed May 18, 2016 7:06 am

hi:

my platform is pi 3 model B of bcm soc. on my screen, i don't use h264 encorder, just get YUV data from ISP. so i want to increase the fps of 1280 720, read the imx219 datasheet, it can support 1280*[email protected], how can i achieve 120fps on pi3

i use the app of raspividyuv, found it only has about 70fps, what's the problem of this case

thanks in advance!

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

Re: imx219 fps

Wed May 18, 2016 4:33 pm

amuxie wrote: i want to increase the fps of 1280 720, read the imx219 datasheet, it can support 1280*[email protected], how can i achieve 120fps on pi3
i use the app of raspividyuv, found it only has about 70fps, what's the problem of this case
The datasheet says: "1280 × 720 pixels of 16:9 aspect ratio at 180 frame/s. (Using MIPI 4Lane)"

One problem in this case is that the Raspberry Pi 3 exposes only a 2-Lane MIPI bus, so modes that require 4-Lane MIPI cannot be supported. The other is the maximum throughput of the SoC Videocore which I think supports only MPEG4 level 4.1, which maxes out around 720p68 and that is well short of 720p180. If you don't use h.264 and only YUV, the limitation I suspect is datarate between GPU and ARM.

See also: https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7572
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 May 18, 2016 5:02 pm

There's an update :) - I'll update the first post when I get home.

With the latest Raspbian release and rpi-update, the modes have been reordered to match OV5647's as closely as possible. The cutting edge PiCamera mode list at https://media.readthedocs.org/pdf/picam ... camera.pdf section 2.6.1 is now correct.

The H264 encoder has had the level 4.0 constraint relaxed to allow setting of up to 4.2. It will NOT achieve 720P145, but with overclocking >100 is looking plausible. The sensor will frame at up to 720P120 now, but again needs a small overclock to allow processing of those frames, and it is a cropped FOV. Naush has had 720P120 with H264 encoding on a Pi3, whilst my Pi2 was struggling above about 720P105. It does require some extra buffering to be allocated.

We only have 2 CSI2 lanes exposed on the Pi camera board and Pi's excluding the Compute Module, so that is about the limit of what can be achieved.

There's a mod to all the raspicam apps I've been meaning to do for quite a while which removes a memcpy from the processing path. That would help out if you're after just the YUV data.

Think that's the headlines for now. I'll update later.

edit: Update of first post done.
Last edited by 6by9 on Thu May 19, 2016 9:06 am, edited 1 time in total.
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.

9aed
Posts: 17
Joined: Wed Sep 24, 2014 11:49 pm

Re: New 8MP Camera - Q&A thread

Wed May 18, 2016 5:18 pm

New test and odd results.

tl;dr (i.e. Executive summary): Noir V2.1 angular resolution measured diagonally. Left is near, red is bad.
ready.gif
ready.gif (7.69 KiB) Viewed 7110 times
New test chart was made. No images were actually obtained, but instead the preview window was used to measure resolution. Observations were made by turning the camera and keeping target chart at place, so the distance is not from image plane, but instead from a sphere, or in this case more correctly from virtual test image circle. Performance varied between 0.51 and 1.47 milliradians over the distance covered. There has been no testing over the other diagonal.

White areas are off the chart. No resolvable targets could be seen at 8.25 meters. Also the facility at hand limited testing at this distance.

Light level, colour and source could not be kept static through testing. Measurement was also rather subjective, so there is a lot of noise, but a certain pattern can be readily observed. There are 320 measurement points, which also helps to reduce adverse effects from noise.

Oddly enough the sharpest resolution was consistently reached at the farthest reaches of the image; the corners. There is also a persistent offset of the least unresolvable area, which shows quite a remarkable asymmetrical behaviour of the lens.

The following command was used over all measured distances:

Code: Select all

for i in 0.0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 ; do echo $i ; raspistill -k -roi $i,$i,0.05,0.05 -o /dev/null -md 3 ; done
Number system was again borrowed from the idea of https://en.wikipedia.org/wiki/Preferred_number, using 24th root of 10 as base multiplier. From this it is rather easy to obtain (milli)radians by dividing the observed chart target number by distance, resulting nicely quantized values.

The following is the raw data from observations. First line is ROI indication, last number at each data line is distance. 0,0-corner is lower side at the image above.

Code: Select all

0.00  0.05  0.10  0.15  0.20  0.25  0.30  0.35  0.40  0.45  0.50  0.55  0.60  0.65  0.70  0.75  0.80  0.85  0.90  0.95

0.619 0.619 0.619 0.619 0.619 0.681 0.681 0.681 0.825 1.00  1.10  1.10  1.10  0.909 0.825 0.681 0.681 0.681 0.681 0.562  0.750
0.619 0.619 0.562 0.619 0.681 0.681 0.681 0.750 0.909 1.00  1.10  1.10  1.10  1.00  0.825 0.750 0.681 0.750 0.681 0.562  0.825
0.619 0.681 0.681 0.681 0.681 0.681 0.750 0.825 0.825 1.10  1.10  1.21  1.21  1.00  0.825 0.750 0.750 0.825 0.681 0.562  0.909
0.681 0.750 0.750 0.681 0.750 0.750 0.825 0.909 1.00  1.10  1.21  1.21  1.21  1.10  1.00  0.909 0.909 0.909 0.681 0.562  1.00
0.750 0.825 0.825 0.825 0.750 0.825 0.825 0.909 1.00  1.10  1.33  1.33  1.21  1.10  1.00  0.909 0.909 0.909 0.750 0.619  1.10
0.825 0.909 1.00  0.909 0.825 0.825 0.909 1.00  1.10  1.21  1.33  1.33  1.21  1.10  1.00  0.909 1.00  0.909 0.750 0.619  1.21

0.909 0.909 1.00  1.10  1.10  1.21  1.10  1.10  1.33  1.47  1.62  1.62  1.62  1.33  1.21  1.10  1.21  1.10  1.00  0.825  1.47
1.00  1.21  1.33  1.33  1.33  1.33  1.21  1.33  1.47  1.62  1.78  1.96  1.96  1.47  1.47  1.47  1.47  1.21  1.00  1.00   1.78
1.10  1.21  1.33  1.62  1.62  1.62  1.47  1.47  1.62  1.78  2.15  2.15  2.15  2.15  1.96  1.78  1.62  1.47  1.21  1.21   2.15
1.33  1.33  1.47  1.62  1.62  1.62  1.62  1.78  1.62  1.96  2.15  2.37  2.37  2.15  1.96  1.96  1.96  1.62  1.47  1.33   2.61
1.78  1.78  1.78  1.96  1.96  2.15  1.96  1.96  1.96  2.37  2.61  2.87  2.87  2.37  2.61  2.37  2.15  1.96  1.78  1.78   3.16
2.15  2.37  2.37  2.61  2.61  2.61  2.37  2.61  2.61  2.87  2.87  3.48  3.48  3.16  3.16  2.87  2.61  2.37  2.15  2.37   3.83
2.37  2.61  2.61  2.87  2.87  2.87  3.16  2.87  2.87  3.16  3.83  4.22  3.83  3.83  3.83  3.48  3.16  2.61  2.61  2.61   4.64
2.87  2.87  3.16  3.48  3.48  3.83  3.83  3.48  3.48  3.83  4.22  4.64  4.64  4.22  4.22  3.83  3.83  3.16  2.87  2.87   5.62
3.48  3.48  3.83  3.83  4.22  4.22  4.22  4.22  4.64  4.64  ----  ----  ----  ----  ----  4.64  4.22  3.83  3.83  3.83   6.81
4.22  4.22  4.22  4.64  ----  ----  ----  ----  ----  ----  ----  ----  ----  ----  ----  ----  ----  4.64  4.64  4.64   8.25
This is the source code for actual test chart:

Code: Select all

%!PS
% 1.10069417125 - 24th root of 10
% 1.10 1.21 1.33 1.47 1.62 1.78 1.96 2.15 2.37 2.61 2.87 3.16
% 3.48 3.83 4.22 4.64 5.11 5.62 6.19 6.81 7.50 8.25 9.09 10.0

72 25.4 div dup scale
0 setlinecap
/Courier-Bold findfont 6 scalefont setfont
1 setlinewidth

/line_target {
	gsave
	dup dup scale (     ) cvs
	newpath 0 0 moveto dup true charpath flattenpath pathbbox
	pop exch pop sub 2 div 0 9 moveto 0 rmoveto show
	2 2 8 {
		newpath 0 exch 0 exch 0 360 arc closepath stroke
	} for
	45 rotate
	1 1 4 {
		newpath 9 0 moveto 11 1 lineto 11 -1 lineto
		closepath fill 90 rotate pop
	} for
	grestore
} def

/pt {
	gsave
	gco_x gco_y translate dup line_target
	/gco_x exch 17 mul gdir mul gco_x add def
	grestore
} def

% A4 210*297 
gsave 190 273 translate 1.00 line_target grestore
gsave 190 252 translate 0.909 line_target grestore
gsave 191 232 translate 0.825 line_target grestore
gsave 191 214 translate 0.750 line_target grestore
gsave 175 200 translate 0.681 line_target grestore
gsave 175 215 translate 0.619 line_target grestore
gsave 175 229 translate 0.562 line_target grestore
gsave 175 243 translate 0.511 line_target grestore
gsave 175 255 translate 0.464 line_target grestore
gsave 175 266 translate 0.422 line_target grestore
gsave 175 276 translate 0.383 line_target grestore

/gco_x 50 def
/gco_y 225 def
/gdir 1 def
4.64 pt
4.22 pt
/gco_x 167 def
/gco_y 141 def
/gdir -1 def
3.83 pt
3.48 pt
3.16 pt
/gco_x 35 def
/gco_y 73 def
/gdir 1 def
2.87 pt
2.61 pt
2.37 pt
2.15 pt
/gco_x 183 def
/gco_y 27 def
/gdir -1 def
1.96 pt
1.78 pt
1.62 pt
1.47 pt
1.33 pt
1.21 pt
1.10 pt
10 10 moveto (t 2 v 1.0 p 1) show
showpage
No refocus was attempted, since no light source at correct wavelength was available, the target focus would have been at infinity and no suitable target at infinity was at hand.

Even so, quite an odd result. I cannot figure out any major problems with the test. I understand that there are possibly some issues around initial adjustments of the lens, but that leaves the odd performance of the lens a bit without explanation. Inadequate initial install at factory might explain the asymmetrical offset, but could it explain the best resolution at corners? That would be an odd optimization at lens selection.

Is this consistent with other users? Is this something that only affects performance of Noir?

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

Re: New 8MP Camera - Q&A thread

Wed May 18, 2016 5:39 pm

Impressed by your testing methods! Curious what your setup looks like. Do you have just one test chart, and manually re-angled the camera to re-frame the image at each of the 20 ROI segments along the image diagonal? Then repeated that for each of 16 distances? Seems like quite a bit of effort! But the results are enlightening. I also found center and edge sharpness on my NoIR v2.1 to vary a lot; I could refocus to make center sharp or edge sharp at a given distance, but not both at once. Personally I wonder if removing the IR filter to create NoIR changed the optical path length behind the lens from center to edge. (well, of course it would; more properly, was it replaced by equivalent glass without the IR-blocking properties?) Even that would not explain the asymmetric focus though.

In case of interest, the PDF file with the new ring test pattern with 27 size steps is attached (in a ZIP file, because PDF is not allowed as attachment here). Also available as "Set: 27 Rings (pdf)" on this page http://www.bealecorner.org/red/test-patterns/
Attachments
ResPat-27rings.zip
27 ring test pattern
(12.58 KiB) Downloaded 252 times
Last edited by jbeale on Fri May 20, 2016 6:30 am, edited 1 time in total.

9aed
Posts: 17
Joined: Wed Sep 24, 2014 11:49 pm

Re: New 8MP Camera - Q&A thread

Wed May 18, 2016 6:46 pm

jbeale wrote:Impressed by your testing methods! Curious what your setup looks like. Do you have just one test chart, and manually re-angled the camera to re-frame the image at each of the 20 ROI segments along the image diagonal? Then repeated that for each of 16 distances?
Just one test chart. The previous chart required basically a tailored printout for every distance step, although the results were immediately comparable. And yes - 320 manual target acquisition operations, but mainly just between adjacent parts of the chart. Among other things this introduces a bit of a parallax problem at shorter distances, but it generally gets buried in noise. Next time I will use a softly moving video head, though...

Truth to be told, it was partly your previous remark about Noir being possibly fundamentally different optical animal that led to this test. This is not an answer for that question, but hopefully a step forward in learning the way of Noir V2.1.

Parkview
Posts: 58
Joined: Sun Feb 17, 2013 1:51 pm

Re: New 8MP Camera - Q&A thread

Fri May 20, 2016 2:10 pm

Hi,

I have designed up a simple 3D printable, RPi V2.1 camera lens adjustment wench: http://www.thingiverse.com/thing:1574661

This was modification of this design: http://www.thingiverse.com/thing:1557754

caerandir
Posts: 131
Joined: Tue Dec 18, 2012 11:26 am
Location: Bonn, Germany

Re: New 8MP Camera - Q&A thread

Sun May 22, 2016 5:31 pm

Hi all,

i finally produced some test images, trying my best at focussing the V2.1 modules. Have a look here: Caerandir's test images. For my modules, the lenses are still sitting pretty tight after refocussing, so I do not experience focus shifts with module tilt or so. However, focus is rather susceptible to any pressure put on the sensor housing - even light pressure already deforms the housing enough to impact focus.

@jbeale: I can confirm that the NoIR-camera is not focussing well. The edges get rather unsharp when the image center is focussed best. I guess the lens is not well suited for IR light, most likely it was optimized for visible light in a way that is particularily disadvanteagous for IR. A pity! I was able to focus my NoIR module to have a more or less even sharpness across the whole FOV, but as a result, sharpness at the center is below it's potential. At some point I'll try to unscrew the lens and use some M12 lens or so...

@Gavinmc42: It's funny to be considered famous for just drilling a hole into an old credit card :-) But I indeed a few days ago made it to the front web page of http://www.heise.de/, which is kind of a must-read for German IT-interested people. They featured a short article at how to refocus the camera (read here in German), stating my user name - which makes me a little bit proud - which again is of course pure vanity :oops: In the end I think the main reason for this honour is due to the fact that (i guess) one of the users here is working at heise.de...

Summing up, I am rather satisfied with the new normal module, but would not recommend the new NoIR module without hesitation. The performance of it is not the best.

--Caerandir

User avatar
Gavinmc42
Posts: 4062
Joined: Wed Aug 28, 2013 3:31 am

Re: New 8MP Camera - Q&A thread

Tue May 24, 2016 1:44 am

caerandir, you showed it is not hard to make something to adjust focus, the fame is yours to wallow in :lol:
jbeale had scared me off with his horror story of tweezers and pliers.

I am coming to the opinion that the wider angle, shorter focus lens does not do any favors to the sensor.
I also suspect when the module is made the film PCB with the sensor and lens holder is not perfectly aligned every time.
This is a film pcb with the sensor and connector mounted on it, which is then stuck to a metal backing plate and the lens mount then bonded to that plate. The film PCB could be laterally and/or angular misaligned.
These combinations are adding up to the variability in quality we are seeing.
This is all magnified by the shorter focus lens which has less tolerance for misalignment.
Plus focusing at less than infinity just made it more obvious.

Looking at other Sunny 8Mp IMX219 modules
http://hnl.en.e-cantonfair.com/products ... 07574.html
http://www.happinesslive.com/English/Pr ... 36025.html
There are some with knurled lens holders, which may make focus adjusting easier, top left.
http://www.happinesslive.com/images/up_ ... 162723.jpg

It is easy to pick faults:)
What is not easy is getting camera chips at all and then figuring out how to get them to work.
RPF has made it possible now for anyone to complain about or use 5, 8Mp sensors.
Looking forwards to the title changing to "New 12MP camera Q&A" :P

If there is one thing RPF can learn from this is that focusing should be an option.
Having just one camera/lens solution? There are two currently until stocks of the V1 go.
I understand they try to make it easy, plug and play for the average user but let's face it, the people who use Pi's are not average. A lot of us are uber geeks :ugeek:

Now that the Zero has a camera connector, more options for camera/lens would be nice.
How many Zero's will use cameras compared to Pi3's with cameras?
$5-10 camera with M12 mount, choice of lens?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Squarecoin
Posts: 5
Joined: Tue Apr 26, 2016 12:27 pm

Re: New 8MP Camera - Q&A thread

Wed May 25, 2016 12:11 pm

As of the last firmware update, as I understand it, the VGA 90fps option, on the V2, is being heavily cropped. Would full FOV behaviour, comparable to the V1, be possible down the line? With V1 supply ramping down, I find the restricted FOV to be a little....unwieldy for a passion project of mine (head mounted camera).

All that said, I'm hugely appreciative for all the expertise and time being volunteered here. :) I'm loving tinkering with this stuff.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7572
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 May 25, 2016 12:29 pm

Squarecoin wrote:As of the last firmware update, as I understand it, the VGA 90fps option, on the V2, is being heavily cropped. Would full FOV behaviour, comparable to the V1, be possible down the line? With V1 supply ramping down, I find the restricted FOV to be a little....unwieldy for a passion project of mine (head mounted camera).

All that said, I'm hugely appreciative for all the expertise and time being volunteered here. :) I'm loving tinkering with this stuff.
OV5647 used a technique called skipping to achieve the increased FOV at high frame rates. IMX219 is cropping instead. I'd need to look at the datasheet to see if it can skip and within what limits. If it can, then we can look into improving the FOV in the high frame rate modes.

As it is, try forcing sensor mode 6 (720P90) even if you're asking for VGA out - that has less of a crop (512 pixels off top& bottom, instead of 752), yet the pixel processing rates should still be within limits.
Full FOV may be tricky. 5MP is actually a very nice sweet spot as /2 is almost exactly 720P width (1296), and /4 is almost exactly VGA (648x486). 8MP doesn't fall as nicely.
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.

Return to “Camera board”