[Elphel-support] Fwd: ccam.cgi

[Alexandre Poltorak]

Simon,

With 8.x firmware you can use IMGSRV to download images from the camera
using HTTP. This server does not provide any control over the sensor or FPGA
compressor operation, its only purpose is to get data acquired to the
(currently 19 MB) circular buffer in the system RAM. The imgsrv makes use of
the new functionality of the
/dev/circbuf<http://wiki.elphel.com/index.php?title=Circbuf>driver
providing it with a convenient web front end. It serves JPEG images
(with Exif data attached) as well as metadata and
circbuf<http://wiki.elphel.com/index.php?title=Circbuf>status
formatting output as the xml files.

To simply get the last compressed image you can download
http://192.168.0.9:8081/bimg

For more information about imgsrv:
http://wiki.elphel.com/index.php?title=Imgsrv

To configure the camera in a specific configuration at boot you can use
http://192.168.0.9/autocampars.php

Alexandre


2009/12/28 Simon Zuñiga <ccc_mindsz at yahoo.com>

> Andrey,
>
> I'm currently working on a system that will call the camera from a computer
> and either retrieve a picture from a file or take a new picture and store
> it.
>
> For this, ccam.cgi was perfect, because I only needed to call (from a
> Visual Basic program) http://<ip>/ccam.cgi?<options> and I'd retrieve the
> picture that was sent back by the camera.
>
> Is there a way to do something like this with the new 8.x software?
>
> Thanks,
> Simon
>
> --- On *Wed, 12/23/09, Andrey Filippov <andrey at elphel.com>* wrote:
>
>
> From: Andrey Filippov <andrey at elphel.com>
> Subject: Fwd: [Elphel-support] ccam.cgi
> To: "Simon Zuñiga" <ccc_mindsz at yahoo.com>, support-list at support.elphel.com
> Date: Wednesday, December 23, 2009, 4:28 PM
>
>
> Hi Simon,
>
> Thank you for asking about ccam.cgi compatibility.
>
> Can you please describe what exact functionality do you need from ccam.cgi?
> Maybe it is possible to modify your client software (and/or add some PHP
> scripts to the camera) and use the current camera firmware?
>
> You see, the ccam.cgi was rather tightly connected to the camera drivers,
> together they were design to get parameters and serve images over the
> network
>
> ccam.cgi used traditional approach:
> 1 - get user parameters
> 2 - reprogram the sensor and/or compressor ( if the new parameters were
> specified). In Most cases that required a complete reset of the internal
> acquisition pipeline
> 3 - wait for the new image to appear in the buffer
> 4 - send image to the client (through the web server)
>
> Unfortunately such approach was limiting the update rate - the
> re-programming the sensor and camera acquisition modules required purging
> the acquisition pipeline (starting with the sensor latency) ,  so several
> (3-4) frames were lost, and the camera web server was locked for the
> duration of the steps 1..4 for other requests.
>
>  With the current (8.x) software we used a different method (see article in
> LinuxDevices -
> http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Elphel-camera-under-the-hood-from-Verilog-to-PHP/<http://www.linuxfordevices..com/c/a/Linux-For-Devices-Articles/Elphel-camera-under-the-hood-from-Verilog-to-PHP/>), trying to minimize number of frames lost to re-programming.  Additionally
> we sped up the step 4, images are now served by a dedicated fast image
> server - imgsrv (listening on the camera port 8081), it gets up to
> ~10.4MB/sec over the 100mbps network.
>
> Current drivers are aware of the sensor and compressor latencies for
> various parameters, they change program sensor and  change the internal
> parameters in sequence that match the image pipeline, it is possible to
> schedule parameter change in the future. The pipeline approach made "current
> parameters" non-applicable to the camera - for example "current exposure" or
> "current image width" can be different in
>  - i2c command queue (data to be sent to the sensor at the frame boundary
>  - for the current frame being acquired in the sensor
>  - for the frame being read in to the video buffer
>  - for the frame being compressed in FPGA
>  - for multiple frames being stored in the circular buffer, ready to be
> recorded to the disk or to be sent over the network - as video or individual
> images
>
> This is why we had to change the camera programming interface. In order to
> combine interface flexibility and high performance we decided to abandon any
> fixed API (it would either limit the camera functionality or soon grow too
> big and slow) and use efficient integration of the PHP running in the camera
> - it uses fastCGI and custom extension to deal with camera-specific
> functionality. We have several examples of PHP scripts that control camera
> parameters through the web interface, imgsrv (http://camera_ip:8081) can
> be used to acquire individual images.
>
> Of course it is possible to install the legacy (7.x) firmware to the camera
> - the one that still has ccam.cgi, but I hope it should be not that
> difficult to migrate to use the newer functionality, please don't hesitate
> to ask particular questions about it. The same functionality will be
> available in the next model 373 camera too, there will be no legacy ccam.cgi
> there.
>
> Andrey
>
>
>
>
> _______________________________________________
> 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/20091228/1e3481fe/attachment-0002.html>