[Elphel-support] Camogm triggered mode

[Dimitrios]

Andrey

I am not recording movies but single (or multiple - burst) images. A
recording session lasts for many hours (possibly a whole day) but
snapshots are taken at irregular times with an external trigger.
Recording continuously, even with frameskip, besides being a waste of
resources for this application, cannot last for so many hours. However,
the 32GB of CF space available in the camera may well be adequate for
autonomous camera operation, if camogm can be made to operate in trigger
mode.

Image format will be fixed, FPS need to be as high as possible to reduce
latency between trigger and actual acquisition of an image, and
autoexposure (and white balance) should work properly. I don't need to
playback the acquired images as a video stream, so I don't mind having a
corrupted MOV header if I can split the images in post-processing. The
operation of Eyesis seems close to what I need to do, although images
are taken not at a set rate but rather randomly.

I had a look at the code in camogm.c to see how skipping frames is
handled. It seems like a check for a trigger in the input-pipe and a

	return -CAMOGM_FRAME_NOT_READY;

in the absence of one can handle the basic requirement for a trigger
mode, if I read the code correctly. The place to insert it is just
before the update of the EXIF header. Do you see any problem with doing
that?

Dimitrios



On 01/11/2012 06:34 PM, Andrey Filippov wrote:
> Dimitrios,
> 
> Why do you need external triggering? To reduce number of images when the
> camera moves slowly?
> If that is correct, I would recommend you just skip some images from
> recording, keeping the sensor frame rate high. That will allow the
> autoexposure to work properly.
> 
> As for the variable rate recording with camogm - it is just prevented by
> the software to make players happy - currently when the camogm detects
> frame period change, it closes current file and starts a new one (that
> test can be easily bypassed). Actually single-frame (maybe more than one
> frame - I'll need to look in the code)  drops can be tolerated - that is
> done to continue recording when hi-res image snapshot is made.
> 
> While mov format we use does not support variable frame rate, with the
> timestamps embedded in each frame it is not critical. Actually when
> processing mov files in Eyesis we completely skip the MOV file header
> and just split the remaining of the file into individual JPEG (JP4
> actually as the JPEG format does not provide quality we need) frames.
> That also means that if MOV file is corrupted (camera records the MOV
> file header when closing the file, so power loss during recording will
> result in a file with no header) it can still be split into individual
> frame files.
>