Remote display of Pi Camera

The preview is an overlay and is handled entirely by the GPU. It works the same whether you're running a desktop or not. As such it's hard to remote it.

There are other issues, the preview may not be the same as the still image you get - different field of view.  There was supposedly a fix for that, but I don't know if it's available yet.

Streaming video isn't the answer either as that has yet another different field of view.

What I do is to have the Pi save images to an NFS share and view them from that machine, it means you get to see exactly what you'll get.

It's also worth noting that if you ask raspistill for a 1920x1080 image using the -w and -h options it's not simply a crop of the 2592x1944 native resolution and will have yet another different field of view as it scales somewhat the full image to fit your request.

I've not tried the -roi settings yet, but those would seem to crop the raw sensor resolution before scaling what's left to the -w & -h settings.

Anyway, what you really want to try is to grab your still image using the settings you expect to use, then view that on a decent screen elsewhere.

I'll be interested to hear how you get on with your project and what settings you use.  I'm doing some timelapse stuff and have been trying out various combinations, but have come to the conclusion that in daylight I'll be using spot or average metering and iso 100, other metering modes provide darker images of the same scene.  As it's a fixed iris lens, increasing ISO in daylight only seems to give a hint to the GPU to use a faster shutter speed which gives darker images...   At some lower light level it starts to become advantageous to increase the ISO, so I'm adding an ambient light sensor so that I can start to work out when to do that.

With current firmware it seems to be a bit of a guessing game what results you can expect for certain settings, so I just wrote a simple script to cycle through them quickly so I can look at the images and pick what's working.

Selsinork

Thanks for the reply.

As such it's hard to remote it.

I came to that conclusion, but not having played much, and lacking any real Linux skills, needed to check.

What I do is to have the Pi save images to an NFS share and view them from that machine

I figured that was what I was going to need to do.

increasing ISO in daylight only

I read somewhere on the RPi.org site that the ISO doesn't seem to work, and it was stuck on  a list to check.

In the brief check I did (inside) it didin't seem to function like I thought it should ... but I didn't try it in sunlight.

Thanks for the other suggestions.

Mark

Mark Beckett wrote:

 

I read somewhere on the RPi.org site that the ISO doesn't seem to work, and it was stuck on  a list to check.

In the brief check I did (inside) it didin't seem to function like I thought it should ... but I didn't try it in sunlight.

ISO setting was disabled until raspistill 1.2 where it's been enabled again.  You probably need to do the rpi-update dance to get the latest kernel/firmware/apps.

With 1.1 ISO defaulted to 100 which gives fairly good results all round, in 1.2 it defaults to 400, nothing necessarily wrong with that, but the results are quite a bit different

I'm by no means a photography expert, but various things currently don't work in the ways you'd expect even when comparing to a simple point & shoot digital camera..

Maybe I'm being unfair, but it seems that the interactions between the settings are not intuitive and don't always do what you'd expect, or they appear to operate differently depending on what the light level is.  So there's a bit of second guessing around how the settings you provide interact with the algorithms in the firmware.

Keep us posted on how you get on..

You probably need to do the rpi-update

Cheers, I'll do it tonight.

400 ISO is typically grainy, and in the old film days was because the grains in the film had to be larger to be more sensitive.

I noted somewhere that -10 ev was equivalent to -3 stops (each stop is half the light), and this was to allow for 1/2 or 1/3 stop changes.

Now that I've got it to a state of not requiring the screen, I'll move it and try a few pics facing outside, which will allow a few setting tests.

I have a nice bright surface to face it at, so it will at least simulate the snow covered surfaces.

Thanks

Mark

You probably need to do the rpi-update

Cheers, I'll do it tonight.

400 ISO is typically grainy, and in the old film days was because the grains in the film had to be larger to be more sensitive.

I noted somewhere that -10 ev was equivalent to -3 stops (each stop is half the light), and this was to allow for 1/2 or 1/3 stop changes.

Now that I've got it to a state of not requiring the screen, I'll move it and try a few pics facing outside, which will allow a few setting tests.

I have a nice bright surface to face it at, so it will at least simulate the snow covered surfaces.

Thanks

Mark

Mark Beckett wrote:

 

400 ISO is typically grainy, and in the old film days was because the grains in the film had to be larger to be more sensitive.

I noted somewhere that -10 ev was equivalent to -3 stops (each stop is half the light), and this was to allow for 1/2 or 1/3 stop changes.

Experimentation suggests that upping the ISO adds noise to the image, in reasonable daylight it doesn't seem to have any other effect and ISO 100 will give a better looking image. If it's overcast it'll probably make the image darker, but that seems mostly due to the faster shutter speed the increased ISO lets the GPU use.

the -ev settings seem to go in perceptible steps of two, add 1 and there's little or no noticeable difference, add two and there is.  Certain combinations don't seem to work together, for example with ISO 800 in reasonably dark conditions, the -ev settings seem to have no effect.  Also if you use -ex off then none of the other settings seem to do much and you get, in daylight, what appears to be the equivalent of average metering, iso 100, -ev 10 and a shutter speed of 1/100.

You're sure to have some interesting times ahead testing different settings to see what works.

I've just come across the first slightly strange situation with the camera where raspistill would start up and then seemingly sit there doing nothing. The Pi was otherwise working normally, nothing obviously wrong in the logs etc. Ctrl-C kills off raspistill quickly without resort to more drastic measures.

Looking in the GPU log with "vcdbg log msg" revealed this message:

mmal: mmal_port_event_send: event lost on port 1,0 (buffer header callback not defined)

I've read various stuff in the RPF forums where people have had their Pi lock up completely or loose the camera, and I'd had problems with long video captures on previous firmware.

However I'd already taken something like 100k full images with this over several days since it's previous reboot (timelapse stuff), so had assumed those issues were solved, but it seems not.

Fixed it with a simple reboot, unlike some of the other things I've read I didn't need a full power cycle.  It does seem that if you want reliable images you'll have to factor in something to check the images are created, look sane, and if not, have the ability to reboot the Pi, or possibly to power cycle it.

It seems likely that issues like this will get fixed in time, the camera is still relatively new after all, but in the meantie some defensive coding seems advisable.

Selsinork

That a very good heads up ...thanks.

In my plan, I intended to have one of the GPIO signal the RPi was completed, before allowing the controller to shut it down.

Checking for this error, and forcing it to be shutdown will effectively resolve it.

If the RPi is locked up though, this won't fix it, so I need to also have the controller check for completion within x and pull the plug anyway.

It is obviously random as you've found, and no doubt your investigation is helpful to solve the underlying issue.

Cheers

Mark

In searching for some other snippets, I ran across this blog.

Its for implementing and controlling the built-in watchdog.

http://rpihouse.wordpress.com/2012/12/06/watching-the-dog/

It also includes ways to check the load to ensure that a task isn't hogging it.

Cheers

Mark

I'd advise a little bit of caution on relying on the load average feature of the watchdog prog.

The load average is an imprecise measurement and deliberately so.  It also may not really be measuring what you'd expect.  It's an average of the number of processes either running or waiting for IO to complete. This means that you can have a high load average when you have lots of processes waiting on a slow storage device, while at the same time having a CPU utilisation that's very low and have little or no impact on system performance (assuming that slow storage device isn't your root filesystem).

There's an obvious link to the Pi here, the SDcard is a slow storage device.

Leaving that aside for a minute, the problem I saw with raspistill doing nothing appeared to be a problem on the GPU, or in the communication between raspistill and the GPU. It left both load average and cpu utilisation down at around zero, so the watchdog would never trigger.

Watchdog timers are useful to some degree, and in some situations, but not all.   Compaq used to do a thing in their servers called ASR, or Automatic Server Recovery, essentially a watchdog done in hardware/firmware such that the OS didn't need to know about it. Most people tried it once, then disabled it forevermore on all current and any future systems as it could be a bit trigger happy. Maybe it was fixed later, but it's reputation had been destroyed by then.

What I've also found over the years is that the times when you really need a watchdog tends to be the times where the hardware has somehow got itself into a mess and the onboard watchdog can't reset it. In these cases you tend to need to hard power cycle the machine to get it back, usually meaning you need to send an engineer out to do that manually.  So I much prefer the idea of a watchdog that's in an external box, is connected to the system being watched via serial usb etc for it's heartbeat, and that it's able to physically interrupt power to the watched system when needed. Of course, if the watchdog itself is a microcontroller or some such it probably needs it's own watchdog too

In your case as you're building a power controller for other reasons, I'd suggest that for reliability you have that do the watchdog duties too.

Selsinork

Thanks for that.

I have always preferred external watchdogs, for the reasons you've outlined.

In your observation, I presume the other RPi functions were non responsive?

My plan was to have the controller initiate a picture via the GPIO, and the RPi signal that it had been done by checking for the file and pulsing a pin on the GPIO.

In theory this should be a crude RPi watchdog, where the controller can then 'pull the plug' on the RPi if it doesn't respond after xx secs.

I think I'll plan for a hardware watchdog in the power monitor/switch, which the controller can utilise. (cheers )

I have one planned for the new Tow Trip controllers that I'll tackle after this project.

The  current design uses two micros, and sends serial data to the 2nd one  which checks the data and pulses its output to hold a relay on ... hence  fail to safety, but I need some extra functionality, and the KL25z are  looking like a very good alternative.

Thanks for the advice.

Mark