Imgsrv - Revision history

Andrey.filippov: /* imgsrv - Simple and fast HTTP server to provide still images and metadata acquired by the camera */

2017-01-27T19:42:46Z

imgsrv - Simple and fast HTTP server to provide still images and metadata acquired by the camera

← Older revision		Revision as of 19:42, 27 January 2017
Line 8:		Line 8:
	=== imgsrv usage ===		=== imgsrv usage ===

	imgsrv listens to the camera http port (~~currently~~ 8081) and parses the rest of the ~~url~~ string as a series of commands, ~~i.e.~~:		====Update for NC393 series cameras that have 4 sensor ports:====

			Default imgsrv ports are '''2323, 2324, 2325 and 2326''' instead of single '''8081''' that is valid for NC353.

			imgsrv listens to the camera http port (8081 for the nc353 series) and parses the rest of the URL string as a series of commands, for example:
	<nowiki>http://<camera_ip>:8081/towp/save</nowiki>		<nowiki>http://<camera_ip>:8081/towp/save</nowiki>
	<nowiki>http://<camera_ip>:8081/torp/wait/img/next/save</nowiki>		<nowiki>http://<camera_ip>:8081/torp/wait/img/next/save</nowiki>

	~~'''Update for NC393 series cameras that have 4 sensor ports:'''~~

	~~Default imgsrv ports are '''2323, 2324, 2325 and 2326''' instead of single '''8081''' that is valid for NC353.~~

	The above command will be interpreted as the following sequences:		The above command will be interpreted as the following sequences:

Andrey.filippov: /* imgsrv usage */

2017-01-27T19:39:55Z

imgsrv usage

← Older revision		Revision as of 19:39, 27 January 2017
Line 14:		Line 14:
	'''Update for NC393 series cameras that have 4 sensor ports:'''		'''Update for NC393 series cameras that have 4 sensor ports:'''

	Default imgsrv ports are '''2323, 2324, 2325 and 2326''' instead of '''8081''' that is valid for NC353.		Default imgsrv ports are '''2323, 2324, 2325 and 2326''' instead of single '''8081''' that is valid for NC353.

	The above command will be interpreted as the following sequences:		The above command will be interpreted as the following sequences:

Andrey.filippov: /* imgsrv usage */

2017-01-27T19:39:11Z

imgsrv usage

← Older revision		Revision as of 19:39, 27 January 2017
Line 12:		Line 12:
	<nowiki>http://<camera_ip>:8081/torp/wait/img/next/save</nowiki>		<nowiki>http://<camera_ip>:8081/torp/wait/img/next/save</nowiki>

	Update for NC393 series cameras that have 4 sensor ports:		'''Update for NC393 series cameras that have 4 sensor ports:'''
	Default imgsrv ports are 2323, 2324, 2325 and 2326 instead of 8081 that is valid for NC353.
			Default imgsrv ports are '''2323, 2324, 2325 and 2326''' instead of '''8081''' that is valid for NC353.

	The above command will be interpreted as the following sequences:		The above command will be interpreted as the following sequences:

Andrey.filippov: /* imgsrv usage */

2017-01-27T19:37:27Z

imgsrv usage

← Older revision		Revision as of 19:37, 27 January 2017
Line 11:		Line 11:
	<nowiki>http://<camera_ip>:8081/towp/save</nowiki>		<nowiki>http://<camera_ip>:8081/towp/save</nowiki>
	<nowiki>http://<camera_ip>:8081/torp/wait/img/next/save</nowiki>		<nowiki>http://<camera_ip>:8081/torp/wait/img/next/save</nowiki>

			Update for NC393 series cameras that have 4 sensor ports:
			Default imgsrv ports are 2323, 2324, 2325 and 2326 instead of 8081 that is valid for NC353.

	The above command will be interpreted as the following sequences:		The above command will be interpreted as the following sequences:

Oleg at 00:33, 31 May 2016

2016-05-31T00:33:09Z

← Older revision		Revision as of 00:33, 31 May 2016
Line 77:		Line 77:
	\|-		\|-
	\|}		\|}

			[[Category:353]]

Dimitrios: Updated imgsrv commands according to the imgsrv help page

2012-02-17T01:49:40Z

Updated imgsrv commands according to the imgsrv help page

← Older revision		Revision as of 01:49, 17 February 2012
Line 33:		Line 33:
	*'''img''' - send image at the current pointer (if it is the first command - use last acquired image - implied '''last''' command), if no image is available and the current pointer server will not wait for the image to be acquired (see '''wait ''' below) but rather immediately return 1x1 GIF image to the client;		*'''img''' - send image at the current pointer (if it is the first command - use last acquired image - implied '''last''' command), if no image is available and the current pointer server will not wait for the image to be acquired (see '''wait ''' below) but rather immediately return 1x1 GIF image to the client;
	*'''bimg''' -same as above, but the whole image is stored in the camera outside of the circbuf before being sent to the client. It makes it safe from being overwritten by the new frames acquired by the camera. This option is useful when the camera is accessed from outside of the fast LAN over the slow network, it is safer and is recommended if the full frame rate is not required;		*'''bimg''' -same as above, but the whole image is stored in the camera outside of the circbuf before being sent to the client. It makes it safe from being overwritten by the new frames acquired by the camera. This option is useful when the camera is accessed from outside of the fast LAN over the slow network, it is safer and is recommended if the full frame rate is not required;
	*'''~~mimg~~''' ~~- send a stream of images at the current pointer as MJPEG (HTTP header~~, ''~~Content-type: multipart/x-mixed-replace~~''~~); like~~ '''~~img~~''' ~~but~~ for ~~an MJPEG stream.~~		*'''simg''', '''sbimg''' - similar to img, bimg but will imemdiately suggest to save instead of opening image in the browser
	*'''~~mbimg~~''' - same as above, ~~but the images are stored in the camera outside of the circbuf before being sent to the client.~~		*'''mimg[n]''' - send images as a multipart JPEG (all commands after will be ignored), possible to specify optional fps reduction i.e. mimg4 - skip 3 frames for each frame output (1/4 fps)
			*'''bmimg[n]''' - same as above, buffered
	*'''meta''' - send XML-formated metadata of the current frame instead of the image;		*'''meta''' - send XML-formated metadata of the current frame instead of the image;
	*'''pointers''' - send XML-formatted data about the circbuf frame pointers.		*'''pointers''' - send XML-formatted data about the circbuf frame pointers.
			*'''frame''' - return current frame number as plain text
			*'''wframe''' - wait for the next frame sync, return current frame number as plain text

	Next commands are designed on top of [[Circbuf\|circbuf]] control commands:		Next commands are designed on top of [[Circbuf\|circbuf]] control commands:

Dimitrios at 01:13, 11 February 2012

2012-02-11T01:13:11Z

← Older revision		Revision as of 01:13, 11 February 2012
Line 33:		Line 33:
	*'''img''' - send image at the current pointer (if it is the first command - use last acquired image - implied '''last''' command), if no image is available and the current pointer server will not wait for the image to be acquired (see '''wait ''' below) but rather immediately return 1x1 GIF image to the client;		*'''img''' - send image at the current pointer (if it is the first command - use last acquired image - implied '''last''' command), if no image is available and the current pointer server will not wait for the image to be acquired (see '''wait ''' below) but rather immediately return 1x1 GIF image to the client;
	*'''bimg''' -same as above, but the whole image is stored in the camera outside of the circbuf before being sent to the client. It makes it safe from being overwritten by the new frames acquired by the camera. This option is useful when the camera is accessed from outside of the fast LAN over the slow network, it is safer and is recommended if the full frame rate is not required;		*'''bimg''' -same as above, but the whole image is stored in the camera outside of the circbuf before being sent to the client. It makes it safe from being overwritten by the new frames acquired by the camera. This option is useful when the camera is accessed from outside of the fast LAN over the slow network, it is safer and is recommended if the full frame rate is not required;
	*'''mimg''' - send a stream of images at the current pointer as MJPEG ('''Content-type: multipart/x-mixed-replace'''); like '''img''' but for an MJPEG stream.		*'''mimg''' - send a stream of images at the current pointer as MJPEG (HTTP header, ''Content-type: multipart/x-mixed-replace''); like '''img''' but for an MJPEG stream.
	'''mbimg''' - same as above, but the images are stored in the camera outside of the circbuf before being sent to the client. '''meta''' - send XML-formated metadata of the current frame instead of the image;		*'''mbimg''' - same as above, but the images are stored in the camera outside of the circbuf before being sent to the client.
			*'''meta''' - send XML-formated metadata of the current frame instead of the image;
	*'''pointers''' - send XML-formatted data about the circbuf frame pointers.		*'''pointers''' - send XML-formatted data about the circbuf frame pointers.

Dimitrios: Added undocummented commands mimg and mbimg

2012-02-11T01:10:33Z

Added undocummented commands mimg and mbimg

← Older revision		Revision as of 01:10, 11 February 2012
Line 33:		Line 33:
	*'''img''' - send image at the current pointer (if it is the first command - use last acquired image - implied '''last''' command), if no image is available and the current pointer server will not wait for the image to be acquired (see '''wait ''' below) but rather immediately return 1x1 GIF image to the client;		*'''img''' - send image at the current pointer (if it is the first command - use last acquired image - implied '''last''' command), if no image is available and the current pointer server will not wait for the image to be acquired (see '''wait ''' below) but rather immediately return 1x1 GIF image to the client;
	*'''bimg''' -same as above, but the whole image is stored in the camera outside of the circbuf before being sent to the client. It makes it safe from being overwritten by the new frames acquired by the camera. This option is useful when the camera is accessed from outside of the fast LAN over the slow network, it is safer and is recommended if the full frame rate is not required;		*'''bimg''' -same as above, but the whole image is stored in the camera outside of the circbuf before being sent to the client. It makes it safe from being overwritten by the new frames acquired by the camera. This option is useful when the camera is accessed from outside of the fast LAN over the slow network, it is safer and is recommended if the full frame rate is not required;
	*'''meta''' - send XML-formated metadata of the current frame instead of the image;		*'''mimg''' - send a stream of images at the current pointer as MJPEG ('''Content-type: multipart/x-mixed-replace'''); like '''img''' but for an MJPEG stream.
			'''mbimg''' - same as above, but the images are stored in the camera outside of the circbuf before being sent to the client. '''meta''' - send XML-formated metadata of the current frame instead of the image;
	*'''pointers''' - send XML-formatted data about the circbuf frame pointers.		*'''pointers''' - send XML-formatted data about the circbuf frame pointers.

Andrey.filippov: /* Overview */

2008-03-11T02:14:03Z

Overview

← Older revision		Revision as of 02:14, 11 March 2008
Line 2:		Line 2:

	=== Overview ===		=== Overview ===
	This server was developed to increase the transfer rate of individual images acquired by the Elphel 353 series cameras as the CGI (and even fastCGI applications) connected through the universal web servers ([http://www.boa.org Boa], included with Axis SDK, currently on the default port 80 in camera and [http://www.lighttpd.net/ lighttpd] - now used in Elphel cameras together with php in fast CGI mode, port 81) failed to reach the top speed of the 100mbps network. Specialized imgsrv is connected through a different port (currently listens to 8081) and writes GET responses directly to the socket (reading image data from the [[Circbuf\|circbuf]] using zero-copy memory mapping mmap), reaching 9-10MB/sec - virtually the full bandwidth of the network. 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. It is intended to have the functionality similar to the camera video streamers that also deal with the data already being acquired to the system buffer to be used when individual images are needed rather than the continuous video stream .		This server was developed to increase the transfer rate of individual images acquired by the Elphel 353 series cameras as the CGI (and even fastCGI applications) connected through the universal web servers ([http://www.boa.org Boa], included with Axis SDK, currently on the default port 80 in camera and [http://www.lighttpd.net/ lighttpd] - now used in Elphel cameras together with php in fast CGI mode, port 81) failed to reach the top speed of the 100mbps network. Specialized imgsrv is connected through a different port (currently listens to 8081) and writes GET responses directly to the socket (reading image data from the [[Circbuf\|circbuf]] using zero-copy memory mapping mmap), reaching 9-10MB/sec - virtually the full bandwidth of the network. '''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'''. It is intended to have the functionality similar to the camera video streamers that also deal with the data already being acquired to the system buffer to be used when individual images are needed rather than the continuous video stream .

	The imgsrv makes use of the new functionality of the [[Circbuf\|/dev/circbuf]] driver providing it with a convenient web front end. It serves JPEG images (with Exif data attached) as well as metadata and [[Circbuf\|circbuf]] status formatting output as the xml files.		The imgsrv makes use of the new functionality of the [[Circbuf\|/dev/circbuf]] driver providing it with a convenient web front end. It serves JPEG images (with Exif data attached) as well as metadata and [[Circbuf\|circbuf]] status formatting output as the xml files.

Andrey.filippov: /* imgsrv usage */

2008-02-13T00:51:45Z

imgsrv usage

← Older revision		Revision as of 00:51, 13 February 2008
Line 31:		Line 31:
	First group of the commands generates response data sent to the client, they are mutually exclusive and can appear only once in the command line (url). Each subsequent instances of such commands will be ignored. If none of the response-generating commands appear in the URL (but the url is not empty) the server will generate a minimalistic response - 1x1 pixel image. The commands of that group are the following:		First group of the commands generates response data sent to the client, they are mutually exclusive and can appear only once in the command line (url). Each subsequent instances of such commands will be ignored. If none of the response-generating commands appear in the URL (but the url is not empty) the server will generate a minimalistic response - 1x1 pixel image. The commands of that group are the following:

	*'''img''' - send image at the current pointer (if it is the first command - use last acquired image - implied '''last''' command), if no image is available and the current pointer server will not wait ~~fro~~ the image to be acquired (see '''wait ''' below) but rather immediately return 1x1 GIF image to the client;		*'''img''' - send image at the current pointer (if it is the first command - use last acquired image - implied '''last''' command), if no image is available and the current pointer server will not wait for the image to be acquired (see '''wait ''' below) but rather immediately return 1x1 GIF image to the client;
	*'''bimg''' -same as above, but the whole image is stored in the camera outside of the circbuf before being sent to the client. It makes it safe from being overwritten by the new frames acquired by the camera. This option is useful when the camera is accessed from outside of the fast LAN over the slow network, it is safer and is recommended if the full frame rate is not required;		*'''bimg''' -same as above, but the whole image is stored in the camera outside of the circbuf before being sent to the client. It makes it safe from being overwritten by the new frames acquired by the camera. This option is useful when the camera is accessed from outside of the fast LAN over the slow network, it is safer and is recommended if the full frame rate is not required;
	*'''meta''' - send XML-formated metadata of the current frame instead of the image;		*'''meta''' - send XML-formated metadata of the current frame instead of the image;