towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: Consider a USB camera as an alternative

Sat Sep 21, 2013 12:09 pm

Webcams, I believe, use variable frame rate, since they are not bothered about maintaining a fixed rate, which we are. So in darker conditions the rate is lowered to help exposure times.
This is how -ex night used to work. It ranged between 4fps in low light and 30fps in fully lit conditions. And that was fine.

Many video solutions cope just fine with variable frame rates. If one just dumps h264 of course playing that will speed up when frame rates drop, but any modern video system works using PTS timestamps that are associated with each frame.

What is needed is to get -ex night back to working as it did and then one can continue to pipe raw video into ffmpeg (to get derived timestamps, i.e., timestamps of the frame coming in on stdin).

Better would be to tag frames with precise pts at the time of capture and wrap a container (mp4, ts, mkv, whatever). There are containers that allow even to add a timecode track (timecode as is time of day and date). MP4 has the tmcd track, which would be super cool to reference RTC to the video and later burn in timecode onto the video, or correlate other signals.

mmal has references to physical and other timestamps, can they be hooked up?

motocoder
Posts: 29
Joined: Fri Sep 06, 2013 4:13 pm

Re: Consider a USB camera as an alternative

Sat Sep 21, 2013 1:56 pm

jamesh wrote:That's not going to work very well. Stills takes over a second to start the camera, adjust exposure, take picture, shut down camera.
Actually, it worked great as long as there was sufficient ambient light. You can watch the videos I posted in the other thread to see it in action.

Keep in mind that my internet connection is the limiting factor for this project, so high frame rates and high resolution aren't an option no matter what the camera is capable of.

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

Re: Consider a USB camera as an alternative

Sat Sep 21, 2013 3:25 pm

jamesh wrote:That's not going to work very well. Stills takes over a second to start the camera, adjust exposure, take picture, shut down camera.
Any way of overcoming this by running the camera full time and taking stills as required ? Starting the camera up etc everytime you need a shot is what's taking the time ?

Gordon77

motocoder
Posts: 29
Joined: Fri Sep 06, 2013 4:13 pm

Re: Consider a USB camera as an alternative

Sat Sep 21, 2013 3:42 pm

gordon77 wrote:
jamesh wrote:That's not going to work very well. Stills takes over a second to start the camera, adjust exposure, take picture, shut down camera.
Any way of overcoming this by running the camera full time and taking stills as required ? Starting the camera up etc everytime you need a shot is what's taking the time ?

Gordon77
One idea would be to spawn the camera program in time-lapse mode and with standard output captured by the parent (spawning) process. Then in the parent process you can either keep the image or discard it. I'm not sure how you'd be able to keep the frames distinct. Might be easier just to grab the raspistill source code (that bit is all open source) and adapt it to your needs.

mikerr
Posts: 2826
Joined: Thu Jan 12, 2012 12:46 pm
Location: UK
Contact: Website

Re: Consider a USB camera as an alternative

Sat Sep 21, 2013 4:29 pm

ednl wrote: More elaborate alternative to completely avoid that: let the time lapse write to sequentially named images, pick the second to newest one.
That's how I did it, grab the python code here: http://www.raspberrypi.org/phpBB3/viewt ... 43&t=54361

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

Re: Consider a USB camera as an alternative

Sat Sep 21, 2013 4:51 pm

mikerr wrote:
ednl wrote: More elaborate alternative to completely avoid that: let the time lapse write to sequentially named images, pick the second to newest one.
That's how I did it, grab the python code here: http://www.raspberrypi.org/phpBB3/viewt ... 43&t=54361

Thanks these options look promising for my project

Gordon77

motocoder
Posts: 29
Joined: Fri Sep 06, 2013 4:13 pm

Re: Consider a USB camera as an alternative

Sat Sep 21, 2013 7:25 pm

mikerr wrote:
ednl wrote: More elaborate alternative to completely avoid that: let the time lapse write to sequentially named images, pick the second to newest one.
That's how I did it, grab the python code here: http://www.raspberrypi.org/phpBB3/viewt ... 43&t=54361
It's a good idea, but given the limited number of writes that a flash card can have, I wanted something that did not write to the card unless needed. My current solution only writes to the card when you tell it to capture a snapshot. For watching the web cam, it just streams low framerate MJPG, with nothing ever written to the SD card.

mikerr
Posts: 2826
Joined: Thu Jan 12, 2012 12:46 pm
Location: UK
Contact: Website

Re: Consider a USB camera as an alternative

Sat Sep 21, 2013 7:37 pm

motocoder wrote:
mikerr wrote:
ednl wrote: More elaborate alternative to completely avoid that: let the time lapse write to sequentially named images, pick the second to newest one.
That's how I did it, grab the python code here: http://www.raspberrypi.org/phpBB3/viewt ... 43&t=54361
It's a good idea, but given the limited number of writes that a flash card can have, I wanted something that did not write to the card unless needed.
The code writes to the built in RAM disk (/run/shm) - it never touches the SD card.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 27403
Joined: Sat Jul 30, 2011 7:41 pm

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 7:15 am

towolf wrote:
Webcams, I believe, use variable frame rate, since they are not bothered about maintaining a fixed rate, which we are. So in darker conditions the rate is lowered to help exposure times.
This is how -ex night used to work. It ranged between 4fps in low light and 30fps in fully lit conditions. And that was fine.

Many video solutions cope just fine with variable frame rates. If one just dumps h264 of course playing that will speed up when frame rates drop, but any modern video system works using PTS timestamps that are associated with each frame.

What is needed is to get -ex night back to working as it did and then one can continue to pipe raw video into ffmpeg (to get derived timestamps, i.e., timestamps of the frame coming in on stdin).

Better would be to tag frames with precise pts at the time of capture and wrap a container (mp4, ts, mkv, whatever). There are containers that allow even to add a timecode track (timecode as is time of day and date). MP4 has the tmcd track, which would be super cool to reference RTC to the video and later burn in timecode onto the video, or correlate other signals.

mmal has references to physical and other timestamps, can they be hooked up?
I really don't know why that has stopped working. Not sure I;ve changed anything in that area at all. Presumably some weird interaction somewhere.

The GPU also copes very well with variable frame rate - but that's not a standard use case for mobile phones - they want fixed rate. Usually the code using the GPU adds its own container, which is why the current version is straight H264, uncontained.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

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

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 8:56 am

ednl wrote:
mikerr wrote:The code writes to the built in RAM disk (/run/shm) - it never touches the SD card.
Yep, mine as well.
I've been using /tmp assuming that's in RAM, maybe it's not ?

Any advantages / disadvantages to various directories for RAM ?

I'd really like not to have to store the temporary file at all and get directly into the python programme, similar to cam.get_image(), anyway of doing that ?

Gordon77

mikerr
Posts: 2826
Joined: Thu Jan 12, 2012 12:46 pm
Location: UK
Contact: Website

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 9:07 am

gordon77 wrote: I've been using /tmp assuming that's in RAM, maybe it's not ?
Actually, /tmp is not normally in RAM as standard on raspian.
You can alter that, or just use /run/shm
Any advantages / disadvantages to various directories for RAM ?
Advantage is speed, but you can run out of space...
I'd really like not to have to store the temporary file at all and get directly into the python programme, similar to cam.get_image(), anyway of doing that ?
You can now use the V4L driver for that:
http://www.raspberrypi.org/phpBB3/viewt ... 43&t=50639

then python code is just the same as a USB cam in pygame (cam.get_image) or openCV (cv.CaptureFromCAM )
Last edited by mikerr on Sun Sep 22, 2013 11:37 am, edited 1 time in total.

mikerr
Posts: 2826
Joined: Thu Jan 12, 2012 12:46 pm
Location: UK
Contact: Website

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 11:18 am

Read that carefully, and it says the default is no.

df -h will tell you what's currently using a ramdisk (tmpfs)

e.g. on NOOBS/ raspbian:

Code: Select all

df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs          1.8G  1.6G  108M  94% /
/dev/root       1.8G  1.6G  108M  94% /
devtmpfs        180M     0  180M   0% /dev
tmpfs            38M  376K   38M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            75M     0   75M   0% /run/shm
/dev/mmcblk0p1   56M   19M   38M  33% /boot

There's a good reason for /tmp to be on disk: many programs put HUGE files in /tmp
e.g. some put a 4GB DVD ISO there prior to burning, gcc builds can use a lot

mikerr
Posts: 2826
Joined: Thu Jan 12, 2012 12:46 pm
Location: UK
Contact: Website

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 11:39 am

Oh, I mistyped... I was meaning /tmp is NOT in ram in that first post, but somehow missed off the "not" ...doh.
[I've edited it in now]

Sorry for the confusion!

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 2:44 pm

ednl wrote:Still occasionally results in a partially grey image (incomplete write).
To help with that problem, look at https://github.com/raspberrypi/userland ... 8c7d45fd6a ( https://github.com/raspberrypi/userland/pull/71 )

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

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 3:06 pm

mikerr wrote:Oh, I mistyped... I was meaning /tmp is NOT in ram in that first post, but somehow missed off the "not" ...doh.
[I've edited it in now]

Sorry for the confusion!
Thanks, no problem.
I've got my programme mostly going using your technique but it is occasionally stopping producing any output from the camera, no pictures appear in the /run/shm dir.

I'm deleting any existing pictures and starting timelapse....

Code: Select all

   files = filter(os.path.isfile, glob.glob('/run/shm/test*.jpg'))
   files.sort(key=lambda x: os.path.getmtime(x))
   if len(files) > 0:
      for filename in files:
         os.remove(filename)
   command = "raspistill -t 100000 -tl " + str(rpit) + " -n -o /run/shm/test%d.jpg -w 352 -h 288 -sa -100 -br " + str(rpibr) + " -co " + str(rpico) + " -ex off"
   p=subprocess.Popen(command,shell=True, preexec_fn=os.setsid)
Then if any parameters are changed eg height, width, brightness etc I have to stop the subprocess, delete existing pictures and restart the subprocess....

Code: Select all

          os.killpg(p.pid, signal.SIGTERM)
          files = filter(os.path.isfile, glob.glob('/run/shm/' + "test*.jpg"))
          if files > 0:
             files.sort(key=lambda x: os.path.getmtime(x))
             for filename in files:
                 os.remove(filename)
          command = "raspistill -t 100000 -tl " + str(rpit) + " -n -o /run/shm/test%d.jpg -w " + str(w) + " -h " + str(h) + " -sa -100 -br " + str(rpibr) + " -co " + str(rpico) + " -ex " + rpiex
          p=subprocess.Popen(command,shell=True, preexec_fn=os.setsid)   
                   
All seems to work OK for a while but then the pictures stop coming from the camera, the RPI is 100% busy doing something, there are no files in /run/shm and I have to reboot the RPI to start again..

Have you had any experience with stopping and restarting the timelapse subprocess ?

Gordon77

motocoder
Posts: 29
Joined: Fri Sep 06, 2013 4:13 pm

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 3:27 pm

jamesh - I've completed the tests that I promised to run this weekend.

Summary:
No change. I updated the software and captured test images using several settings. I tried playing around with the preview setting and preview time (based on comments I saw here about there being a bug around that). I started the capture a little later in the morning than planned, so ambient light was greater than at night time, and the frames were a little bit lighter than usual. Nonetheless, the exposure on the raspberry pi camera board is just awful. I've included a photo taken from the USB webcam for comparison.

Results are available here:

https://www.dropbox.com/sh/jastghqo7kd6 ... sure-Issue

- connected the camera to a RPi model B
- sudo apt-get update
- sudo apt-get upgrade
- sudo raspi-config (enabled camera)
- Reboot
Captured photos as follows:

usb-webcam.jpg
Captured with Motion software, 800x448 resolution, default options

raspicam.jpg:
Captured with the following command:
raspistill -w 648 -h 486 -t 0 -n -e jpg -o raspicam.jpg

raspicam2.jpg:
Captured with the following command:
raspistill -w 648 -h 486 -t 2000 -n -e jpg -o raspicam2.jpg

raspicam3.jpg:
Captured with the following command:
raspistill -w 648 -h 486 -t 3000 -n -e jpg -o raspicam3.jpg

raspicam4.jpg:
Captured with the following command:
raspistill -w 648 -h 486 -t 2000 -e jpg -o raspicam4.jpg

mikerr
Posts: 2826
Joined: Thu Jan 12, 2012 12:46 pm
Location: UK
Contact: Website

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 3:50 pm

Also don't forget to also do a firmware update:

Code: Select all

sudo rpi-update
which brings in more recent camera firmware

motocoder
Posts: 29
Joined: Fri Sep 06, 2013 4:13 pm

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 7:19 pm

mikerr wrote:Also don't forget to also do a firmware update:

Code: Select all

sudo rpi-update
which brings in more recent camera firmware
Is there a way to check if I have the most recent version already? I'd like to know conclusively that I have an older version before repeating the test; I have to prop the board up sort of precariously in order to get the same camera angle as the webcam.

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 7:34 pm

motocoder wrote:Results are available here:
https://www.dropbox.com/sh/jastghqo7kd6 ... sure-Issue
Not sure I want to know why you're taking pictures of the underneath of a table :!:

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

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 8:08 pm

motocoder wrote:
mikerr wrote:Also don't forget to also do a firmware update:

Code: Select all

sudo rpi-update
which brings in more recent camera firmware
Is there a way to check if I have the most recent version already? I'd like to know conclusively that I have an older version before repeating the test; I have to prop the board up sort of precariously in order to get the same camera angle as the webcam.
Uname -a. Will show a #number, latest l've seen on here is #541 dated 7th Sept

mikerr
Posts: 2826
Joined: Thu Jan 12, 2012 12:46 pm
Location: UK
Contact: Website

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 9:55 pm

Code: Select all

uname -a
Linux piloft 3.6.11+ #545 PREEMPT Fri Sep 20 23:57:55 BST 2013 armv6l GNU/Linux

lenkf
Posts: 19
Joined: Wed Jul 10, 2013 10:02 pm
Location: S.California

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 10:09 pm

I concur. On my first pi, I hooked up a usb M$ livecam hd3000 and used Motion to view my outdoor aviary from other computers at home and via internet with tweak to router forwarding. Worked decently. So I thought I'd get a 2nd pi with a pi camera module and try to do the same. I worked at that project for a while and got some nice images and videos with raspistill and raspivid. So I moved on to trying to view the pi camera via a web browser. Eventually the OS got so messed up I had to download Raspian OS and start over again. I'll say the raspi cam is not ready for prime time to view via web browser. I suspect it will be a while before Motion can use the pi cam due to issues of proprietary code in the gpu and camera (which raspivid and raspistill can use). Motion is nice with usb cam in that it creates a minimal (safe) web browser easily viewable with Firefox, and you don't have to install a web server on the pi and add programs to windows pcs. AND you don't have to download and compile custom source code to make it work on the web (which may leave other programs not working). The cpu load on the pi with Motion, one usb cam, without overclocking, is reasonable (c. 60-70%) with one visitor to the website.

For now I've removed the pi camera module from the 2nd pi and am using another usb camera with it. I also use the 2nd pi for experimenting in order to keep the first pi and usb cam dedicated to the aviary. I'll try again to hook up the rpi cam after a few more upgrades and firmware updates, (currently at 9/20/13 according to uname -a), and be watching the forums for camera news.

poing
Posts: 1132
Joined: Thu Mar 08, 2012 3:32 pm

Re: Consider a USB camera as an alternative

Sun Sep 22, 2013 11:33 pm

motocoder wrote:Results are available here:

https://www.dropbox.com/sh/jastghqo7kd6 ... sure-Issue
Correct me If I'm wrong but did you notice the '-ev' option? With that you can lower or raise the gain (artificially boosting the exposure) of the PiCamera captures. The last documentation I saw mentioned it can be used from -10 to +10 but I found it can be used from -25 to +25 IIRC.

As a photographer (following sensor development as closely as possible) I can't see why a middle of the road USB camera should give better image quality (IQ) than the Pi Camera. Should be roughly equal for sensors manufactured recently. What I can see is that USB camera manufacturers spend a lot of dough to make it easier for people to use their gadgets while the Foundation doesn't have that financial leverage and expects more from the user (and jamesh, my hero :mrgreen: ).

My guess is that while you see 'better' IQ from the USB camera it's just that they set the gain higher in your low-light scenario while I see from your examples that you didn't even bother to try raising it when using the Pi Camera. I could be wrong, have not been reading the thread closely as it doesn't interest me much, but I think you should try.

So place your camera under the table again and try something like

Code: Select all

raspistill -w 648 -h 486 -t 2000 -ev 25 -e jpg -o raspicam4.jpg

poing
Posts: 1132
Joined: Thu Mar 08, 2012 3:32 pm

Re: Consider a USB camera as an alternative

Mon Sep 23, 2013 1:06 am

That said, trying it myself the '-ev' option seems to be broken at the moment like all other exposure settings that used to work. So don't bother just yet.

Positive is that, with a little luck, jamesh should now be able to see where the broken auto exposure problem is which might lead to the so-much-craved-for complete manual mode of the Pi Camera (which doesn't only include the manual exposure but also the manual white balance(!)).

motocoder
Posts: 29
Joined: Fri Sep 06, 2013 4:13 pm

Re: Consider a USB camera as an alternative

Mon Sep 23, 2013 1:19 am

AndrewS wrote:
motocoder wrote:Results are available here:
https://www.dropbox.com/sh/jastghqo7kd6 ... sure-Issue
Not sure I want to know why you're taking pictures of the underneath of a table :!:
LOL, Andrew. Thanks for the chuckle. I have an RPi-controlled automated cat feeder on the floor underneath the camera. The camera lets me check up on the cat when I'm away from the house on short trips.

Return to “Camera board”