I cannot remember if I implemented that...I'm sure someone will comment if I did or didn't.

I've been putting information on long exposure in a different thread - got it to about 2s but proving awkward to go further. As for ISO, the lower the better - higher ISO means more analog/digital gain is added, which will increase noise.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

Is there a facility that allows a time lapse video to be created by specifying how often a frame is taken and then a video is automatically created that you can specify how many frames per second that the resultant video plays back at?

Forrrge wrote:Is there a facility that allows a time lapse video to be created by specifying how often a frame is taken and then a video is automatically created that you can specify how many frames per second that the resultant video plays back at?

Apologies if this has already been discussed.

Raspistill will take pictures at specified intervals. Then use a different piece of software to make it in to a video (ffmpg/avconv will do that). There are various threads about timelapse around.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

Sorry, simply don't have the time to look at it at the moment. I have three camera modes that really need sorting out - full FOV video; 60fps; 90fps.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

jamesh wrote:Sorry, simply don't have the time to look at it at the moment. I have three camera modes that really need sorting out - full FOV video; 60fps; 90fps.

Glad to see full FOV is at (or near) the top of the list. I've had to resort to other using usb webcams while waiting for this to happen, but I'd much prefer to use the camera module. If there is anything I could do to help you on that, I certainly would (as many others have said as well). We can't do it directly, since it is GPU code, but is there a to do list of userland fixes that we could help out with that might free up more of your time for the closed source bits?

Not really, I think most of the userland side issues are solved. Although there is an issue list on github for anyone who want to take a peak.

I'm busy at work at the moment, so cannot look at either side of the GPU barrier!

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

Kinda ironic that this type of development is closed of to the crowd, while the raspberry pi leans so heavily on the crowd to exist. Can issues like this be prevented or circumvented in the future with future iterations of the Pi?

cmegens wrote:Kinda ironic that this type of development is closed of to the crowd, while the raspberry pi leans so heavily on the crowd to exist. Can issues like this be prevented or circumvented in the future with future iterations of the Pi?

You can also look at it from a different perspective: The closed code is a serious asset for the manufacturers which they won't give away. Luckily there's a bloke with access to the code that is willing to waste his free time hacking on user requests.

If I compare that with the likes of Nikon, those guys are totally deaf and blind to the most obvious user-requested features and all you ever get back when you contact them is evasive marketing speak.

Tell that to the dudes who spent years trying to painstakingly clean-room reverse engineer the Broadcom wireless drivers to write open source kernel drivers.

Then some blokes at Broadcom decided the Android business was worth opening up the driver for. Suddenly the sacred business secrets and regulatory obligations for keeping it closed did not matter anymore.

cmegens wrote:Kinda ironic that this type of development is closed of to the crowd, while the raspberry pi leans so heavily on the crowd to exist. Can issues like this be prevented or circumvented in the future with future iterations of the Pi?

No, not really, unless you know of a open source chip with the same level of capability and price, or a manufacturer of a chip who is willing to put the time and effort in to support it to the level that Broadcom has, even given the closed source nature of the GPU.

Not ironic at all, the Pi doesn't lean that heavily - the Linux OS and its associated software (which is available to anyone, on any board itself been ported to), but the board itself, no crowd input on that. The Pi has never claimed to be an OS platform, although in fact it's probably the most open of the available ARM platforms given the entire ARM side code base is OSS.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

towolf wrote:Tell that to the dudes who spent years trying to painstakingly clean-room reverse engineer the Broadcom wireless drivers to write open source kernel drivers.

Then some blokes at Broadcom decided the Android business was worth opening up the driver for. Suddenly the sacred business secrets and regulatory obligations for keeping it closed did not matter anymore.

Not sure what your point is. Broadcom are a business. There came a point where the business benefited from open sourcing the drivers. They open sourced the drivers. It's business. Pure and simple. And the Android business is BIG business.

The fact that people had been reverse engineering them is irrelevant to the business decision. It's a bugger for those that had been doing it (and its quite possible the clean room drivers are better than the manufacturer ones), but it was their decision to do it, in the knowledge there may come a time when they would be released anyway.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

jamesh wrote:Sorry, simply don't have the time to look at it at the moment. I have three camera modes that really need sorting out - full FOV video; 60fps; 90fps.

Glad to see full FOV is at (or near) the top of the list. I've had to resort to other using usb webcams while waiting for this to happen, but I'd much prefer to use the camera module. If there is anything I could do to help you on that, I certainly would (as many others have said as well). We can't do it directly, since it is GPU code, but is there a to do list of userland fixes that we could help out with that might free up more of your time for the closed source bits?

I'm really glad as well to see FOV is at the top of the list as we're really looking forward to it making our camera projects even better! Luckily I am in a position to offer you a Ferrari* for completing this work. All yours as soon as the firmware is released... Appreciate all the work you have done to date in producing a great product. Have a good Christmas.

Personally waiting more on the 60fps functionality (as you might have guessed ) This would make the camera board instantly killer for some sports related projects, as you need more frames to really capture most sports movements. I too will donate a ferrari like BPK for this functionality to arrive, after I fluently capture a high speed drift in 60fps of said Ferrari

Would it be possible to add the ability to output the image at two sizes?

For example a full resolution image then a smaller image (640x480) (or whatever the correct aspect ratio is). Using the GPU to do the resizing rather than using something like Imagemagick which is understandably fairly slow on the RPi.

I think the python camera library does something like that. Not sure of the frame rate.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

PNG is not HW accelerated, so will be slower. Overlays is something on my list, but I have no idea when I will have time to look at them.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

P.s: I guess just providing a GPU-api for:
* copy a camera image buffer to a second
* overlay image-Buffer with a second one (maybe different operations)
* Scaling an image buffer
* converting the image buffer to JPEG

And having pycamera call those APIs would be sufficient to implement everything from python (or with other language bindings) with much higher flexibility of what can get done and in what sequence than just extending raspistill...

msperl wrote:P.s: I guess just providing a GPU-api for:
* copy a camera image buffer to a second
* overlay image-Buffer with a second one (maybe different operations)
* Scaling an image buffer
* converting the image buffer to JPEG

And having pycamera call those APIs would be sufficient to implement everything from python (or with other language bindings) with much higher flexibility of what can get done and in what sequence than just extending raspistill...

All these things are possible. All require quite a bit of code to be written.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

Sorry there was a change to the exposure code in the GPU and raspistill and vid haven't caught up yet. Meant to fx it today but ran out of time. Will do it tomorrow.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

so please test and comment. If OK, will submit a pull request to the main repo.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.