From the web page shown that:
___________________________________________________
Capable of tracking up to 8 colorful objects at 30 frames/sec
User-definable color map to track up to 8 different colors
Tracked image resolution of 88 x 144 pixels
__________________________________________________
How this calculation is made?
How to calculate the specification of performance
2 posts
• Page 1 of 1
by Guest » Sun Jan 30, 2005 11:55 am
Hello,
The AVRcam has a trackedObjectTable data structure internally that has space to hold up to 8 simultaneously tracked objects. The data maintained for each tracked object is the color, upper left (x,y) coordinates, and lower right (x,y) coordinates. The system performs a direct mapping between the sampled RGB/YUV values from the camera to specific colors as specified by the colorMap, another data structure maintained by the AVRcam.
The camera generates pixel information in a Bayer pattern, formatted as follows:
row 1: G G G G G G G...
row 2: R B R B R B R B...
row 3: G G G G G G G...
row 4: R B R B R B R B...
The OV6620 natively generates digital video at 352 x 288 pixels per frame. A register in the OV6620 can cut each dimension in half (176 x 144 pixels per frame). Internally, the AVRcam subsamples each row of data (i.e., it samples column 1 and 2, skips 3 and 4, samples 5 and 6, skips 7 and 8, etc), which effectively provides a range of 88 sampled pixels in each row. This skipped columns are where the AVRcam is mapping the sampled RGB/YUV values into an actual color, and updating the run-length encoding data for the line. All 144 rows are sampled (none are skipped).
The 30 frames/sec is the nominal rate of data provided by the OV6620. It can be throttled down by setting an internal register, but this isn't needed for the AVRcam. The actual responsiveness of the system can be emperically measured by enabling color blob tracking ("ET" command), and timing the tracking packets being sent by the system (assuming there is something to track in the current scene). There will be ~30 of these packets sent by the system each second. This can also be verified with the AVRcamVIEW software, by enabling the logging feature. This will log each packet received from the AVRcam, with a timestamp to verify the overall throughput of the system (NOTE: the timing within Java used to timestamp the packets isn't precise down to the millisecond...sometimes it appears as though two tracking packets were received within the same millisecond, which is clearly not possible).
The colorMap can hold a maximum of 8 colors in the current implementation. As each RGB/YUV block is sampled by the system, it is converted to either one of the eight colors (through a single bit being set in a byte), or to a value of zero, indicating that the RGB/YUV block doesn't map to any color in the colorMap.
Let me know if you have any other questions...
The AVRcam has a trackedObjectTable data structure internally that has space to hold up to 8 simultaneously tracked objects. The data maintained for each tracked object is the color, upper left (x,y) coordinates, and lower right (x,y) coordinates. The system performs a direct mapping between the sampled RGB/YUV values from the camera to specific colors as specified by the colorMap, another data structure maintained by the AVRcam.
The camera generates pixel information in a Bayer pattern, formatted as follows:
row 1: G G G G G G G...
row 2: R B R B R B R B...
row 3: G G G G G G G...
row 4: R B R B R B R B...
The OV6620 natively generates digital video at 352 x 288 pixels per frame. A register in the OV6620 can cut each dimension in half (176 x 144 pixels per frame). Internally, the AVRcam subsamples each row of data (i.e., it samples column 1 and 2, skips 3 and 4, samples 5 and 6, skips 7 and 8, etc), which effectively provides a range of 88 sampled pixels in each row. This skipped columns are where the AVRcam is mapping the sampled RGB/YUV values into an actual color, and updating the run-length encoding data for the line. All 144 rows are sampled (none are skipped).
The 30 frames/sec is the nominal rate of data provided by the OV6620. It can be throttled down by setting an internal register, but this isn't needed for the AVRcam. The actual responsiveness of the system can be emperically measured by enabling color blob tracking ("ET" command), and timing the tracking packets being sent by the system (assuming there is something to track in the current scene). There will be ~30 of these packets sent by the system each second. This can also be verified with the AVRcamVIEW software, by enabling the logging feature. This will log each packet received from the AVRcam, with a timestamp to verify the overall throughput of the system (NOTE: the timing within Java used to timestamp the packets isn't precise down to the millisecond...sometimes it appears as though two tracking packets were received within the same millisecond, which is clearly not possible).
The colorMap can hold a maximum of 8 colors in the current implementation. As each RGB/YUV block is sampled by the system, it is converted to either one of the eight colors (through a single bit being set in a byte), or to a value of zero, indicating that the RGB/YUV block doesn't map to any color in the colorMap.
Let me know if you have any other questions...
- Guest
2 posts
• Page 1 of 1
Return to AVRcam Embedded System
Who is online
Users browsing this forum: No registered users and 21 guests