STICKY: New features for raspistill command

Wed May 29, 2013 12:29 pm

willip5 wrote:Could I please have a control to shut off the very bright LED on the camera module, it is interfering with my timelapse through a window. The current bit of black tape is not very elegant.

Peter

I'd suggest BluTac, but that perhaps even more inelegant. Dom was looking in to why the LED config wasn't turning it off correctly. It's just on a GPIO, so the mechanism is already there if you want to dig in.

yves97 · Wed May 29, 2013 3:12 pm

A line:

disable_camera_led=1

in /boot/config.txt

works for me (it's necessary to reboot, though).

chorlton2080 · Wed May 29, 2013 8:48 pm

jamesh wrote:
chorlton2080 wrote:Please fix the LED off option (or provide an alternative).

Also, an option to output a fully completed frame in timelapse mode (not sure if the problem exists in normal operation). At present the output file (if we assume a static filename) is formed in a scan-line type way, i.e. can be partially complete at any given moment (i.e. when referred to on a recurring basis by a script). I'm unsure if this relates to filesystem cache write to SD card or a deliberate consequence of the raspistill methodology. It would be useful to refer to a completed static filename in, for instance, an Apache served HTML webpage, rather than the hit-or-miss (usually miss) now. I'm unsure if I've explained this well enough!

I know there could be an ingenious work-around using bash or HTML, but I'm not an expert user; an option within raspistill would be more elegant.
Sorry. not sure what you mean. But guessing - The JPEG encoder outputs in stripes, but the file stays open for the entire time this takes place (less than 1s usually). You shouldn't be using the file until its closed by raspistill. If you access it whilst its being written, then you will get incomplete images. Not much to do about that - just don't access the file whilst it's open elsewhere I guess.

Yes, you've understood my issue. But I was hoping to use the raspistill command to overcome some of the streaming issues on vanilla browsers. Instead of streaming, I wanted to simply post the most recent jpg image in a served webpage. The simplest method would have been to run raspistill with a static output filename which would be posted in /var/www/ and refer to that filename within a HTTP script. Yes, as you allude to, the file is in various states of completion at any given moment. Why not have a internal buffer file created by raspistill, which is used to compose the image through "stripes", and then create a complete output file? Why would anyone wish to see a partially complete output file: it is not technically an "output".

jbeale · Wed May 29, 2013 10:58 pm

I don't think Linux systems guarantee an entire file write is an atomic process, do they? The process doing a file write can generally be interrupted by the OS task scheduler, and paused while another process starts which is reading that file, regardless of internal buffers. That's why things like .lock files, or checking if the file is open elsewhere, is needed if you want to be sure you have a complete file.

How about if you have two JPEG output files and ping-pong between them. After each fresh file is written, you swap a symlink to the newly updated one, and your static HTML page refers to that symlink, not the file directly. http://en.wikipedia.org/wiki/Symbolic_link

I haven't tried this, so maybe my syntax is wrong, but I am thinking of something like:

Code: Select all

<html><head>Current Events</head><body>
Here is what it looks like now!  <img src="NOW.jpg"> </body></html>

...and meanwhile, a script is running to write alternate files and then swap the "NOW" link to it:

#!/bin/bash
while [ 1 ] do
  raspistill -o file1.jpg
  ln -f -s file1.jpg NOW.jpg
  raspistill -o file2.jpg
  ln -f -s file2.jpg NOW.jpg
done

At least with some servers and some browsers, even pressing refresh will not update to a new picture of the same name, unless it has a timestamp different by at least 1 minute from the previous one. Maybe there is a workaround for this, I don't know.

towolf · Wed May 29, 2013 11:53 pm

jbeale wrote:I don't think Linux systems guarantee an entire file write is an atomic process, do they?

No, normally for overwriting a file properly you write to a temporary file, fsync, and then rename over the original file. That is atomic.

http://unix.stackexchange.com/a/35289

JiriH · Thu May 30, 2013 7:17 am

jbeale wrote: I haven't tried this, so maybe my syntax is wrong, but I am thinking of something like:
Code: Select all
<html><head>Current Events</head><body>
Here is what it looks like now!  <img src="NOW.jpg"> </body></html>
...and meanwhile, a script is running to write alternate files and then swap the "NOW" link to it:

#!/bin/bash
while [ 1 ] do
  raspistill -o file1.jpg
  ln -f -s file1.jpg NOW.jpg
  raspistill -o file2.jpg
  ln -f -s file2.jpg NOW.jpg
done
At least with some servers and some browsers, even pressing refresh will not update to a new picture of the same name, unless it has a timestamp different by at least 1 minute from the previous one. Maybe there is a workaround for this, I don't know.

In that case you have to wait every time for camera initialisation.

This would be better

Code: Select all

raspistill -o /tmp/image.jpg -t 9999999 --timelapse 1000 --exec /home/pi/move.sh

and then /home/pi/move.sh

Code: Select all

#!/bin/bash
#In $1 is the filename of saved image
chmod 666 "$1"
#this will move image everytime to /var/www/image.jpg even if you name source files image%d.jpg (image1.jpg image2.jpg ...)
mv "$1" "/var/www/image.jpg"

I don't know when exec parameter will be available, because Jamesh didn't write any feedback nor ETA. So you would need to compile it for yourself now.

Thu May 30, 2013 7:56 am

I merged in to my codebase, but that not yet synced up with the userland codebase (I did development using Eclipse on my own git repo), I'm going to have to move to the userland git to make the process more streamlined. So will be a few days.

If you want feedback, you are in the wrong place, I'm too busy to write answers to everything.

EDIT: You can submit commits to the userland repo, they will be checked and can then be merged if appropriate. That might be a better approach.

JiriH · Thu May 30, 2013 8:07 am

jamesh wrote:I merged in to my codebase, but that not yet synced up with the userland codebase (I did development using Eclipse on my own git repo), I'm going to have to move to the userland git to make the process more streamlined. So will be a few days.

If you want feedback, you are in the wrong place, I'm too busy to write answers to everything.

You are encouraging people to DO something. When I did, you didn't say a word, so how could i be assured that you have include that patch?
Does it take too much to write something like "ok, it's patched, will take another 2 weeks"
Nevermind, forget it. I don't want to argue with you.

Thu May 30, 2013 8:13 am

JiriH wrote:
jamesh wrote:I merged in to my codebase, but that not yet synced up with the userland codebase (I did development using Eclipse on my own git repo), I'm going to have to move to the userland git to make the process more streamlined. So will be a few days.

If you want feedback, you are in the wrong place, I'm too busy to write answers to everything.
You are encouraging people to DO something. When I did, you didn't say a word, so how could i be assured that you have include that patch?
Does it take too much to write something like "ok, it's patched, will take another 2 weeks"
Nevermind, forget it. I don't want to argue with you.

A number of people have already written code and submitted it to the userland repo. I think that is probably the best approach.

eckythump · Thu May 30, 2013 9:41 am

overlapping a bit with previous posts but:

please could we have: camera warms up ONCE, then lets us get a still quickly (50 millisec?, is it possible to get faster?), so most of the time can be used for image processing and other stuff rather than turning the camera on and waiting? (around 0.8 sec per still at the moment). Thanks.

(The idea, mentioned by others, of using timelapse running in the background sending files to alternating files (so that full images are obtained rather than partial images) might be a good solution.).

Thu May 30, 2013 10:47 am

eckythump wrote:overlapping a bit with previous posts but:

please could we have: camera warms up ONCE, then lets us get a still quickly (50 millisec?, is it possible to get faster?), so most of the time can be used for image processing and other stuff rather than turning the camera on and waiting? (around 0.8 sec per still at the moment). Thanks.

(The idea, mentioned by others, of using timelapse running in the background sending files to alternating files (so that full images are obtained rather than partial images) might be a good solution.).

It's not possible to do that in separate invocations of raspistill, the camera will always shut down on exiting the program. Not sure of the minimum time between captures, perhaps 3-4 per second at full rez.

Please remember that Raspistill is intended as demo software to show how to use the camera- some suggestions, like this one, would be better served by completely new apps. It's not that difficult....

eckythump · Thu May 30, 2013 1:58 pm

jamesh wrote:

It's not possible to do that in separate invocations of raspistill, the camera will always shut down on exiting the program. Not sure of the minimum time between captures, perhaps 3-4 per second at full rez.

Please remember that Raspistill is intended as demo software to show how to use the camera- some suggestions, like this one, would be better served by completely new apps. It's not that difficult....

I did have a look at the .c code for raspistill, but didn't make much headway with it (I'm more python than C). What would be really useful for those of us who think modifying this code would be quite difficult is a tutorial or fully commented script explaining exactly what is going on in the raspistill.c code (and the functions it calls from outside), or at least a pointer in the direction of such. I've written basic c programs in the past, but when it comes to the lower-level stuff, connection to hardware etc. it all gets a bit tricky.

Thu May 30, 2013 2:32 pm

eckythump wrote:
jamesh wrote:

It's not possible to do that in separate invocations of raspistill, the camera will always shut down on exiting the program. Not sure of the minimum time between captures, perhaps 3-4 per second at full rez.

Please remember that Raspistill is intended as demo software to show how to use the camera- some suggestions, like this one, would be better served by completely new apps. It's not that difficult....
I did have a look at the .c code for raspistill, but didn't make much headway with it (I'm more python than C). What would be really useful for those of us who think modifying this code would be quite difficult is a tutorial or fully commented script explaining exactly what is going on in the raspistill.c code (and the functions it calls from outside), or at least a pointer in the direction of such. I've written basic c programs in the past, but when it comes to the lower-level stuff, connection to hardware etc. it all gets a bit tricky.

Hmm, thought I'd done a fair job in making it as simple as possible. The camera code doesn't access the hardware directly, its all abstracted away, so no register bashing involved. If you run doxygen over the code you will get some html pages with lots of function descriptions etc which may help you decipher the code.

Start in main(), read through, it's fairly well commented and should give a decent idea of what you need to do and the order in which you need to do it.

Gert van Loo · Thu May 30, 2013 2:59 pm

Start in main(), ......

Why did you call that function main??

Thu May 30, 2013 3:03 pm

Gert van Loo wrote:
Start in main(), ......
Why did you call that function main??

It was its mothers decision.

chorlton2080 · Thu May 30, 2013 8:03 pm

Thanks for all you comments and advice, folks. I have a few suggestions of possible workarounds. I note how this thread is morphing into something a little different. I do appreciate that raspistill is a demo, but I have not, and do not intend to become, and application developer. I just want to Wash'n'Go: thus the feature request.

Fri May 31, 2013 8:06 am

chorlton2080 wrote:Thanks for all you comments and advice, folks. I have a few suggestions of possible workarounds. I note how this thread is morphing into something a little different. I do appreciate that raspistill is a demo, but I have not, and do not intend to become, and application developer. I just want to Wash'n'Go: thus the feature request.

Remember, the main Raspi's purpose in life is educational....

wallarug · Mon Jun 03, 2013 5:07 am

yves97 wrote:A line:

disable_camera_led=1

in /boot/config.txt

works for me (it's necessary to reboot, though).

Is this a suggestion or does this actually work? or is it a suggestion?

erikcf · Mon Jun 03, 2013 5:53 am

Yes, disable_camera_led was already fixed to work again sometime sort of recently. There was an update that broke that feature not long after I got my camera (which I received two days after they were officially available for purchase), but the fix has already been in the updates available with apt-get.

renambot · Tue Jun 04, 2013 1:16 am

Would it be possible to have an option to trigger the camera (in still or video mode) from a pin of the GPIO ?
I'd like to synchronize several cameras.

Also, is there an C/C++ API in the works, instead of the command line tools ?

Thanks,

Luc

Tue Jun 04, 2013 7:33 am

renambot wrote:Would it be possible to have an option to trigger the camera (in still or video mode) from a pin of the GPIO ?

Luc

It doesn't need any changes to raspistill or raspivid for you to do that - you could (for example) use a python script to monitor the GPIO line, then us an os call to send the raspistill command.

Texy

Tue Jun 04, 2013 9:30 am

renambot wrote:Would it be possible to have an option to trigger the camera (in still or video mode) from a pin of the GPIO ?
I'd like to synchronize several cameras.

Also, is there an C/C++ API in the works, instead of the command line tools ?

Thanks,

Luc

I was hoping someone would stand up to the plate and write a C library. I don't have time at the moment. all the required information is already in the demo apps.

OtherCrashOverride · Tue Jun 04, 2013 9:39 am

jamesh wrote:I was hoping someone would stand up to the plate and write a C library.

According to our USA supplier here, that will be at least 42 days before some of us can assist.

Tue Jun 04, 2013 9:59 am

OtherCrashOverride wrote:
jamesh wrote:I was hoping someone would stand up to the plate and write a C library.
According to our USA supplier here, that will be at least 42 days before some of us can assist.

We write a lot of SW here before the HW is ready...

Quasim0ndo · Tue Jun 04, 2013 12:57 pm

jamesh wrote: It's not possible to do that in separate invocations of raspistill, the camera will always shut down on exiting the program. Not sure of the minimum time between captures, perhaps 3-4 per second at full rez.

Please remember that Raspistill is intended as demo software to show how to use the camera- some suggestions, like this one, would be better served by completely new apps. It's not that difficult....

Maybe this is a rather naive proposal : Would it be possible to only invoke raspistill once and keep it running (the same way it keeps running duing a timelapse) and then have it watch a temp file which just contains a number. When that number increases a picture is taken, when the number becomes -1 the process is terminated.

STICKY: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command

Re: New features for raspistill command