Attempted to use raspistill with raw flag and timelapse flag to generate image sequences for video conversion. Unfortunately only the first still frame saved to disk contains raw bayer data in the jpg exif. Every following frame is saved normal jpg as if the raw flag was never enabled.

It’s quite easy to unscrew the little lens and do focal imaging with other optics.

Based on the stadard lens, the post-processing assumes a fall-off towards the edge and compensates with a filter. Once the optics change this filter interferes with making good images.

Would be neat if this could be turned off, on-the-fly if possible.

Hi there,

when linking my programs against this library (including the sample hello_* programs) I'm seeing an undefined reference to khrn_image_is_tformat.

When grepping the whole 'userland' repo I only see three instances of it, and they're all invocations of the function (no definition or prototypes).

Where can I find the definition for this function?
There's a stack of similar-looking functions in interface/khronos/common/khrn_int_image.h.

Cheers,
Simon

Hi,
I'd appreciate if there was a default filename for images and vids like timestamp.

Hey there, I'm trying to compile berryboot from source as per the instructions here https://github.com/maxnet/berryboot, and this fails on "error: redefinition of typedef 'VCOS_SEMAPHORE_T'" in raspicam (see attached image). I see this was added 16 hours ago, is it a bug here or on the berryboot side, or just my system messing up?

I've built my own embedded distribution based on CrosstoolNG, Buildroot/Busybox and the raspberry pi firmware and userland repos. I cross compiled xbmc to use on this distribution, but its failing to start. I get these lines in an strace output of the xbmc binary:

grep vchiq /tmp/xbmc.strace

open("/opt/xbmc-bcm/xbmc-bin/lib/libvchiq_arm.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/opt/vc/lib/libvchiq_arm.so", O_RDONLY) = 3
open("/dev/vchiq", O_RDWR) = -1 ENOTCONN (Transport endpoint is not connected)
open("/dev/vchiq", O_RDWR) = -1 ENOTCONN (Transport endpoint is not connected)
write(1, "* failed to open vchiq instance\n", 32) = 32

Are there any validation tools or recommended steps to make sure my firmware and userland repos have been properly installed and are working with the kernel driver? I'd like to be sure these are correct before diving deeper into why xbmc isn't working.

Also, I'm using the 3.2.27 kernel with the driver compiled in (not a loadable module). Should I make it a loadable module instead? Do the latest (master) branches of the firmware and userland work with 3.2.27 or do I need to rev the kernel to 3.6.x?

Is there a better place to post these questions? The RPI forums, perhaps (but which forum is appropriate)?

Many thanks!

Auto white-balance in the camera apps only works when the preview is active.

For each of raspivid, raspistill and raspiyuv, running them with --help e.g. 'raspivid --help' just displays the full-screen video preview overlay, rather than displaying the expected help text!

As discussed here raspberrypi/firmware@470b34d the source-code for edidparser and vcdbg is currently unavailable. AFAICT this makes them the only part of the ARM-side code that isn't yet open-sourced.

Creating this issue as a reminder that they ought to be added at some point...

I have the following packages in OpenEmbedded failing to build as they include <EGL/egl.h> but then cannot find "vcos_platform_types.h":

mesa-demos 0.8.1
weston 1.1.0
gstreamer1.0-plugins-bad 1.0.7

What's the suggested solution for this? They're all fairly big upstream projects (mesa, weston and gstreamer) which support many platforms. I doubt I'm going to get much luck sending a patch to add a raspberrypi-specific include directory to their build system. I'd rather see this solved commonly so that all downstream users of the raspberrypi EGL support simply include "EGL/egl.h" and it just works. Is that possible?

I accidentally started writing images to a tiny partition on a USB flash drive and ended up with 0-byte files being written with no feedback from the program once the destination drive filled up.

In raspistill.c:506 encoder_buffer_callback() the return of fwrite() is never checked. Perhaps check the size_t returned versus the length of the data (or for zero)?

I'd like to use raspivid for live streaming of the captured video. But I'm unable to start raspivid without time limit.

So when using the stdout as output allow it to run forever (run raspivid with -t 0 paramter). I came up with the following patch against RaspiVid.c:

1087c1087,1088
<                for (wait = 0; wait < state.timeout; wait+= ABORT_INTERVAL)

---
>                wait = 0;
>                while(true)
1091a1093,1098
>                   if ( state.timeout > 0 || state.filename[0] != '-' )
>                   {
>                      wait+= ABORT_INTERVAL;
>                      if (wait>state.timeout)
>                         break;
>                   }

it may be helpful to be able to programme ISP to send ROI for saving,
in some circumstances.

I am keen to experiment with this aspect which is a regular feature of more expensive research equipment and board camera software.

http://www.raspberrypi.org/phpBB3/viewtopic.php?p=343665#p343665

There is currently no way to disable preview. This is the error when using the suggested -p '0,0,0,0' workaround on the elinux wiki:

root@raspbmc:/opt/vc/bin# /opt/vc/bin/raspistill -t 0 -o /home/pi/camera/surveillance.jpeg -w 600 -h 800 -p '0,0,0,0'
mmal: mmal_vc_port_info_set: failed to set port info (3:0): EINVAL
mmal: mmal_vc_port_set_format: mmal_vc_port_info_set failed 0x1cf1c00 (EINVAL)
mmal: camera viewfinder format couldn't be set
mmal: main: Failed to create camera component
mmal: Failed to run camera app. Please check for firmware updates

I did a night time lapse test and when I analysed the images I found something curious:
Applying a "multiply" effect revealed a strange line at the bottom of the images that looks like a part of the image is corrupted. This is more noticeable with darker images, and some of them were pitch black - that's why I managed to spot it.
The code I used to capture the images: raspistill -o image$i.jpg -ex auto -q 50 -w 1440 -h 1080 -ev 10 --vflip
This issue can be reproduced with these settings every time, but it's less noticeable on brighter images (they become too bright with big multiply values to see anything).
Some examples:
A pitch black image: http://shrani.si/?2E/bR/kCV2tgK/image10.jpg
Same image, cropped and multiplied by factor 100 to show the issue:

A brighter image: http://shrani.si/?3b/2O/69INt2k/test.jpg
Same image, cropped and multiplied by factor 100 to show the issue:

It appears this issue does not occur when no additional settings are used: raspistill -o test.jpg

@JamesH65 suggested:

I think that is because your vertical height is not a multiple of 16.

I agree that this seems a reasonable explanation.

A frequently requested feature in XBMC related projects is the possibility to use USB/ I2S sound cards. The only sane option [1] to play audio/video files in XBMC is via the 'omxplayer' using the OpenMAX framework.

Hence, the feature request for an ALSA sink in the Broadcom OpenMAX IL implementation to overcome the limitation for USB sound cards in omxplayer/XBMC.

I am aware that this feature might not have a high priority, but I'm sure many users of omxplayer/XBMC/OpenELEC/Xbian would appreciate this feature. I guess also the downstream developers would be grateful for this, because they are usually dealing with the frequent complains/bug reports of not working USB sound cards [2].
Unfortunately, my programming skills are not advanced enough to accomplish this task myself, hence my kind question if one of the (Broadcom) developers would be willing to implement it.

[1] Aside from a really dirty and unreliable hack, exclusively available in raspbmc, that uses 'paplayer' for ALSA sound devices: http://forum.stmlabs.com/showthread.php?tid=1052

[2] Bug reports on USB/ ALSA sound cards:
huceke/omxplayer#36
http://forum.xbmc.org/showthread.php?tid=140809
OpenELEC/OpenELEC.tv#953
OpenELEC/OpenELEC.tv#1804
OpenELEC/OpenELEC.tv#2478 (comment)
xbianonpi/xbian#4
... and many more in various forums.

It seems that a few files are missing "makefiles/cmake/scripts/install_vmcs" and "interface/vchiq_arm/etc/10-vchiq.rules". The install command fails on account of that.

The video mode currently crops the central 1920x1080 pixels out of the full image.

This leads to much narrower FoV than necessary. It would be better to bin 2x2 pixels and offer the resulting 1296x972 pixels as a high quality (improved SNR) and full-frame video mode.

If a 16/9 aspect ratio is required, a 1280x720 crop would give the widest FoV with no additional resampling.

Sorting through compiler warnings; this looks like a real bug; the apparent intent of this code is to change the group in this case, but it looks like someone typed "==" where they intended "=".

/usr/home/tim/projects/crochet-rpi/vcuserland/interface/vmcs_host/vc_vchi_tvservice.c:1564:13: warning: equality
comparison result unused [-Wunused-comparison]
group == HDMI_RES_GROUP_CEA;
~~~~~~^~~~~~~~~~~~~~~~~~~~~
/usr/home/tim/projects/crochet-rpi/vcuserland/interface/vmcs_host/vc_vchi_tvservice.c:1564:13: note: use '=' to turn
this equality comparison into an assignment
group == HDMI_RES_GROUP_CEA;
^~
=
1 warning generated.

Currently when capturing a timelapse series of images specifying the %d modifier for the output filenames the image number which is inserted into the filename is simply the current capture number. For instance, in a series of 10 images specified with the output filename: image%d.jpg the resulting filenames would be image1.jpg, image2.jpg...image10.jpg. This method leaves the sorting of files by filename open to different interpretations. One sort method would resolve the order as 1, 2...10 and another (lexicographical) would resolve the order as 1, 10, 2...9. To avoid this potential confusion I suggest adding leading zeroes to filenames where they're warranted. Given that the total number of images is generally known (except in the potential case where someone specifies that the capture should continue until manually aborted) this allows the calculation of the total number of digits each filename should contain.

From the example above the previous result of image1.jpg, image2.jpg...image10.jpg would become image01.jpg, image02.jpg...image10.jpg.

Hi, I am trying to use raspistill -tl for taking snapshots once every half a second, which I then serve via a web server. The problem I have is that the images are corrupted. Raspistill just overwrites the file while the web server streams it.

If the filename given by -o does not exist or is a regular file, the right way to overwrite it is:

1. write to filename.tmp
2. unlink filename
3. link filename.tmp to filename
4. unlink filename.tmp

This way, the image will never be corrupted.

Thanks.

I don’t know what this is doing but what it is setting is not EV, i.e., log_2 scale. It’s quite small increments. Please clarify

Switching to MMAL_PARAM_EXPOSUREMODE_NIGHT is very nifty, as can be seen here:

It gives shots with low light much more exposure time, at the cost of fixed fps. You can see it ramps fps down as light fades and then flatlines at 4fps.

First question, why 4fps. Could it go lower?

To see how low I wonder what MMAL_PARAM_EXPOSUREMODE_VERYLONG does.

And why does it not work?

Building userland from master using a toolchain I rolled myself with CrosstoolNG. I get the following:

[ 51%] Building ASM object interface/khronos/CMakeFiles/khrn_static.dir/common/khrn_int_hash_asm.s.o
/home/mjhammel/src/ximba/raspberrypi/bld/crosstool-ng-1.15.2.bld/install/bin/arm-unknown-linux-gnueabi-as: unrecognized option '-_HAVE_SBRK'
make[3]: *** [interface/khronos/CMakeFiles/khrn_static.dir/common/khrn_int_hash_asm.s.o] Error 1

firmware repo is up to date when doing this build.

Building with commit 9852ce2 does not generate this error. Am I missing something in my toolchain?

FYI: My project is PiBox, which is on gitorious if you'd like to test it though you have to build the toolchain manually. I don't have released, packaged versions yet.

With commit
61232b4 Add hello_pi apps and bcm_host.h to userland. Merge with latest code.
the installation of the header files in vcos/pthreads was disabled. I don't think this was intended, as it breaks build of almost everything, cause these headers are referenced by other headers at many places.

Hello,

I could build EGL lib successfully with this userland source without any problem.

But when I build this with -DANDROID option, I fount there are some dependency related android/log.h and gralloc_brcm.h. So, I tried to find the h file, but I couldn't find where is gralloc_brcm.h.

I guess this userland source is already ported as android, but some files related to gralloc still not opened.

Thanks.

As I can see mml supports different profiles.

Currently raspivid outputs h264 high profile, it'd be nice to configure it.

Requesting option for raspivid to output raw frame data for image processing/analysis. Even if we can only use low resolution or low frame rate to not overload the Pi's limited CPU power, it'll make for a cheap, compact unit for computer vision projects.

I have already tried modifying https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/raspicam/RaspiVid.c#L695 to a different codec listed in https://github.com/raspberrypi/userland/blob/master/interface/mmal/mmal_encodings.h (RGBA would be a good candidate) but the Pi doesn't appear to support anything other than H.264, upon execution it throws a "mmal_vc_port_info_set failed EINVAL" error.

Right now piping video into a video processor like ffmpeg gives incorrect timing in combination with --exposure night and in other situations.

Useful formats would be MP4 and MPEG TS.

Building with Clang fails because Clang is stricter about implicit type conversions than GCC. (This is on FreeBSD, which is in the process of switching the system compiler for ARM from GCC to clang.) The specific error is pasted below.

One possible fix would remove -Werror from mmal/CMakeLists.txt. Another would add explicit casts to these two assignments. Clang complains about a number of other similar conversions elsewhere but those don't have -Werror enabled, so those don't break the build.

[ 94%] Building C object interface/mmal/vc/CMakeFiles/mmal_vc_client.dir/mmal_vc_client.c.o
/usr/home/tim/projects/crochet-rpi/vcuserland/interface/mmal/vc/mmal_vc_client.c:102:13: error:
implicit conversion from enumeration type 'VCOS_STATUS_T' to different
enumeration type 'MMAL_STATUS_T' [-Werror,-Wenum-conversion]
status = vcos_semaphore_create(&waitpool->sem, VCOS_FUNCTION,
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/home/tim/projects/crochet-rpi/vcuserland/interface/mmal/vc/mmal_vc_client.c:110:16: error:
implicit conversion from enumeration type 'VCOS_STATUS_T' to different
enumeration type 'MMAL_STATUS_T' [-Werror,-Wenum-conversion]
status = vcos_semaphore_create(&waitpool->waiters[i].sem,
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
*** [interface/mmal/vc/CMakeFiles/mmal_vc_client.dir/mmal_vc_client.c.o] Error code 1

Stop in /usr/home/tim/projects/crochet-rpi/vcuserland/build/arm-freebsd/release.
*** [interface/mmal/vc/CMakeFiles/mmal_vc_client.dir/all] Error code 1

Stop in /usr/home/tim/projects/crochet-rpi/vcuserland/build/arm-freebsd/release.
*** [all] Error code 1

Stop in /usr/home/tim/projects/crochet-rpi/vcuserland/build/arm-freebsd/release.

Can we have a command that will exit the execution cleanly as opposed to ctrl+z which sometimes causes the preview window to freeze or the camera to freeze on and become unresponsive. Only way around recovering is to reboot. This will also make it easier to exit out of -t -1 executions when needed.

Are there any plans to remove the circular dependencies in interface/khronos?
It won't work in a Android environment, which is a known problem according to the CMakeLists.txt.
Is it even possible to resolve those dependencies?

If the following error occurs, raspistill returns 0 as retvalue

root@raspberrypi:/opt/webcam/bin# raspistill --rotation 180 -o /opt/webcam/bin/../data/b8jd8tddi2rgw/2013/7/22/2013-07-22T23:36:58UTC.jpg -e jpg -q 50 -n -w 800 -h 600
mmal: mmal_vc_component_enable: failed to enable component: ENOSPC
mmal: camera component couldn't be enabled
mmal: main: Failed to create camera component
mmal: Failed to run camera app. Please check for firmware updates

root@raspberrypi:/opt/webcam/bin# echo $?
0

Should be changed to non-zero value

This is a request to make the exposure time (shutter speed) an exposed parameter in the API (or if it is already, to document how to use it.)

I would like to set the shutter speed for raspistill. I want to do technical imaging where I can control what the camera does (and, secondarily, make it do it with as little lag as possible).

If I set --exposure=off then it always takes a 1/100 s image (according to the EXIF).

I have looked through the mmal_parameters_camera.h and don't see any way to set the exposure time, unless it is disguised as e.g. MMAL_PARAMETER_FRAME_RATE, MMAL_PARAMETER_FPS_RANGE, etc.

Since the Raspberry Pi is not an open-source project, I can't go in and see how it is setting the shutter speed.

This capability would be useful for, e.g.:

1. HDR imaging
2. Astronomical imaging
3. structured light scanning
4. photogrametry
   and any other purpose where the data is more important than the aesthetics.

...simply because host_applications/linux/apps/hello_pi/rebuild.sh is missing entries for the hello_videocube directory.

There should be an option to set the color balance manually using k values (ie. 3200, 5600, 6500, etc.) in order to fine-tune the color balance of an image/video.

makefiles/cmake/vmcs.cmake - Line 54 - makefiles/cmake/scripts/install_vmcs is missing from repo.

interface/vchiq_arm/CMakeLists.txt - Line 9 - etc/10-vchiq.rules is also missing.

Other than that it builds and installs fine natively on the Pi.

Thanks Broadcom!

Update:
Oh wait, it's also missing bcm_host.h and doesn't install a lot of interface headers...
Maybe repo was never ment as a complete /opt/vc replacement, in that case install procedure is probably not a big deal :)

If i use "raspivid -t 0 -b 8000000 -ex night -o - | /opt/ffmpeg/bin/ffmpeg -i - -vcodec copy -an -f flv -metadata streamName=myStream tcp://0.0.0.0:6666" the framerate goes down to 4 fps and after some minutes the stream breaks down.

If i use "raspivid -t 0 -b 8000000 -o - | /opt/ffmpeg/bin/ffmpeg -i - -vcodec copy -an -f flv -metadata streamName=myStream tcp://0.0.0.0:6666" without -ex night everything works fine.

Same Thing with cvlc Streaming.

At the moment the "buildme" defines "CMAKE_TOOLCHAIN_FILE" which is designed to use the cross compiler. Would it be possible to add a ".cmake" configuration for use on the RPi please?

I ran 'make' and it complained that '../Makefile.include' was missing, so I changed that line in the Makefile to 'include ../hello_pi/Makefile.include'
Then running 'make' complained that 'interface/mmal/mmal.h' was missing, so I added 'INCLUDES+=-I../../../..' to the Makeile.
Then running 'make' ran to completion, but it only produced a single 'raspicam.bin' file, rather than the three separate raspistill, raspivid and raspiyuv files as found in /opt/vc/bin/

Accessing the camera using two commands at the same time causes the first command to hang, and the second command to fail with the error

mmal: mmal_vc_component_enable: failed to enable component: ENOSPC
mmal: camera component couldn't be enabled
mmal: main: Failed to create camera component
mmal: Failed to run camera app. Please check for firmware updates

Running ps aux and killing the running raspistill process results in the error not appearing, but the command still hangs

~ $ raspistill -v -o temp.jpg

RaspiStill Camera App
=====================

Width 2592, Height 1944, quality 85, filename temp.jpg
Time delay 5000, Raw no
Thumbnail enabled Yes, width 64, height 48, quality 35

Preview Yes, Full screen Yes
Preview window 0,0,1024,768

Sharpness 0, Contrast 0, Brightness 50
Saturation 0, ISO 400, Video Stabilisation No, Exposure compensation 0
Exposure Mode 'auto', AWB Mode 'auto', Image Effect 'none'
Metering Mode 'average', Colour Effect Enabled No with U = 128, V = 128
Rotation 0, hflip No, vflip No

The system has to be rebooted for it to work again.

This can be reproduced by running a camera command simultaneously in two screen sessions.
Tested with fully updated (on 20130525) Raspian wheezy image.

I get a black frame, no matter the settings.

Is there any way to achieve truly manual exposure? i.e., set ISO and exposure time by hand.

/home/pi/src/raspberrypi/userland/interface/vcos/generic/vcos_generic_blockpool.c
is present

have limited experience with gdb or segfault,
please supply gdb instructions as required.

my apologies if this is a C issue rather than a bug,
using an edited version of Tasanakorn's mmal code.

the attached repeatedly occurs within ~2 seconds, but not immediately

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6dc1470 (LWP 2526)]
0xb6f8efcc in vcos_generic_blockpool_free (block=0xa2d64) at /home/dc4/userland/interface/vcos/generic/vcos_generic_blockpool.c:356
356 /home/dc4/userland/interface/vcos/generic/vcos_generic_blockpool.c: No such file or directory.
(gdb) 62;9;c62;9;c62;9;c62;9;c

Issues for the userland code seem to be split between this github project and the 'firmware' github project. I'd suggest adding a quick line to the README.md file to point users in the right direction for where to post and look for issues so that you don't get duplicates like the one I just posted...

/opt/vc/bin/raspistill -n -t 0 -o test.jpg
$ segfault

when display is not attached ((

in my state of ignorance it seemed possible that setting no preview when display is not connected might preserve resources.

raspistill make fine picture, raspivid and raspiyuv make broken video files. Players can't decode it.

$ sudo raspivid -v -t 1000 -o – | nc 10.0.6.253 5001

RaspiVid Camera App

Width 1920, Height 1080, filename –
bitrate 17000000, framerate 30, time delay 1000
Sharpness 0, Contrast 0, Brightness 50
Saturation 0, ISO 400, Video Stabilisation No, Exposure compensation 0
Exposure Mode 'auto', AWB Mode 'auto', Image Effect 'none'
Metering Mode 'average', Colour Effect Enabled No with U = 128, V = 128
Rotation 0, hflip No, vflip No
Camera component done
Encoder component done
Starting component connection stage
Connecting camera preview port to preview input port
Starting video preview
Connecting camera stills port to encoder input port
Opening output file "–"
Enabling encoder output port
Starting video capture
Finished capture
Closing down
Close down completed, all components disconnected, disabled and destroyed

but nothing:

nc.exe -L -p 5001 | mplayer.exe -fps 31 -cache 1024 -
MPlayer Redxii-SVN-r36251-4.6.3 (C) 2000-2013 MPlayer Team
Custom build by Redxii, http://smplayer.sourceforge.net
Compiled against FFmpeg version N-52919-ge4723a8
Build date: Thu May 9 02:07:55 EDT 2013

Playing -.
Reading from stdin...
Cache fill: 0.01% (58 bytes)

If try do write video to disk and play it:
Error while decoding frame!
[h264 @ 012b8fe0]no frame!
and so on..

$ file test.h264
test.h264: JVT NAL sequence, H.264 video @ L 40

Whats wrong?

Noted in the forums but added here for completeness. The EXIF tags set in raspicam are not appearing in the output JPG, I'm not convinced that the EXIF tags that are there are always correct. Thanks.

Hi, first post so I hope I get this right.
When using "raspistill -o myfile.jpj" there is a preview for you to position etc. before the final still is taken. However if you use the "-vf" or "-rot 180" then the preview doesn't display. There is still a delay but no picture until a brief flash as the final image is taken.
N.B. the "-vf" is very handy for just resting the camera on the table without a proper stand.

When recording video using the command "raspivid -t 5000 -o video.h264" recording after the middle of the picture has horizontal white lines flashing.

my rasp: Raspberry Pi ver B 1.0 256MB

video record:
http://qcloud.pl/panel/public.php?service=files&t=973c94d5b59d7fa13f2243ab48a37a52

Dispmanx does anti-aliasing scaling for pretty much no cost but there doesn't appear to be a way in the API to do the scaling without anti-aliasing. i.e. vc_dispmanx_element_add

GLES2 can do scaling without anti-aliasing with the GL_NEAREST setting but I'm not getting as good performance as I do with my Dispmanx backend, so using GLES2 is out of the question. I would have assumed the GPU is ultimately doing the scaling the same way for both methods.