[Elphel-support] Camogm triggered mode

Andrey Filippov support-list at support.elphel.com
Thu Jan 5 13:26:57 PST 2012


Dimitrios,

imgsrv is the fastest to get images over the network (i was able to get
10.4MB/sec over 100Mbps network), for the in-camera recording I would
recommend camogv with MOV format (it has the least of the CPU load).
Recordiong individual frames is not that good if you need many - even
normal computers can not open directories with many thousands of files
easily. And the camera with limited memory can run out of buffers.

When calling PHP scripts from inside the camera there are two options -
through web server (wget "http://127...") and directly. Webserver would be
faster, because several instances of php interpreter are loaded into the
memory and waiting to serve (FastCGI). Currently there are only 3 instances
of the php allowed, so in some cases (i.e. if camera is locked up waiting
for an external trigger) and there are several simultaneous requests, all
the PHP instances may be in use. It is possible to increase number of
instances in lighttpd configuration file (I did that when trying EyeOS in
the camera). To recover manually from such condition you may "killall
lighttpd" - it will restart the php instances.

Andrey

On Thu, Jan 5, 2012 at 12:19 PM, Dimitrios <dz at telemetry.gr> wrote:

> Hi Alexander and thank you for the suggestions.
> I hope I'm not wasting the list's bandwidth with a flood of questions.
>
> I see that the Arduino code uses
>
>   wget http://127.0.0.1/snapfull.php
>
> I am already using imgsrv very satisfactorily for storing the images
> outside the camera (a 90 degree Hammer). I was looking for ways to store
> the images to the internal 2x16GB CF cards so that the whole process be
> contained within the camera.
>
> The triggered mode sounds interesting, but if the camera is unresponsive
> while waiting, then that does not fit the purpose.
>
> I was thinking of modifying camogm to do what you describe for triggered
> mode. Here is a small description of it (rather ambiguous):
>
> ----------------------------------------------------------
> Desired functionality and draft camogm API extension:
>
> a. Triggered image/burst/stream recording to disk.
> b. User defined filename or tag of the stored image. If the frame is
> stored in a container then the tag could be set in the EXIF data for
> that frame.
>
> This allows an external application/signal to save a frame/burst of
> frames to disk on demand rather than continuously, either in an Ogg or
> Mov container or as individual files. Communication with camogm is
> through camogm's input pipe.
>
> The user will have a new 'trigger' camogm command with the following
> options:
>
> 1.      Trigger single snapshot write to disk, with optional user filename
> or
> tag:
>
>        echo "trigger name=<filename or tag>" > /path/to/input_pipe
>
> 2.      Trigger burst snapshot write to disk, with optional user filename
> or
> tag and size of burst [default 5]:
>
>        echo "trigger name=<filename or tag> burst=5"
>
>        Filenames or tags for each image in the burst are created by
> appending
> an auto-incrementing integer to the filename/tag given by the user, or
> the default filename created by camogm
>
> 3. Trigger duration limited recording to disk, with optional user
> filename or tag:
>
>        echo "trigger name=<filename or tag> duration=5.32"
>
>        Filenames or tags for each image are created by appending an
> auto-incrementing integer to the filename/tag given by the user, or the
> default filename created by camogm.
>
> -----
>
> So, I was thinking of parsing the new command and then patch camogm at
> some place where it's waiting for the next frame to come but prevent it
> from saving unless a trigger is seen in the input pipe. After that, it
> goes again into waiting for a trigger. The process starts and ends as
> usual with the start/stop camogm commands.
>
> The good thing with open source software is that you can scratch your
> own itch. The difficulty is knowing where to start, and the learning
> curve here is steep, so any suggestions are very welcome  :-)
>
> Best regards
> Dimitrios
>
>
> On 01/05/2012 07:10 PM, Alexandre Poltorak wrote:
> > Hi Dimitrios,
> >
> > Please take a look on http://wiki.elphel.com/index.php?title=Arduino
> >
> > This method have a big latency for executing the command. You can use
> > http://wiki.elphel.com/index.php?title=Circbuf and
> > http://wiki.elphel.com/index.php?title=Imgsrv to get precisely the image
> > that was acquired during the trigger.
> >
> > Also in triggered / slave mode the camera will record frames on external
> > trigger to the internal HDD using camogm. You will get MOV files with
> > triggered frames. The problem of this method is that between triggers
> > the camera is completely unresponsive. (so you can not even do a
> > network preview or telnet)
> >
> > Another idea is to record every single frames using camogm and only mark
> > images on trigger inside EXIF for later processing.
> >
> > Best regards.
> > Polto
>
> _______________________________________________
> Support-list mailing list
> Support-list at support.elphel.com
> http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20120105/2ab7c002/attachment-0002.html>


More information about the Support-list mailing list