Difference between revisions of "Ccam.cgi"
From ElphelWiki
| Line 4: | Line 4: | ||
<nowiki>http://<camera-ip-address>/admin-bin/ccam.cgi?parameter1=value1¶meter2=value2&...</nowiki> | <nowiki>http://<camera-ip-address>/admin-bin/ccam.cgi?parameter1=value1¶meter2=value2&...</nowiki> | ||
Most parameters are persistent, so if the value is not specified it will be assumed to remain the same. | Most parameters are persistent, so if the value is not specified it will be assumed to remain the same. | ||
| − | These parameters are approximately related to the pairs of parameters passed to the main camera driver [http://cvs.sourceforge.net/viewcvs.py/elphel/camera333mjpeg/os/linux/arch/cris/drivers/cc333.c?view=markup cc333.c] that uses specific sensor driver (for [http://www.micron.com/products/imaging/products/MT9T001.html Micron sensors] - [http://cvs.sourceforge.net/viewcvs.py/elphel/camera333mjpeg/os/linux/arch/cris/drivers/mt9x001.c?view=markup | + | These parameters are approximately related to the pairs of parameters passed to the main camera driver [http://cvs.sourceforge.net/viewcvs.py/elphel/camera333mjpeg/os/linux/arch/cris/drivers/cc333.c?view=markup cc333.c] that uses specific sensor driver (for [http://www.micron.com/products/imaging/products/MT9T001.html Micron sensors] - [http://cvs.sourceforge.net/viewcvs.py/elphel/camera333mjpeg/os/linux/arch/cris/drivers/mt9x001.c?view=markup mt9x001.c]) from the user space to the driver with IOCTL. The list of these 63 driver parameters is defined in [http://cvs.sourceforge.net/viewcvs.py/elphel/camera333mjpeg/os/linux/include/asm-cris/c313a.h?view=markup c313a.h] (names staring with "P_"), most of the values come in pairs desired and actual: |
ioctl(devfd, _CCCMD(CCAM_WPARS , P_''name''), ''desired_value''); //set new value of the parameter | ioctl(devfd, _CCCMD(CCAM_WPARS , P_''name''), ''desired_value''); //set new value of the parameter | ||
''current_actual_value''=ioctl(devfd, _CCCMD(CCAM_RPARS , P_''name'' ), 0); // read current actual value - driver modifies the set value if needed to match the valid range. | ''current_actual_value''=ioctl(devfd, _CCCMD(CCAM_RPARS , P_''name'' ), 0); // read current actual value - driver modifies the set value if needed to match the valid range. | ||
Revision as of 21:10, 28 September 2005
The interface described below and all the links are for the Model 333 camera, interface for the 313 is approximately (but not completely) the same.
ccam.cgi (source - ccam.c) is currently the main interface to the camera functionality that uses GET method to pass parameters and receive the data back, so you may call it as
http://<camera-ip-address>/admin-bin/ccam.cgi?parameter1=value1¶meter2=value2&...
Most parameters are persistent, so if the value is not specified it will be assumed to remain the same. These parameters are approximately related to the pairs of parameters passed to the main camera driver cc333.c that uses specific sensor driver (for Micron sensors - mt9x001.c) from the user space to the driver with IOCTL. The list of these 63 driver parameters is defined in c313a.h (names staring with "P_"), most of the values come in pairs desired and actual:
ioctl(devfd, _CCCMD(CCAM_WPARS , P_name), desired_value); //set new value of the parameter
current_actual_value=ioctl(devfd, _CCCMD(CCAM_RPARS , P_name ), 0); // read current actual value - driver modifies the set value if needed to match the valid range.
Writing these parameters will not cause immediate action, additional write needs to be performed to make driver process the new values. Some parameters can be updated without interrupting the sensor operation and the video stream output if active (i.e. exposure time, panning without window resizing, analog gains, color saturation). Changes in other parameters (such as window size or decimation) will not be applied until the sensor is stopped.
ioctl(devfd, _CCCMD(CCAM_WPARS , P_UPDATE ), 3); // "on the fly"
ioctl(devfd, _CCCMD(CCAM_WPARS , P_UPDATE ), 1); // stop the sensor if needed, write new parameters, start sensor and wait sensor-dependent (usually 2) petentially "bad" frames before sending images through the FPGA compressor.
It is possible to read the current values of CCAM_RPARS using special request to ccam.cgi as HTML table, set of javascript assignments or xml data
There is only one copy of these kernel-space variables - they reflect current state of a single sensor and single compressor.
* _time=t (ms) will try to set current system time (if it was not set already. _stime - will always set) * if any of html, htmlr, htmll or htmlj are present will genmerate html page instead of an image * html= not present)- picture as before (or vrml) * 0 - nothing * 1 - all sensor parameters as javaScript * 2 - all sensor parameters as html * 3 - beam data as javaScript * 4 - beam data as html * 5 - state (5 -picture ready) as javaScript * 6 - state (5 -picture ready) as html * 7 - start image acquisition (option "s" or "t" should be present) * 8 - reset waiting for trigger * 10 - all sensor parameters as XML * 11 - beam data as XML * 12 - state (5 -picture ready) as XML * 13 - start image acquisition (option "s" or "t" should be present), return XML * 14 - reset waiting for trigger, return XML
* htmlr=n - Refresh each n seconds * htmll=(escape) - command executed onLoad in <body> tag * htmlj=(escape) - include *.js javaScript file
* vrmld - decimation to make a grid (>=8 for full frame) (default = 16) * vrmlb - number of individual blocks in each x/y (default=2) * vrmlm - maximal pixel. 1023 - full scale, less - increase contrast, 0 - automatic (default =1023)
* vrmli - indentation (default=1) * vrmlf - format - 0 - integer, 1 - one digit after "." (default 0) * vrmll - number of countours to build (default = 32) * vrmlo - options for isolines - e - elevated, f - flat (default=ef) * vrmlz - 0..9 output (gzip) compression level (0 - none, 1 - fastest, default - 6, best -9) * fpns - 0..3 fpga background subtraction: * 0 - none, * 1 (fine) - subtract 8-bit FPN from 10-bit pixel * 2 - multiply FPN by 2 before subtracting * 3 - multiply FPN by 4 before subtracting (full scale) * note: negative result is replaced by 0, decrease FPN data before applying for "fat 0" * fpnm - muliply by inverse sensitivity (sensitivity correction) mode: * 0 - no correction * 1 - fine (+/- 12.5%) * 2 - medium (+/- 25%) * 3 - maximal (+/- 50%) * pc - pseudo color string. Applies to monochrome images and vrml
* any of vrml* specified - vrml instead of a picture/html * * background measurement/subtraction will (now) work only with 10-bit images * gd = "digital gain" 0..5 (software) * iq = 0..100 - jpeg quality, "-1" - BMP non-compressed, "-2" - BMP RLE compressed * byr =0..3 Overwite Bayer phase shift, =4 - use calculated by driver. * vw - virtual frame width
* vh - virtual frame height
* wl = 0..1288 - left
* wt = 0..1032 - top
* ww = 1..1288 - width
* wh = 1..1032 - height
* pfh - photofinish mode strip height (0 - normal mode, not photofinish). In this mode each frame will consist of multiple
pfh-high horizontal (camera should be oriented 90 deg. to make vertical) strips, and no extra lines will be added to the frames
for demosaic
for now: +65536 - timestamp for normal frames, +131072 - timestamps for photo-finish mode
* ts - time stamp mode: 0 - none, 1 - in upper-left corner, 2 - added to the right of the image (photo-finish mode)
* fsd - frame sync delay (in lines) from the beginning of a frame (needed in photofinish mode - 3 lines?)
* dh = 1 2 4 - decimation horizontal (both) MT9T001 dh= 1,2,3,4,5,6,7,8 * dv - decimation vertical MT9T001 dv= 1,2,3,4,5,6,7,8 * bh - binning horizontal or both (MT9T001 - 1<bh<=dh<=8, has some on-chip problems) * bv - binning vertical (MT9T001 - 1<bh<=dh<=8, has some on-chip problems) * bit - pixel depth (10/4/8) * shl - shift left (FPGA in 8 and 4-bit modes) - obsolete * clk - MCLK divisor - 80MHz/(2..129) - obsolete?
* fclk - 0-127 - fpga (compressor) clock (MHz) * sclk - 0-127 - sensor clock (MHz) - will be limited by sensor driver * xtra - number of pixel-cycles needed for compressor between frames - debugging only
* gr = 0..63 - analog gain red (or mono)
* gg = 0..63 - analog gain green (or green-"red" line)
* gb = 0..63 - analog gain blue
* ggb = 0..63 - analog gain green ("blue" line - ZR32212 only)
* bg = n - calculate background 1-2-4..16 times (does not need option s/t/v)
* parameters for "instant on" quicktime
* qfr = n - number of frames to send in a quicktime clip
* qpad = % to leave for the frame size to grow (initial size 1-st frame * (100- 1.5*qpad)/100
* qdur = frame duration in 1/600 of a second
* parameters for quicktime clips (send after shooting)
* qsz = n - clip size in KB (w/o headers) (<=0 will use "instant on") - will be obsolete
* qcmd= (mandatory for videoclip)
1 - start constant compression of all acquired frames
2 - stop constant compression.
3 - acquire the whole buffer and stop
4 - read movie from buffer
6 (and 5?) - stop, then read
7 - acquire buffer, then read
* qts = t - playback time/real time
* gam=gamma - gamma correction (gamma value 0.13..10)
* pxl=00 lowest pixel value (on 8-bit scale) before table to be mapped to zero output value
* pxh=255 hioghest pixel value (on 8-bit scale) before table to be mapped to 255 output value
* fps= xx.xx - desired fps (will process to decimals)
* hist=n - read frame from "history" applies only to rereading from memory after acquisition of a clipÃÂ
n<=0 - from the end of clip (0 - last), n>0 - from the start (1 - first)
* e = 0..60000 - exposure (1 msec step) * csb= 0..710 - color saturation blue (%) * csr= 0..562 - color saturation red (%) hl - histogram top (all histogram parameters will be made even by truncating, all written derectly to FPGA - no shadows yet) ht - histogram left hw - histogram width hh - histogram height if ((vp=paramValue(gparams, "csb"))) ioctl(devfd, _CCCMD(CCAM_WPARS , P_COLOR_SATURATION_BLUE ), strtol (vp,&cp,10));
if ((vp=paramValue(gparams, "csr"))) ioctl(devfd, _CCCMD(CCAM_WPARS , P_COLOR_SATURATION_RED ), strtol (vp,&cp,10));
* opt = string of 1-character options: * h - use hardware compression * c - color mode * x - flip x * y - flip y * p - test pattern (ramp) * f - test pattern (ramp) fpga * b - buffer file * m - restart exposure after sending * if none of "st" is present - "reload mode" (all but iq and gd ignored) * s - software trigger * t - external trigger * v - video mode - will be obsolete soon (for now will only tell it is not "reload") * g - use background image - will be obsolete * q - sent quicktime movie * u - updates (some) parameters "on the fly", returns 1x1 pix dummy image * * - unlock "in use"
