Talk:Camogm - Revision history

Andrey.filippov at 15:41, 17 April 2008

2008-04-17T15:41:42Z

← Older revision		Revision as of 15:41, 17 April 2008
Line 20:		Line 20:
	And i get a normal video (i mean not a timelapse). If i look to the status i see: timescale 1.000000		And i get a normal video (i mean not a timelapse). If i look to the status i see: timescale 1.000000
	--[[User:Polto\|Polto]] 22:14, 28 November 2007 (GMT)		--[[User:Polto\|Polto]] 22:14, 28 November 2007 (GMT)

			There are many new changes in Exif data handling and camogm that uses it (i.e. it can now output *.kml files in parallel with the video). Please stay tuned for the documentation --[[User:Andrey.filippov\|Andrey.filippov]] 10:41, 17 April 2008 (CDT)

Polto at 21:15, 28 November 2007

2007-11-28T21:15:52Z

← Older revision		Revision as of 21:15, 28 November 2007
Line 13:		Line 13:

	No, not negaitive. just > or < 1. 10 will playback 10 slower (100fps will play at 10 fps), 0.00139 should do what you wanted.		No, not negaitive. just > or < 1. 10 will playback 10 slower (100fps will play at 10 fps), 0.00139 should do what you wanted.
			--[[User:Andrey.filippov\|Andrey.filippov]]

			I understood correctly, but as it was not working i tried different things... So it seems to be a bug. I do:
			echo "status; exif=1; format=mov; prefix=/var/tmp/z/timelapse; duration=600; timescale=0.0001; status=/var/tmp/camogm.status" > /var/state/camogm_cmd

			And i get a normal video (i mean not a timelapse). If i look to the status i see: timescale 1.000000
			--[[User:Polto\|Polto]] 22:14, 28 November 2007 (GMT)

Andrey.filippov at 07:13, 27 November 2007

2007-11-27T07:13:24Z

← Older revision		Revision as of 07:13, 27 November 2007
Line 11:		Line 11:

	For timelapse, should timescale be negative? and what does it exactly ? a video with same number of frames but played faster or does the video have less images? (i try to do a timelapse with images every 1 minutes and would like to play it 12 images per second (12 minutes of real time per second, an hour viewed in 5 seconds)) --[[User:Polto\|Polto]] 16:36, 26 November 2007 (GMT)		For timelapse, should timescale be negative? and what does it exactly ? a video with same number of frames but played faster or does the video have less images? (i try to do a timelapse with images every 1 minutes and would like to play it 12 images per second (12 minutes of real time per second, an hour viewed in 5 seconds)) --[[User:Polto\|Polto]] 16:36, 26 November 2007 (GMT)

			No, not negaitive. just > or < 1. 10 will playback 10 slower (100fps will play at 10 fps), 0.00139 should do what you wanted.

Polto at 15:36, 26 November 2007

2007-11-26T15:36:28Z

← Older revision		Revision as of 15:36, 26 November 2007
Line 8:		Line 8:

	Two last ones are pretty new so bugs are definitely expected, fixing them will make sure that underlying drivers work nicely. After that we plan to add more functionality on the sensor/compressor control - there are many sensors to support and different modes of operation.--[[User:Andrey.filippov\|Andrey.filippov]] 13:40, 19 November 2007 (CST)		Two last ones are pretty new so bugs are definitely expected, fixing them will make sure that underlying drivers work nicely. After that we plan to add more functionality on the sensor/compressor control - there are many sensors to support and different modes of operation.--[[User:Andrey.filippov\|Andrey.filippov]] 13:40, 19 November 2007 (CST)


			For timelapse, should timescale be negative? and what does it exactly ? a video with same number of frames but played faster or does the video have less images? (i try to do a timelapse with images every 1 minutes and would like to play it 12 images per second (12 minutes of real time per second, an hour viewed in 5 seconds)) --[[User:Polto\|Polto]] 16:36, 26 November 2007 (GMT)

Andrey.filippov at 19:40, 19 November 2007

2007-11-19T19:40:23Z

← Older revision		Revision as of 19:40, 19 November 2007
Line 3:		Line 3:
	None yet. I was focusing on separating functionality of the overgrown ccam.cgi into separate parts - image acquisition to the internal buffer (that includes programming of different sensors) and dealing with the data from the buffer. So far we did more for that second part, there are 3 applications now:		None yet. I was focusing on separating functionality of the overgrown ccam.cgi into separate parts - image acquisition to the internal buffer (that includes programming of different sensors) and dealing with the data from the buffer. So far we did more for that second part, there are 3 applications now:

	- imgsrv that serves images from the circbuf in response to HTTP GET		*imgsrv that serves images from the circbuf in response to HTTP GET
	- astreamer (recently updated by Spectr to support circbuf) for RTP streaming		*astreamer (recently updated by Spectr to support circbuf) for RTP streaming
	- camogm - to record images/video to the internal storage media		*camogm - to record images/video to the internal storage media

	Two last ones are pretty new so bugs are definitely expected, fixing them will make sure that underlying drivers work nicely. After that we plan to add more functionality on the sensor/compressor control - there are many sensors to support and different modes of operation.--[[User:Andrey.filippov\|Andrey.filippov]] 13:40, 19 November 2007 (CST)		Two last ones are pretty new so bugs are definitely expected, fixing them will make sure that underlying drivers work nicely. After that we plan to add more functionality on the sensor/compressor control - there are many sensors to support and different modes of operation.--[[User:Andrey.filippov\|Andrey.filippov]] 13:40, 19 November 2007 (CST)

Andrey.filippov at 19:40, 19 November 2007

2007-11-19T19:40:00Z

← Older revision		Revision as of 19:40, 19 November 2007
Line 1:		Line 1:
	Camogm seems to be very versatile.. however, is there a similar method (command line) for changing acquisition parameters (e.g., decimation, exposure time, etc.) ? I am interested in automating capture of low-rate, high-res still images and high-rate, low-res video. The ability to switch between these two without using ccam (or any web interface) would be ideal. --[[User:Ekratzer\|Ekratzer]] 11:18, 19 November 2007 (CST)		Camogm seems to be very versatile.. however, is there a similar method (command line) for changing acquisition parameters (e.g., decimation, exposure time, etc.) ? I am interested in automating capture of low-rate, high-res still images and high-rate, low-res video. The ability to switch between these two without using ccam (or any web interface) would be ideal. --[[User:Ekratzer\|Ekratzer]] 11:18, 19 November 2007 (CST)

			None yet. I was focusing on separating functionality of the overgrown ccam.cgi into separate parts - image acquisition to the internal buffer (that includes programming of different sensors) and dealing with the data from the buffer. So far we did more for that second part, there are 3 applications now:

			- imgsrv that serves images from the circbuf in response to HTTP GET
			- astreamer (recently updated by Spectr to support circbuf) for RTP streaming
			- camogm - to record images/video to the internal storage media

			Two last ones are pretty new so bugs are definitely expected, fixing them will make sure that underlying drivers work nicely. After that we plan to add more functionality on the sensor/compressor control - there are many sensors to support and different modes of operation.--[[User:Andrey.filippov\|Andrey.filippov]] 13:40, 19 November 2007 (CST)

Ekratzer at 17:18, 19 November 2007

2007-11-19T17:18:59Z

New page

Camogm seems to be very versatile.. however, is there a similar method (command line) for changing acquisition parameters (e.g., decimation, exposure time, etc.) ? I am interested in automating capture of low-rate, high-res still images and high-rate, low-res video. The ability to switch between these two without using ccam (or any web interface) would be ideal. --[[User:Ekratzer|Ekratzer]] 11:18, 19 November 2007 (CST)