RPi Camera issues and status


45 posts   Page 1 of 2   1, 2
by jbeale » Fri May 24, 2013 2:42 pm
Some of this is also on the wiki at http://elinux.org/Rpi_Camera_Module#Known_Issues
Bugs are being filed on Github at https://github.com/raspberrypi/userland/issues?state=open

R-Pi CSI Camera Status as of 24 May 2013 (see updates later in thread)

1)
Both still and video modes are currently using a 1920x1080 central crop of the sensor, which is then rescaled to provide the requested (x,y) resolution (and further cropped, if requested aspect ratio is not 16:9). JamesH reports an as-yet unreleased version has full-frame enabled, but he is currently waiting on a 2x2 binned 1296x972 at 30fps full-frame mode to work for a viable preview, before release.
viewtopic.php?f=43&t=44431#p353815

2)
The "turn camera LED off" feature, putting 'disable_camera_led=1' in in /boot/config.txt worked at release, but does not work with the current firmware. There is a partial workaround using Python to reassert control of GPIO5. Dom may be looking into this.
viewtopic.php?f=43&t=44759

3) Various EXIF problems exist with raspistill, for example JPEG file EXIF Time/Date are not correctly set (fixed at 1 Jan 1970)
viewtopic.php?f=43&t=44802

4)
Some EXIF fields are not populated, for example focal length is set to 0. (experiments suggest f=3.6 mm approximately)
viewtopic.php?t=32605&p=352038#p351417

5) The raspistill --raw option (Add raw bayer data to jpeg metadata) does not do anything; size of JPEG file remains unchanged.
viewtopic.php?t=32605&p=352038#p351915

6) In some cases, the micro-connector from the camera module to the camera board PCB has been loose, causing mis-operation. This has been fixed by removing and re-seating the small (tiny!) yellow flex cable connector labelled "P5V04A SUNNY" on the camera board.
viewtopic.php?f=43&t=39996&start=100#p355172

7) There is no Video4Linux driver for the CSI Camera yet, although work is apparently in progress. This would be on the ARM-CPU side, not on the GPU so anyone knowing Linux device drivers could in theory do this.
viewtopic.php?f=43&t=44003&p=350755&hilit=V4L#p350755

8) The camera hardware is supposed to be capable of 720p 60 fps, but this mode is not yet enabled from the GPU side.
viewtopic.php?f=43&t=44862

Hardware Issues

Colored Banding or Flickering on video: this can be caused by a poor power supply, or bad power cable. Several people have fixed this by replacing the power supply, or the microUSB power cable.
viewtopic.php?f=43&t=44863
viewtopic.php?f=43&t=43982

Camera not working: The RPi + camera draws about 260 mA more current when recording video, than without the camera. The Model B is about 550 mA by itself, so camera use pushes it over 800 mA. Some power supplies, cables, and polyfuses may not maintain 5V onboard at this current load well enough for reliable operation. You can check this with a voltmeter across TP1 and TP2.
viewtopic.php?f=43&t=43998#p350528

Another reason for camera not working is the micro-flex cable is not well seated, see (6) above.

Other Useful Information

A hand-measured mechanical drawing of the camera module is available, thanks to Gert van Loo.
There is another drawing from raspberrypi-spy

Replacement flex cables in various lengths are available.
viewtopic.php?f=43&t=43737

It is possible to stream video to other Pis, and other computers with low latency. Some methods work better than others.
viewtopic.php?f=43&t=44896
http://raspi.tv/2013/how-to-stream-vide ... -using-vlc
viewtopic.php?f=43&t=43969

The camera is fixed-focus (at infinity) as delivered. The thread-locking glue dots can be scraped off allowing manual lens focus, as close as 6 cm, or complete removal of the lens allowing other optical systems. The lens thread size may be 6 mm x 0.5. The IR filter is rigid and glued to the bottom inside of the black plastic lens housing, requiring complete disassembly to remove. This has been done twice (M33P, scorp) and in both cases the camera died soon afterwards from blunt trauma to the fragile bond wires on the die.
viewtopic.php?f=43&t=44339

The RPi camera driver and software is being developed and maintained by one volunteer (JamesH) in his spare time.
viewtopic.php?f=43&t=44431&start=25#p354825
Last edited by jbeale on Fri May 24, 2013 11:36 pm, edited 11 times in total.
User avatar
Posts: 1885
Joined: Tue Nov 22, 2011 11:51 pm
by Chris_Reynolds » Fri May 24, 2013 3:46 pm
A good summary thanks for doing this. I think it would be good to make this a sticky. I've linked to it from the Wiki page I started a few days ago http://elinux.org/Rpi_Camera_Module#Known_Issues

**EDIT** Some the issues are logged at github too https://github.com/raspberrypi/userland ... state=open
Posts: 62
Joined: Mon May 14, 2012 7:25 am
by towolf » Fri May 24, 2013 4:00 pm
Please file bugs on GitHub so they can be tracked individually.
Posts: 378
Joined: Fri Jan 18, 2013 2:11 pm
by jamesh » Fri May 24, 2013 5:01 pm
jbeale wrote:Some of this is also on the wiki at http://elinux.org/Rpi_Camera_Module#Known_Issues

R-Pi CSI Camera Status as of 24 May 2013

1)
Both still and video modes are currently using a 1920x1080 central crop of the sensor, which is then rescaled to provide the requested (x,y) resolution (and further cropped, if requested aspect ratio is not 16:9). JamesH reports an as-yet unreleased version has full-frame enabled, but he is currently waiting on a 2x2 binned 1296x972 at 30fps full-frame mode to work for a viable preview, before release.
viewtopic.php?f=43&t=44431#p353815

2)
The "turn camera LED off" feature, putting 'disable_camera_led=1' in in /boot/config.txt worked at release, but does not work with the current firmware. There is a partial workaround using Python to reassert control of GPIO5. Dom may be looking into this.
viewtopic.php?f=43&t=44759

3) Various EXIF problems exist with raspistill, for example JPEG file EXIF Time/Date are not correctly set (fixed at 1 Jan 1970)
viewtopic.php?f=43&t=44802

4)
Some EXIF fields are not populated, for example focal length is set to 0. (Lens looks like f=3.6 mm approximately)
viewtopic.php?t=32605&p=352038#p351417

5) The raspistill --raw option (Add raw bayer data to jpeg metadata) does not do anything; size of JPEG file remains unchanged.
viewtopic.php?t=32605&p=352038#p351915

6) In some cases, the micro-connector from the camera module to the camera board PCB has been loose, causing mis-operation. This has been fixed by removing and re-seating the small (tiny!) yellow flex cable connector on the camera board.
viewtopic.php?f=43&t=39996&start=100#p355172

7) There is no Video4Linux driver for the CSI Camera yet, although work is apparently in progress. This would be on the ARM-CPU side, not on the GPU so anyone knowing Linux device drivers could in theory do this.
viewtopic.php?f=43&t=44003&p=350755&hilit=V4L#p350755

Other Useful Information

A hand-measured mechanical drawing of the camera module is available, thanks to Gert van Loo.
viewtopic.php?f=43&t=44466

Replacement flex cables in various lengths are available.
viewtopic.php?f=43&t=43737

The camera is fixed-focus (at infinity) as delivered. The thread-locking glue dots can be scraped off allowing manual lens focus, as close as 6 cm, or complete removal of the lens allowing other optical systems. The lens thread size may be 6 mm x 0.5. The IR filter is rigid and glued to the bottom inside of the black plastic lens housing, requiring complete disassembly to remove. This has been done twice (M33P, scorp) and in both cases the camera died soon afterwards from blunt trauma to the fragile bond wires on the die.
viewtopic.php?f=43&t=44339

The RPi camera driver and software is being developed and maintained by one volunteer (JamesH) in his spare time.
viewtopic.php?f=43&t=44431&start=25#p354825


1) Correct. We may release with the capture fix but without the new preview mode - you do get a difference in preview vs the actual capture, but I think people could live with that until the new preview is done.
2) Dom's looking at this.
3) Correct. Not had time to look at this - but this stuff used to work so not sure why it isn't now.
4) Correct. I'll look in to that. The driver doesn't reports its focal length (I never knew what it was!)
5) This was a bug in the firmware - my firmware had a fix when I tested it but the released one missed it. Should be fixed now.
6) HW problem!
7) Indeed. We have someone working on this right now. Not sure of the timescale.

There will also be a number of other issues/enhancements in the next release.

-n should now work correctly
-? should no work correctly
No need to use hflip - it will be defaulted to the correct orientation.
Added preview opacity setting
Added code to check for failures in writing to storage (out of storage space) at which point captures will stop rather than continuing to write 0 length files.
Moderator
Moderator
Posts: 10532
Joined: Sat Jul 30, 2011 7:41 pm
by dom » Fri May 24, 2013 5:05 pm
Next release is now available through rpi-update. Should have the features James has fixed, plus the disable_camera_led=1 fix. Please test.
Moderator
Moderator
Posts: 3862
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by mrlinux2u » Fri May 24, 2013 5:42 pm
found one problem with raspivid, up until I ran rpi-update, if I set -t to -1 it kept streaming/recording video without any time outs, now this option doesn't work.

any change of having this handy switch working again please? :)
Posts: 168
Joined: Sat Sep 24, 2011 8:38 pm
by jamesh » Fri May 24, 2013 5:45 pm
Hmm, no changes that part of the code. -1 probably only worked by accident (I was surprised when people said they ewere using it). Just use 9999999.
Moderator
Moderator
Posts: 10532
Joined: Sat Jul 30, 2011 7:41 pm
by fbutler » Fri May 24, 2013 6:50 pm
jamesh wrote:Hmm, no changes that part of the code. -1 probably only worked by accident (I was surprised when people said they ewere using it). Just use 9999999.

It would be a handy setting for those people wanting to stream continuously. Any chance the accident could become a proper feature?
User avatar
Posts: 298
Joined: Thu Mar 15, 2012 4:09 pm
Location: Surrey, England
by tvjon » Fri May 24, 2013 7:10 pm
Yes, I reported that value the other day in another thread, as I reckoned 2000 million would cover most eventualities :)

Anyway, that'll teach me to use undocumented "features", as this afternoon's update has broken my statements from sending video from a camera in the socat thread I posted earlier.

I'll go & edit that thread now, but if a signed long int could be used that'd be quite handy & easy to type :)
Posts: 253
Joined: Mon Jan 07, 2013 9:11 am
by towolf » Sat May 25, 2013 12:47 am
jamesh wrote:Hmm, no changes that part of the code. -1 probably only worked by accident (I was surprised when people said they ewere using it). Just use 9999999.


What if we want to stream video for a week uninterrupted? Why is the timeout the default anyhow? Does it have a hardware reason?
Posts: 378
Joined: Fri Jan 18, 2013 2:11 pm
by towolf » Sat May 25, 2013 2:00 am
And just to clarify, when I have been selecting 1280x720 it was a crop compared to the mentioned 2x2 binned 1296x972 full-frame? Is it now possible to get binned 720p video output? Or is that to be sorted out?
Posts: 378
Joined: Fri Jan 18, 2013 2:11 pm
by rayjoh » Sat May 25, 2013 7:37 am
towolf wrote:
jamesh wrote:Hmm, no changes that part of the code. -1 probably only worked by accident (I was surprised when people said they ewere using it). Just use 9999999.


What if we want to stream video for a week uninterrupted? Why is the timeout the default anyhow? Does it have a hardware reason?

The timeout is a signed 32 bit integer. 2 000 000 000 is 555.6 hours or 23 days. I know, If there is a limit, someone is going to hit it.
-- Raymond
Posts: 9
Joined: Thu May 23, 2013 11:48 am
by jamesh » Sat May 25, 2013 7:40 am
towolf wrote:
jamesh wrote:Hmm, no changes that part of the code. -1 probably only worked by accident (I was surprised when people said they ewere using it). Just use 9999999.


What if we want to stream video for a week uninterrupted? Why is the timeout the default anyhow? Does it have a hardware reason?


Well, the code is meant for demonstration purposes - if you want something specific, you have the source code - modify it to your use case. After all, it's meant for educational purposes...
Moderator
Moderator
Posts: 10532
Joined: Sat Jul 30, 2011 7:41 pm
by jamesh » Sat May 25, 2013 7:43 am
towolf wrote:And just to clarify, when I have been selecting 1280x720 it was a crop compared to the mentioned 2x2 binned 1296x972 full-frame? Is it now possible to get binned 720p video output? Or is that to be sorted out?


There are two modes, full res for stills (should now work correctly) and 1080p video (which is a crop). If you request any other resolutions for still or video they will be based on scaling those resolutions. I still working on specific modes for other popular resolutions (720p, VGAp60, VGAp90 and a new preview 2x2 binned)
Moderator
Moderator
Posts: 10532
Joined: Sat Jul 30, 2011 7:41 pm
by towolf » Sat May 25, 2013 11:23 am
So it would not be possible to feed this 2x2 binned mode into the h264 encoder? I’m wondering if it would be possible to get a little bit wider view from where I have positioned the cam. And 2x2 would of course be higher image quality.
Posts: 378
Joined: Fri Jan 18, 2013 2:11 pm
by jbeale » Sat May 25, 2013 2:48 pm
JamesH earlier replied that if you requested that specific resolution, you would actually get the 2x2 binned version without any additional effort. Once he has that mode working, that is.

I can confirm with the new firmware, I am getting a wider field of view from raspistill, especially dramatic in the vertical direction- looks like we've got a full-sensor image now! Thank you very much for this update! I'm also enjoying figuring out the RAW data.
CAP0121-540.jpg
BEFORE field of view (16x9 showed widest view available)
CAP0121-540.jpg (50.79 KiB) Viewed 8348 times

now-full-6.jpg
AFTER field of view (4x3 full frame)
now-full-6.jpg (50.55 KiB) Viewed 8348 times
User avatar
Posts: 1885
Joined: Tue Nov 22, 2011 11:51 pm
by towolf » Sat May 25, 2013 4:24 pm
Holy crap. Sweet!

I kinda really want this in video too.
Posts: 378
Joined: Fri Jan 18, 2013 2:11 pm
by mikerr » Sat May 25, 2013 5:51 pm
Very marked field of view difference - desk pictures took from same position pre and post update:
Image Image
(click for fullsize images)
Got a Pi Camera? View it in my android app - Raspicam Remote ! No software required on the pi
User avatar
Posts: 957
Joined: Thu Jan 12, 2012 12:46 pm
Location: NorthWest, UK
by lingon » Sat May 25, 2013 7:12 pm
I measured how long the raspistill command takes when setting the timeout to 0:
Code: Select all
time raspistill -t 0 -o test.jpg

real    0m1.150s
user    0m0.010s
sys     0m0.090s

According to the EXIF information the exposure time is 63 ms,
Code: Select all
Exposure time: 0.063 s  (1/16)

The combined system and user time is 100 ms, so it appears that one second is spent waiting for something? Is there possibilities to reach more than roughly one Hz with still images with the Raspberry Pi camera module?
Posts: 101
Joined: Fri Aug 26, 2011 7:31 am
by smx » Sun May 26, 2013 9:00 pm
In a future update, will full hd video be not croppped as well?

Regards,
Posts: 19
Joined: Sun May 26, 2013 8:59 pm
by Grid » Mon May 27, 2013 7:59 am
lingon wrote:The combined system and user time is 100 ms, so it appears that one second is spent waiting for something? Is there possibilities to reach more than roughly one Hz with still images with the Raspberry Pi camera module?


It's the auto exposure delay - the camera measures the scene brightness and tries to adjust, then takes the shot. I think if you want more than 1Hz you're better off shooting video with a lower framerate.
Fix instead of throwing away. Save the planet one gadget at a time.
User avatar
Posts: 22
Joined: Fri Jan 04, 2013 5:02 pm
Location: Lodz, Poland
by jamesh » Mon May 27, 2013 9:09 am
Ref: Modes.

What will happen is that there will be a new binned mode that will use the full frame (2x2 binned = throw away every other pixel), this will be used as a preview AND when cropped to the right aspect, probably the source for the video record as well. This does mean that 1080p will actually be a slightly smaller resolution scaled up (full frame binned 2x2 scaled up to 1080p). This is quite common in the field, and the scaling up is not noticeable once you gone through H264 encoding anyway. This should give 1080p the same horizontal FOV as capture.
Moderator
Moderator
Posts: 10532
Joined: Sat Jul 30, 2011 7:41 pm
by poing » Mon May 27, 2013 9:15 am
jamesh wrote:Ref: Modes.

What will happen is that there will be a new binned mode that will use the full frame (2x2 binned = throw away every other pixel), this will be used as a preview AND when cropped to the right aspect, probably the source for the video record as well. This does mean that 1080p will actually be a slightly smaller resolution scaled up (full frame binned 2x2 scaled up to 1080p). This is quite common in the field, and the scaling up is not noticeable once you gone through H264 encoding anyway. This should give 1080p the same horizontal FOV as capture.

Could you then leave the present video mode (1080p cropped from the middle of the sensor) active too? That would allow a smaller field of view with the same quality (or theoretically higher)?
Posts: 1090
Joined: Thu Mar 08, 2012 3:32 pm
by Maxion » Mon May 27, 2013 9:25 am
jamesh wrote:Ref: Modes.

What will happen is that there will be a new binned mode that will use the full frame (2x2 binned = throw away every other pixel), this will be used as a preview AND when cropped to the right aspect, probably the source for the video record as well. This does mean that 1080p will actually be a slightly smaller resolution scaled up (full frame binned 2x2 scaled up to 1080p). This is quite common in the field, and the scaling up is not noticeable once you gone through H264 encoding anyway. This should give 1080p the same horizontal FOV as capture.


Thanks for that !

I agree, that would be the preferred way, before any naysayers come in and complain about this :)
Posts: 138
Joined: Mon Dec 03, 2012 2:22 pm
by jamesh » Mon May 27, 2013 9:30 am
poing wrote:
jamesh wrote:Ref: Modes.

What will happen is that there will be a new binned mode that will use the full frame (2x2 binned = throw away every other pixel), this will be used as a preview AND when cropped to the right aspect, probably the source for the video record as well. This does mean that 1080p will actually be a slightly smaller resolution scaled up (full frame binned 2x2 scaled up to 1080p). This is quite common in the field, and the scaling up is not noticeable once you gone through H264 encoding anyway. This should give 1080p the same horizontal FOV as capture.

Could you then leave the present video mode (1080p cropped from the middle of the sensor) active too? That would allow a smaller field of view with the same quality (or theoretically higher)?


Yes, depending on what crop is chosen (I've not implemented that in Raspistill yet, but will do - effectively I mean zoom), the nearest mode will be chosen, so as you zoom the mode will be selected that best matches. As you hit the 1080p crop in the middle that will get chosen. Note that you cannot have a perfectly smooth zoom when doing this as changing modes drops frames. The Nokia 808 is the best example of this - we still drop onb zooming, but the time was heavily optimised to reduce the effect.

All of this stuff takes time so it's not going to be in the next week!
Moderator
Moderator
Posts: 10532
Joined: Sat Jul 30, 2011 7:41 pm