Ccam.cgi - Revision history

Andrey.filippov: /* Frame size and resolution */

2008-02-24T06:08:31Z

Frame size and resolution

← Older revision		Revision as of 06:08, 24 February 2008
Line 68:		Line 68:
	{\| border="1" cellpadding="2"		{\| border="1" cellpadding="2"
	\|-		\|-
	\| Key \|\| Value range (3MPix sensor)\|\| Description \|\| Working? \|\|"on the fly"? \|\|Notes		\| Key \|\| Value range (3MPix sensor)\|\| Description \|\| Working? \|\|"on the fly"? \|\|Notes
	\|-		\|-
	\| ww \|\| 2..2048 \|\| Sensor active window width (before decimation) \|\| Y \|\| N \|\|1		\| ww \|\| 2..2048 \|\| Sensor active window width (before decimation) \|\| Y \|\| N \|\| 1
	\|-		\|-
	\| wh \|\| 2..1536 \|\| Sensor active window height (before decimation) \|\| Y \|\| N \|\|1		\| wh \|\| 2..1536 \|\| Sensor active window height (before decimation) \|\| Y \|\| N \|\| 1
	\|-		\|-
	\| wl \|\| 0..(2047-ww) \|\| Sensor active window left margin (before decimation) \|\| Y \|\| Y \|\| 2		\| wl \|\| 0..(2047-ww) \|\| Sensor active window left margin (before decimation) \|\| Y \|\| Y \|\| 2
	\|-		\|-
	\| wt \|\| 0..(1535-wh) \|\| Sensor active window top margin (before decimation) \|\| Y \|\| Y \|\| 2		\| wt \|\| 0..(1535-wh) \|\| Sensor active window top margin (before decimation) \|\| Y \|\| Y \|\| 2
	\|-		\|-
	\| dh \|\| 1..8 \|\| Horizontal decimation (resoulution/image size reduction) \|\| Y \|\| N \|\| 3		\| dh \|\| 1..8 \|\| Horizontal decimation (resoulution/image size reduction) \|\| Y \|\| N \|\| 3
	\|-		\|-
	\| dv \|\| 1..8 \|\| Vertical decimation (resoulution/image size reduction) \|\| Y \|\| N \|\| 3		\| dv \|\| 1..8 \|\| Vertical decimation (resoulution/image size reduction) \|\| Y \|\| N \|\| 3
	\|-		\|-
	\|}		\|}

Andrey.filippov at 00:36, 17 October 2007

2007-10-17T00:36:41Z

← Older revision		Revision as of 00:36, 17 October 2007
Line 1:		Line 1:
	== overview ==		== overview ==
	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.		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.

			''UPDATE: Now it is for the 353 camera, current code is in [http://elphel.cvs.sourceforge.net/elphel/elphel353-7.1/apps/ccam/ccam.c?view=markup here]''

	ccam.cgi (source - [http://cvs.sourceforge.net/viewcvs.py/elphel/camera333mjpeg/333/apps/ccam/ccam.c?view=markup 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		ccam.cgi (source - [http://cvs.sourceforge.net/viewcvs.py/elphel/camera333mjpeg/333/apps/ccam/ccam.c?view=markup 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

Andrey.filippov: /* opt */

2007-08-27T08:15:25Z

opt

← Older revision		Revision as of 08:15, 27 August 2007
Line 30:		Line 30:
	\|-		\|-
	\| c \|\| Consider sensor to be the color one, if not - skip Bayer color filters processing \|\| Y		\| c \|\| Consider sensor to be the color one, if not - skip Bayer color filters processing \|\| Y
			\|-
			\| j \|\| Special color mode (jp4) - Pixels in each 16x16 macroblock are rearranged to separate Bayer colors in individual 8x8 blocks, then encoded as monochrome. De-mosaic will be applied during post-processing on the host PC. If both "j" and "c" are present, "c" is ignored \|\| Y
	\|-		\|-
	\| x \|\| Flip (mirror) image horizontally (uses in-sensor capabilities) \|\| Y		\| x \|\| Flip (mirror) image horizontally (uses in-sensor capabilities) \|\| Y
Line 60:		Line 62:

	----		----

	=== Frame size and resolution ===		=== Frame size and resolution ===
	{\| border="1" cellpadding="2"		{\| border="1" cellpadding="2"

Khlut: /* below is yet unedited text from ccam.c comments */ garbage deleted

2006-06-24T18:19:01Z

below is yet unedited text from ccam.c comments: garbage deleted

← Older revision		Revision as of 18:19, 24 June 2006
Line 343:		Line 343:
	* vrmlz - 0..9 output (gzip) compression level (0 - none, 1 - fastest, default - 6, best -9)		* vrmlz - 0..9 output (gzip) compression level (0 - none, 1 - fastest, default - 6, best -9)

	* hist=n - read frame from "history" applies only to rereading from memory after acquisition of a ~~clipÃÂ~~		* 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)		n<=0 - from the end of clip (0 - last), n>0 - from the start (1 - first)

Pfavr: /* Image Quality, Gamma correction, Color Saturation */ tried making it more clear and yes: I understand it now thanks!

2005-10-27T20:58:49Z

Image Quality, Gamma correction, Color Saturation: tried making it more clear and yes: I understand it now thanks!

← Older revision		Revision as of 20:58, 27 October 2005
Line 187:		Line 187:
	\|}		\|}
	# Standard JPEG compression quality in (%). Earlier negative values were used (in software compression mode only) to generate BMP images, then"-1" meant BMP non-compressed and "-2" - BMP RLE compressed. The code is likely rotten by now.		# Standard JPEG compression quality in (%). Earlier negative values were used (in software compression mode only) to generate BMP images, then"-1" meant BMP non-compressed and "-2" - BMP RLE compressed. The code is likely rotten by now.
	# Camera implements virtually arbitrary table-based conversions from 10-bit sensor data to 8-bit used for compression. You may think of it ~~four (1 for each color including 2 greens - RG/GB)~~ 256-entry tables of single-byte values that are used to convert 10 (or more) bit sensor data to 8-bit foramt using linear interpolation between entries. ~~Such iterpolation can be~~ done as ~~following~~:		# Camera implements virtually arbitrary table-based conversions from e.g. 10-bit sensor data to 8-bit used for compression. You may think of it as 256-entry tables of single-byte values that are used to convert 10 (or more) bit sensor data to 8-bit foramt using linear interpolation between entries. There is four such tables T: one for each color including 2 greens - RG/GB. The interpolation is done as follows:

	Y= T[C][~~(X>>(w-8))~~]+ (((T[C][~~(X>>(W-8))~~+1]-T[~~color~~][~~(X>>(W-8))~~]) * (X & ((1<<~~(W-8)~~)-1))) >> ~~(W-8)~~)		Y= T[C][x]+ (((T[C][x+1]-T[C][x]) * (X & ((1<<D)-1))) >> D)
	where		where
	X - W-bit input (sensor) data,		X - W-bit input (sensor) data,
	Y - 8-bit output		Y - 8-bit output
			x - X (input) truncated to 8 bits: x = X>>(W-8)
			D = W-8 (number of bits to be truncated, i.e. 2 for a 10-bit sensor)
	C - color (0..3)		C - color (0..3)
	and T is a 4 x 256 byte table.		and T is a 4 x 256 byte table (one for each color).

	for 10 bits it will be		for 10 bits it will be
	Y= T[C][~~X>>2~~]+ (((T[C][(~~X>>2~~)+1]-T[~~color~~][~~X>>2~~]) * (X & 3)) >> 2)		Y= T[C][x]+ (((T[C][(x)+1]-T[C][x]) * (X & 3)) >> 2)

	~~Actually from the hardware point of view it is easier to have a single access to the table data instead of two accesses as in~~ (T[C][(X>>2)+1]-T[color][X>>2]) ~~so such differences are calcualted~~ by software in advance and ~~encoded~~ in a separate table ~~that~~ is combined with the main one~~. Maybe I will change that later~~ -~~-[[User:Andrey.filippov\|Andrey~~.~~filippov]] 17:18, 11 October 2005 (MDT)) , but current implementation uses this approach and instead of a~~ 8~~-bit (char) table we have a 16-bit one, where the~~ MSB ~~holds~~ the difference		An implementation detail: (T[C][(X>>2)+1]-T[color][X>>2]) is calculated by software in advance and stored in a separate table. For practical reasons this table is combined with the main one as 16-bit values. The 8 MSB stores the difference T[C][x+1]-T[C][x] and the 8 LSB stores the T[C][x] value. So written to the table is (R[C][x]<<8)+T[C][X].
	R[C][x] = T[C][~~(X>>2)+1~~]-T[~~color~~][~~X>>2~~]		The 8 bit imposes a restriction on the granularity of the table. Difference between consecutive entries needs to be in the range -128..127 (this is enough).
	~~and the data that needs to be~~ written to the table is (R[C][x]<<8)+T[C][X]		All this could change in the future (use the source Luke) --[[User:Andrey.filippov\|Andrey.filippov]] 17:18, 11 October 2005 (MDT))
	-128 ~~<= R~~[x]~~<= 127~~, so ~~not any~~ table ~~can be encoded this way~~, but ~~practically the difference between consequtive entries greater than 127 is not needed~~.
			(How about adding dither before the final truncate? Or maybe the signal has noise enough already to make dither unecessary/harmful? --[[User:Pfavr\|Pfavr]] 15:58, 27 October 2005 (CDT))

			Model 313 camera had a single table for all colors, Model 333 FPGA has room for bigger tables so each color has each own 256-entry table. Currently for the simplicity of the web-interface ccam.cgi only calculate a single table from a gamma value (100 - linear, 47 - standard gamma setting for video cameras) and 2 of the values (pxl and pxh) below. Together they make something like "levels" in image manipulation programs (such as [http://www.gimp.org/ GIMP]), but camera hardware (FPGA code) allows more flexible "curves" control.

	Model 313 camera had a single table for all colors, Model 333 FPGA has bigger tables so each of the 4 (including 2 greens) has an individual 256-entry table. Currently for the simlicity of the interface ccam.cgi allows to calculate a single table using gamma value (100 - linear, 47 - standard gamma setting for video camears) and 2 of the values (pxl and pxh) below. Together they make something like "levels" in image manipulation programs (such as [http://www.gimp.org/ GIMP]), but camera hardware (FPGA code) allows more flexible "curves" control. (I didn't understand the preceeding paragraph, maybe some figures would help? --[[User:Pfavr\|Pfavr]] 14:14, 26 October 2005 (CDT) - which part? - the one that I explained or about gamma?--[[User:Andrey.filippov\|Andrey.filippov]] 18:20, 26 October 2005 (CDT))
	# values for the 8 MSBs of the sensor data that map to total black (0x00) and total white (0xff) of the output signal. Sensors have different modes of auto-zero, and with default settings MT9T001 sensor adjusts black level so in the complete darkness each pixel would output 0x18 (8 MSBs are 0x0a or 10 decimal), other sensors have different values, it is also possible to reprogram sensors to change the "hardware" black value if needed.		# values for the 8 MSBs of the sensor data that map to total black (0x00) and total white (0xff) of the output signal. Sensors have different modes of auto-zero, and with default settings MT9T001 sensor adjusts black level so in the complete darkness each pixel would output 0x18 (8 MSBs are 0x0a or 10 decimal), other sensors have different values, it is also possible to reprogram sensors to change the "hardware" black value if needed.
	# Color saturation values for blue (B-G) and red (R-G) color components, in (%). In linear mode (gam=100) the true colors will be produced with color saturations of 1.0 (100), but for lower gamma setting the color saturation should be increased to compensate for the lowering contrast of the image - with the mosaic color filter pattern lower relative difference between the pixels will be decoded as less intense color.		# Color saturation values for blue (B-G) and red (R-G) color components, in (%). In linear mode (gam=100) the true colors will be produced with color saturations of 1.0 (100), but for lower gamma setting the color saturation should be increased to compensate for the lowering contrast of the image - with the mosaic color filter pattern lower relative difference between the pixels will be decoded as less intense color.

Andrey.filippov: /* Image Quality, Gamma correction, Color Saturation */

2005-10-26T23:20:39Z

Image Quality, Gamma correction, Color Saturation

← Older revision		Revision as of 23:20, 26 October 2005
Line 204:		Line 204:
	-128 <= R[x]<= 127, so not any table can be encoded this way, but practically the difference between consequtive entries greater than 127 is not needed.		-128 <= R[x]<= 127, so not any table can be encoded this way, but practically the difference between consequtive entries greater than 127 is not needed.

	Model 313 camera had a single table for all colors, Model 333 FPGA has bigger tables so each of the 4 (including 2 greens) has an individual 256-entry table. Currently for the simlicity of the interface ccam.cgi allows to calculate a single table using gamma value (100 - linear, 47 - standard gamma setting for video camears) and 2 of the values (pxl and pxh) below. Together they make something like "levels" in image manipulation programs (such as [http://www.gimp.org/ GIMP]), but camera hardware (FPGA code) allows more flexible "curves" control. (I didn't understand the preceeding paragraph, maybe some figures would help? --[[User:Pfavr\|Pfavr]] 14:14, 26 October 2005 (CDT) - which part? - the one that I explained or about gamma?)		Model 313 camera had a single table for all colors, Model 333 FPGA has bigger tables so each of the 4 (including 2 greens) has an individual 256-entry table. Currently for the simlicity of the interface ccam.cgi allows to calculate a single table using gamma value (100 - linear, 47 - standard gamma setting for video camears) and 2 of the values (pxl and pxh) below. Together they make something like "levels" in image manipulation programs (such as [http://www.gimp.org/ GIMP]), but camera hardware (FPGA code) allows more flexible "curves" control. (I didn't understand the preceeding paragraph, maybe some figures would help? --[[User:Pfavr\|Pfavr]] 14:14, 26 October 2005 (CDT) - which part? - the one that I explained or about gamma?--[[User:Andrey.filippov\|Andrey.filippov]] 18:20, 26 October 2005 (CDT))
	# values for the 8 MSBs of the sensor data that map to total black (0x00) and total white (0xff) of the output signal. Sensors have different modes of auto-zero, and with default settings MT9T001 sensor adjusts black level so in the complete darkness each pixel would output 0x18 (8 MSBs are 0x0a or 10 decimal), other sensors have different values, it is also possible to reprogram sensors to change the "hardware" black value if needed.		# values for the 8 MSBs of the sensor data that map to total black (0x00) and total white (0xff) of the output signal. Sensors have different modes of auto-zero, and with default settings MT9T001 sensor adjusts black level so in the complete darkness each pixel would output 0x18 (8 MSBs are 0x0a or 10 decimal), other sensors have different values, it is also possible to reprogram sensors to change the "hardware" black value if needed.
	# Color saturation values for blue (B-G) and red (R-G) color components, in (%). In linear mode (gam=100) the true colors will be produced with color saturations of 1.0 (100), but for lower gamma setting the color saturation should be increased to compensate for the lowering contrast of the image - with the mosaic color filter pattern lower relative difference between the pixels will be decoded as less intense color.		# Color saturation values for blue (B-G) and red (R-G) color components, in (%). In linear mode (gam=100) the true colors will be produced with color saturations of 1.0 (100), but for lower gamma setting the color saturation should be increased to compensate for the lowering contrast of the image - with the mosaic color filter pattern lower relative difference between the pixels will be decoded as less intense color.

Andrey.filippov: /* Image Quality, Gamma correction, Color Saturation */

2005-10-26T23:19:54Z

Image Quality, Gamma correction, Color Saturation

@@ Line 187: / Line 187: @@
 |}
 # Standard JPEG compression quality in (%). Earlier negative values were used (in software compression mode only) to generate BMP images, then"-1" meant BMP non-compressed and  "-2" - BMP RLE compressed. The code is likely rotten by now.
-# Camera implements virtually arbitrary table-based conversions from 10-bit sensor data to 8-bit used for compression. Each of the table has 256 entries each consisting of 2 bytes, the tables are indexed by 8 MSBs of the pixel data. One of the bytes holds the base value for the linear interpolation - the output value if the remaining LSBs (2 for 10-bit sensors) are zeros. The other byte - signed (-128..+127)increment between consequtive base values so in the case of 10-bit data this difference is multiplied by pixel 2 LSBs and divided by 4 (for 2 bits). The result is added to the base value. Of course, these second bytes might be calculated from the base ones, but in current FPGA code there are no extra cycles to retrieve 2 values and subtract them from each other (maybe will do that later --[[User:Andrey.filippov|Andrey.filippov]] 17:18, 11 October 2005 (MDT)) so both bytes in each table entry have to be filled by software. Model 313 camera had a single table for all colors, Model 333 FPGA has bigger tables so each of the 4 (including 2 greens) has an individual 256-entry table.  Currently for the simlicity of the interface ccam.cgi allows to calculate a single table using gamma value (100 - linear, 47 - standard gamma setting for video camears) and 2 of the values (pxl and pxh) below. Together they make something like "levels" in image manipulation programs (such as [http://www.gimp.org/ GIMP]), but camera hardware (FPGA code) allows more flexible "curves" control. (I didn't understand the preceeding paragraph, maybe some figures would help? --[[User:Pfavr|Pfavr]] 14:14, 26 October 2005 (CDT))
+# Camera implements virtually arbitrary table-based conversions from 10-bit sensor data to 8-bit used for compression. You may think of it four (1 for each color including 2 greens - RG/GB) 256-entry tables of single-byte values that are used to convert 10 (or more) bit sensor data to 8-bit foramt using linear interpolation between entries. Such iterpolation can be done as following:
 # values for the 8 MSBs of the sensor data that map to total black (0x00) and total white (0xff) of the output signal. Sensors have different modes of auto-zero, and with default settings MT9T001 sensor adjusts black level so in the complete darkness each pixel would output 0x18 (8 MSBs are 0x0a or 10 decimal), other sensors have different values, it is also possible to reprogram sensors to change the "hardware" black value if needed.
 # Color saturation values for blue (B-G) and red (R-G) color components, in (%). In linear mode (gam=100) the true colors will be produced with color saturations of 1.0 (100), but for lower gamma setting the color saturation should be increased to compensate for the lowering contrast of the image - with the mosaic color filter pattern lower relative difference between the pixels will be decoded as less intense color.
 === Histograms ===

Pfavr: /* Image Quality, Gamma correction, Color Saturation */ request for better explanation of table base conversions

2005-10-26T19:14:11Z

Image Quality, Gamma correction, Color Saturation: request for better explanation of table base conversions

← Older revision		Revision as of 19:14, 26 October 2005
Line 187:		Line 187:
	\|}		\|}
	# Standard JPEG compression quality in (%). Earlier negative values were used (in software compression mode only) to generate BMP images, then"-1" meant BMP non-compressed and "-2" - BMP RLE compressed. The code is likely rotten by now.		# Standard JPEG compression quality in (%). Earlier negative values were used (in software compression mode only) to generate BMP images, then"-1" meant BMP non-compressed and "-2" - BMP RLE compressed. The code is likely rotten by now.
	# Camera implements virtually arbitrary table-based conversions from 10-bit sensor data to 8-bit used for compression. Each of the table has 256 entries each consisting of 2 bytes, the tables are indexed by 8 MSBs of the pixel data. One of the bytes holds the base value for the linear interpolation - the output value if the remaining LSBs (2 for 10-bit sensors) are zeros. The other byte - signed (-128..+127)increment between consequtive base values so in the case of 10-bit data this difference is multiplied by pixel 2 LSBs and divided by 4 (for 2 bits). The result is added to the base value. Of course, these second bytes might be calculated from the base ones, but in current FPGA code there are no extra cycles to retrieve 2 values and subtract them from each other (maybe will do that later --[[User:Andrey.filippov\|Andrey.filippov]] 17:18, 11 October 2005 (MDT)) so both bytes in each table entry have to be filled by software. Model 313 camera had a single table for all colors, Model 333 FPGA has bigger tables so each of the 4 (including 2 greens) has an individual 256-entry table. Currently for the simlicity of the interface ccam.cgi allows to calculate a single table using gamma value (100 - linear, 47 - standard gamma setting for video camears) and 2 of the values (pxl and pxh) below. Together they make something like "levels" in image manipulation programs (such as [http://www.gimp.org/ GIMP]), but camera hardware (FPGA code) allows more flexible "curves" control.		# Camera implements virtually arbitrary table-based conversions from 10-bit sensor data to 8-bit used for compression. Each of the table has 256 entries each consisting of 2 bytes, the tables are indexed by 8 MSBs of the pixel data. One of the bytes holds the base value for the linear interpolation - the output value if the remaining LSBs (2 for 10-bit sensors) are zeros. The other byte - signed (-128..+127)increment between consequtive base values so in the case of 10-bit data this difference is multiplied by pixel 2 LSBs and divided by 4 (for 2 bits). The result is added to the base value. Of course, these second bytes might be calculated from the base ones, but in current FPGA code there are no extra cycles to retrieve 2 values and subtract them from each other (maybe will do that later --[[User:Andrey.filippov\|Andrey.filippov]] 17:18, 11 October 2005 (MDT)) so both bytes in each table entry have to be filled by software. Model 313 camera had a single table for all colors, Model 333 FPGA has bigger tables so each of the 4 (including 2 greens) has an individual 256-entry table. Currently for the simlicity of the interface ccam.cgi allows to calculate a single table using gamma value (100 - linear, 47 - standard gamma setting for video camears) and 2 of the values (pxl and pxh) below. Together they make something like "levels" in image manipulation programs (such as [http://www.gimp.org/ GIMP]), but camera hardware (FPGA code) allows more flexible "curves" control. (I didn't understand the preceeding paragraph, maybe some figures would help? --[[User:Pfavr\|Pfavr]] 14:14, 26 October 2005 (CDT))
	# values for the 8 MSBs of the sensor data that map to total black (0x00) and total white (0xff) of the output signal. Sensors have different modes of auto-zero, and with default settings MT9T001 sensor adjusts black level so in the complete darkness each pixel would output 0x18 (8 MSBs are 0x0a or 10 decimal), other sensors have different values, it is also possible to reprogram sensors to change the "hardware" black value if needed.		# values for the 8 MSBs of the sensor data that map to total black (0x00) and total white (0xff) of the output signal. Sensors have different modes of auto-zero, and with default settings MT9T001 sensor adjusts black level so in the complete darkness each pixel would output 0x18 (8 MSBs are 0x0a or 10 decimal), other sensors have different values, it is also possible to reprogram sensors to change the "hardware" black value if needed.
	# Color saturation values for blue (B-G) and red (R-G) color components, in (%). In linear mode (gam=100) the true colors will be produced with color saturations of 1.0 (100), but for lower gamma setting the color saturation should be increased to compensate for the lowering contrast of the image - with the mosaic color filter pattern lower relative difference between the pixels will be decoded as less intense color.		# Color saturation values for blue (B-G) and red (R-G) color components, in (%). In linear mode (gam=100) the true colors will be produced with color saturations of 1.0 (100), but for lower gamma setting the color saturation should be increased to compensate for the lowering contrast of the image - with the mosaic color filter pattern lower relative difference between the pixels will be decoded as less intense color.


	=== Histograms ===		=== Histograms ===

Andrey.filippov: /* Binning */

2005-10-12T15:56:10Z

Binning

← Older revision		Revision as of 15:56, 12 October 2005
Line 139:		Line 139:
	ww=2048&wh=1536&wl=0&wt=0&dl=4&dh=4&bh=1&bv=1		ww=2048&wh=1536&wl=0&wt=0&dl=4&dh=4&bh=1&bv=1
	2. Full frame with decimation by 4 in each direction will result in image of 512*384 pixels, pixel values are 16 times higher than for the full resolution (all 8x8 pixels are used, values are added together following the bayer RG/GB mosaic - reds with reds, greens with greens, blues with blues)		2. Full frame with decimation by 4 in each direction will result in image of 512*384 pixels, pixel values are 16 times higher than for the full resolution (all 8x8 pixels are used, values are added together following the bayer RG/GB mosaic - reds with reds, greens with greens, blues with blues)
	ww=2048&wh=1536&wl=0&wt=0&dl=4&dh=4&bh=4&bv=4		ww=2048&wh=1536&wl=0&wt=0&dv=4&dh=4&bh=4&bv=4

	=== Analog Gains ===		=== Analog Gains ===

Andrey.filippov: /* below is yet unedited text from ccam.c comments */

2005-10-12T07:28:13Z

below is yet unedited text from ccam.c comments

@@ Line 245: / Line 245: @@
 RG/GB mosaic in different ways, but the sequence of the colors  R,Gr,Gb,B in the FPGA tables ("curves", histogram)
 will still correspond to the colors in the JPEG output.
 == below is yet unedited text from ccam.c comments ==
   * hist=n - read frame from "history" applies only to rereading from memory after acquisition of a clipÃÂ
@@ Line 265: / Line 336: @@
   * _time=t (ms) will try to set current system time (if it was not set already. _stime - will always set)
   * fpns  - 0..3 fpga background subtraction:
   *               0 - none,