[Elphel-support] Fwd: ccam.cgi

[Simon Zuñiga]

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/ ), 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







      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20091228/849ec1c7/attachment-0002.html>