[Elphel-support] Camogm triggered mode

Sebastian Pichelhofer sebastian.pichelhofer at gmail.com
Thu Jan 5 12:24:22 PST 2012


On Thu, Jan 5, 2012 at 20:19, 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.

wget http://127.0.0.1/snapfull.php -O /var/hdd/snapfull`date +%s`.jpg
does run "contained" within the camera, in the Arduino example just
the source of the command comes from the outside but you can also call
this from a php script that is inside the camera.

To automate it at certain time intervals you could run this script via
cron job or just execute php to run in a while loop that checks the
current system time and decided if it needs to write a new image to
the path where the CF cards are mounted.

Regards Sebastian


>
> 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




More information about the Support-list mailing list