STICKY: New features for raspistill command

[jamesh]

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.

Perfectly feasible.

[renambot]

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

That's a first approximation, and I'll try that.
But I need something close to a genlock capability.

But the camera chip (Omnivision 5647) has a sync capability. I was wondering if that's exposed and how.

Luc

[lbendlin]

Exec command _before_ taking a shot

In addition to be able to execute a command after taking a shot I would like to see an option to execute stuff (or fork it) before attempting to take a picture.

Here's my use case: The camera sits in the dark basement and every day at noon is supposed to take a picture of the oil tank level gauge. It's dark there, so before taking a picture I need to switch on the light (an LED on the RasPi GPIO basically), take the picture, then switch the light off again and send the picture via email.

[jbeale]

having both pre- and post- execute commands sounds very useful, although that specific example doesn't sound like it needs fast response. If it really is just a LED, I think you could use a shell script to do this as well (turn on LED, call raspistill, turn off LED)? But if you were using a strobe or flash, I could see needing better timing sync.

[jamesh]

Exec command _before_ taking a shot

In addition to be able to execute a command after taking a shot I would like to see an option to execute stuff (or fork it) before attempting to take a picture.

Here's my use case: The camera sits in the dark basement and every day at noon is supposed to take a picture of the oil tank level gauge. It's dark there, so before taking a picture I need to switch on the light (an LED on the RasPi GPIO basically), take the picture, then switch the light off again and send the picture via email.

Replace the red LED on the camera board with a high power white one (check rating though - needs to be within GPIO current spec), since that goes on when power goes on.

Modify the Raspistill code to do what you want (probably does what you want already anyway). Not difficult.

[wallarug]

Exec command _before_ taking a shot

In addition to be able to execute a command after taking a shot I would like to see an option to execute stuff (or fork it) before attempting to take a picture.

Here's my use case: The camera sits in the dark basement and every day at noon is supposed to take a picture of the oil tank level gauge. It's dark there, so before taking a picture I need to switch on the light (an LED on the RasPi GPIO basically), take the picture, then switch the light off again and send the picture via email.

Replace the red LED on the camera board with a high power white one (check rating though - needs to be within GPIO current spec), since that goes on when power goes on.

Modify the Raspistill code to do what you want (probably does what you want already anyway). Not difficult.

You could just attach the LED to a different GPIO pin, then write a little python program like so:

Code: Select all

from subprocess import call
import RPi.GPIO as GPIO

GPIO.setmode(BOARD.BCM)
GPIO.setup(pin, GPIO.OUT)

GPIO.HIGH(pin)
call (["raspistill -o image.jpg"], shell=True)
GPIO.LOW(pin)

print "finished taking image"

[peepo]

please implement -tl for raspiyuv

offtopic, but....

[vilcans]

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.

I have looked at the code, and something like this would be pretty simple to implement.

Instead of using a file for communication, I'd suggest using Unix signals instead as that's more efficient than polling a file.

I imagine a use case like this. The timelapse argument would take a new possible value, signal:

Code: Select all

raspistill -tl signal -t 86400 -o img%06.jpg

That would make timelapse wait for an INT signal instead of a specified time. So between frames, you'd have to run a command like this to trigger the next photo:

Code: Select all

killall -s INT raspistill

You could implement the same logic in a Python script too. You could for example sent the INT signal whenever the user presses a switch.

The above command would run for 86400 seconds, but you can always stop the process prematurely. Just press Ctrl+C if it's open in a terminal, or run:

Code: Select all

killall raspistill

What do you think of this solution?

[peepo]

Instant grab

in many scientific studies it is useful to have a record to measure that is coincident to an event.
eg tripping switch

up to 3 seconds later the moment may have passed.

can we get sensor output within milliseconds, or even microseconds of an event?
ie ignore pre-processing, but optionally allow post-processing

[jamesh]

If the camera is up and running, then telling it to capture and it will within 1 or 2 frames - so about 100ms. Timelapse works like this - it just fires off a capture on each timeout.

Technical explanation. You are running the camera in preview mode - this is where all the exposure stuff is worked out so its all ready for when a capture is requested. On a capture command, it waits for the current frame to complete, then switches camera mode to the stills capture, then grabs a frame. Switching to stills mode will drop a frame, but you should get the next one. Device then returns to preview mode.

[Quasim0ndo]

Instead of using a file for communication, I'd suggest using Unix signals instead as that's more efficient than polling a file.
[...]
What do you think of this solution?

That sounds great - I didn't know about the use of signals in unix, so that solution did not even occur to me.

Maybe a second signal could be used to trigger the autoexposure routine - since I imagine that when the camera is run this way it will keep the setting from the very first invocation.

[jamesh]

I don't think so - exposure is worked out over time, not set by the first capture (or at least, that is how it is supposed to work).

[jamesh]

For those interested in getting the code changes I do to the camera apps before they get officially published to the raspi userland repo, you can check out my fork of userland where I make all the changes. I tend to add new branches for each new feature - but beware, I an pretty nooby at GIT so there may be oddities in the way I have done things.

Note, some changes will need firmware changes as well, which are not supplied here. Code should still run, but may not work correctly.

https://github.com/JamesH65/userland/

[jamesh]

There's an extra code change on a branch in my github which allows setting of a region of interest. You can use this to zoom in to parts of the sensor.

Would appreciate some testing if people have time. See the roi3 branch.

https://github.com/JamesH65/userland/tree/roi3

Command line parameter which takes normalised coordinates to specify the area.

-roi 0.5,0.5,0.25,0.25

would zoom in at x,y,w,h where0.5,0.5 = half way across sensor, half way down sensor, 0.25,0.25 - quarter width of sensor, quarter height of sensor.

Done like this as it's sensor pixel size independent.

James

[towolf]

That’s a useful addition. If I set -roi 1,1,1,1 in video mode, would the image coming out of the camera match what is coming out now?

Also, why did you unindent all the examples? I had formatted the README markdown specifically such that the examples stand out as code boxes (indented by four spaces). Now it’s rendered as plain-text again.

Compare this to this

[jamesh]

That’s a useful addition. If I set -roi 1,1,1,1 in video mode, would the image coming out of the camera match what is coming out now?

Also, why did you unindent all the examples? I had formatted the README markdown specifically such that the examples stand out as code boxes (indented by four spaces). Now it’s rendered as plain-text again.

Compare this to this

Didn't have time to reformat. I do all the doc changes in the ODT file, and just re-saved it as a .txt. Didnt see all the format changes until later. I really need to put the formatting in the odt file, then the txt would look a bit better. Will do that next time I update the docs.

-roi 0,0,1,1 should be full frame.

[towolf]

Why don't you just scrap the silly odt and just go with the README only, then it is formatted on GitHub and readable anywhere, especially on the command line.

Word processor docs are only used in stupid corporate environments. Plain text is the way to go, especially in revision control situations. You cannot diff a binary file.

Are you saying with the ROI I can get full sensor, full frame video? Or is --roi 0,0,1,1 just the full central 1920x1080 crop?

[jamesh]

Why don't you just scrap the silly odt and just go with the README only, then it is formatted on GitHub and readable anywhere, especially on the command line.

Word processor docs are only used in stupid corporate environments. Plain text is the way to go, especially in revision control situations. You cannot diff a binary file.

Are you saying with the ROI I can get full sensor, full frame video? Or is --roi 0,0,1,1 just the full central 1920x1080 crop?

Ooooh. Sorry to step on your toes there.

I'm happy with the way it's done now thanks - I prefer to use a word processor for word processing task. Try and keep your bias to yourself. Perhaps I should change to Word format, just for the craik.

As for the question on full sensor, you can get full sensor FOV on stills preview by using the new -fp option although the preview fps drop below 15. This simply uses the capture resolution for the preview. For video there is no change, the roi takes the specified area of the mode being used, and at the moment, the video/preview mode is not full sensor width.

Proper FOV for video will have to wait until I have time to debug the 2x2 binned mode. I'm concentrating on bugs and low flying fruit at the moment.

[towolf]

Ooooh. Sorry to step on your toes there.

I'm happy with the way it's done now thanks - I prefer to use a word processor for word processing task. Try and keep your bias to yourself. Perhaps I should change to Word format, just for the craik.
.

Whatever. Really losing patience with your attitude.

There's a project hosted on GitHub and the format of the README is markdown by convention. A couple of months ago I spent more than a few minutes reformatting it, so it became more readable. Now you want to clobber that and give me your nasty hostile attitude again.

It matters nothing to me that you are employee of a billion pound corporation. I don't know why you taking part in an open-source project if you do not want to be part of it and constantly complain about people or try to provoke them.

Really tired of your power trip, man.

[jamesh]

Ooooh. Sorry to step on your toes there.

I'm happy with the way it's done now thanks - I prefer to use a word processor for word processing task. Try and keep your bias to yourself. Perhaps I should change to Word format, just for the craik.
.

Whatever. Really losing patience with your attitude.

There's a project hosted on GitHub and the format of the README is markdown by convention. A couple of months ago I spent more than a few minutes reformatting it, so it became more readable. Now you want to clobber that and give me your nasty hostile attitude again.

It matters nothing to me that you are employee of a billion pound corporation. I don't know why you taking part in an open-source project if you do not want to be part of it and constantly complain about people or try to provoke them.

Really tired of your power trip, man.

Mod Hat Off. Please read the following as my own personal view and in no way should be regarded as the opinion of the RPF. Should another moderator feel this post is OTT feel free to remove it.

My attitude? WTF? You have a go at the work I do for FREE and I'm the one with the attitude? Where I work is completely irrelevant as well, the vast majority of work done on the raspicam software was done in MY OWN TIME. I think you should just bugger off and do the work yourself if its so sodding important for you. I'm fed up with your digs. I'm not on a power trip, I'm not looking for credit, but what I really don't need is sarcy bloody attitude from you. I apologised that the minor formatting changes you did awhile back have been lost (30 minutes work maybe, compared with the 100 of hours I've put in on this project, just so you get some perspective), and you go off on one. You are the one with the attitude/powertrip issues, not me.

I know SFA about github, never having used it before. All the development of the camera module was done off github (bitbucket in fact when I needed cloud storage), so the md file is a new thing to me. And RIGHT NOW I am reformatting the odt file to provide better formatting when it's saved as a readme.md. Although TBH, this is documentation for using the camera, not documentation for github, so why this is such an issue for you is beyond me.

Mod hat back on.

[abishur]

as long as the mod hat is off, then my mod response without favoritism :

Both sides please cool your jets.

towolf: we encourage healthy debate, but calling something "stupid corporate environment [software]" is not healthy debate; it's name calling and factually incorrect since odt is the favored format of openoffice a free software not usually encouraged by corporations. I'm sorry that your edits were lost, but this is James' project and he can do whatever he wants to it.

James: Please remember to keep responses civil, we do not permit fighting on this forum.

Please keep this in mind if you choose to continue this, off topic, discussion.

[kevinthefixer]

I would like to see a "coloring book" function in Raspistill, similar to the "sketch" image effect but without the pastel coloring, producing a line drawing. I have seen such effects in image editors before, but unfortunately always in proprietary software packages that came with printer driver CDs. Any chance of that?

[tineibous]

I wold love if has on the raspberry a function to take photos with long time exposure, like 30 seconds, because is going to be very usefull to astronomic photografics.

[jamesh]

I wold love if has on the raspberry a function to take photos with long time exposure, like 30 seconds, because is going to be very usefull to astronomic photografics.

I think there is a upper limit on exposure time, but I am looking in to being able to set the exposure.

[Zamzara]

Hi James, I just wanted to say thank you so much for your work on this - being able to set the exposure time should greatly improve the results of my timelapses. I've also noticed that forcing the ISO to 100 has a noticeably positive impact on image quality.

If anyone else is interested in using manual settings effectively, I would recommend this: http://www.fredparker.com/ultexp1.htm