Thanks for the response, Lambert, but it wasn't a typo. I tried it because that was the name returned by $ImagingDevices and was the $DefaultImagingDevice. Out here in the near perfect vacuum of documentation space, we have no way to know whether something is "supported" or not except to try it and see whether we can understand the response.
The only sensible way I've found so far to get an RPi camera image is to use Import as Arnoud suggested earlier in this thread and wrap it in a function that exposes the optional parameters of raspistill such as:
(* 2014-01-17 Klingener
AFAIC, this is CC0, but Wolfram has restrictions on use of RPiMma.
Mathematica function to obtain an image from the Raspberry Pi camera *)
Options[currentRPiImage] =
{Width -> 640 (* pixels *)
, Height -> 480 (* pixels default chip aspect ratio is 4:3 *)
, Rotation -> 180 (* degrees, increments of 90 *)
, Contrast -> 0 (* -100 to 100, default is 0 *)
, Brightness -> 50 (* 0 to 100, default is 50 *)
, Saturation -> 0 (* -100 to 100, default is 0 *)
, ISO -> 100 (* 100 to 800, default is 100 *)};
currentRPiImage[opts : OptionsPattern[]] :=
Import[
"!raspistill" <>
" -n" <> (* no preview *)
" -e jpg" <> (* jpg is the hardware-supported default *)
" -t 0" <> (* no delay *)
" -o -" <> (* output to stdout *)
" -rot " <> ToString[OptionValue[Rotation]] <>
" -w " <> ToString[OptionValue[Width]] <>
" -h " <> ToString[OptionValue[Height]] <>
" -co " <> ToString[OptionValue[Contrast]] <>
" -br " <> ToString[OptionValue[Brightness]] <>
" -sa " <> ToString[OptionValue[Saturation]] <>
" -ISO " <> ToString[OptionValue[ISO]]
, "JPG"]
In all of this, the most awkward feature is that there are so many ways to fail ugly - if the camera hangs, there's no way to recover except to reset the power on the board, and DeviceRead, as a blocking function, inherently fails ugly - hanging beyond <command .> and sometimes beyond kernel kill. There ought to be a way to first validate the camera state before requesting the image and second, to be able to soft reset it when it does hang. It would seem that the camera validation would be required first, because a hanging DeviceRead would prevent any way to DeviceWrite a reset to the camera (if indeed such a thing exists.) I suppose both of these could be done on the RPi in Python in a more graceful way and avoid the blocking of the Mma front end.
I haven't looked at whether Import or DeviceRead fail more gracefully than the other.
I've encountered two flavors of camera hang. One in which there's some kind of software loop, where the LED blinks on and off with a period of about a second (this one times out after a period of some minutes I haven't actually measured) and another flavor where the LED comes on and stays on, a condition requiring a power off reset.
Any ideas?
BTW, I don't know how or when I became "Updating Name."
Fred Klingener
