Hello, > * You do not need to completely decode the JPEG pictures! I'm certain there > is a very good correlation between sharp details in the picture, and the > presence of high-frequency coefficients in the JPEG data. Basically, > frequency analysis of the picture has already been done for you for free by > the MJPEG compression! > > That is also what i would like to understand, decoding a picture just "half-way". I am interested in finding a motion detection algorithm, that does not take much ressources like CPU and RAM. What i would like to get, is the average color of each JPG-block (should be in there) and if to many blocks change from frame to frame, i would assume it is a motion. Do you have any hints for that? Currently i would assume i have to implement JPG decoding myself in order to understand the algorithm and stop at the right decoding level. > * Most of the time while the camera is in use, there will be no need to > adjust the focus. The adjustment algorithm should only kick in when there > are significant changes (movement) in the centre of the image. A cheap > check for larger-scale changes is possible by looking at the JPEG DC > coefficients, which specify the mean brightness of each 8x8 square of the > picture. As long as there is no movement, this check need not even be done > for every frame, but maybe only every .5 sec or so. Exactly, i would assume that this algorithm allows embedded devices to do the motion detection well enough.
Kind regards, Tom _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
