I am comparing jpeg to jpeg in a constant ‘video-stream’. I am using EMGU/OpenCV to compare each pixels at the byte level. There are 3 channels to each image (RGB). I have heard that it is common practice to store only the pixels that have changed between frames as a way of conserving memory space. But, if for instance, I say EVERY pixel has changed (Please note I am using an exaggerated example to make my point and I would normally discard such large changes.) then the resultant bytes saved is 3 times larger than the original jpeg.
How can I store such motion changes efficiently?
8
Have a bit that indicates whether you are storing changes from the last frame or a new frame and store whatever option is less memory consuming.
You can store either a jpeg (or any other format really, if possible for your purpose since jpeg is far for optimal for that) of the image that represents the changes or a simple jpeg of the next frame, and indicate using an added bit which format you used.
Obviously, you may (and according to your comments seem to) have constrains which block you from using this approach. In any case, this is more or less the approach used in the MPEG video format(s).
Look up I frames (“Intra coded frames/slices”) and P frames (“Predicted frames/slices”) in this Wikipedia article – Video compression picture types
6
From what I remember, the JPEG and MPEG/H264 family of motion codecs internally represent the images in YCbCr colorspace (not RGB), where Y is the luminance, and Cb with Cr are the chrominance components. While every pixel of Y component is used, the chrominance is downsampled according to one of a few possible schemes. The main compression gain in JPEG (and keyframes of motion codecs) is achieved by quantization of DCT results, which means throwing away the high frequency components of each image block.
To compress the differences between frames caused by motion, the motion prediction is used in the luminance component (before DCT). Very briefly, each frame is divided into regular blocks of pixels, and each block of current frame is compared with pixels of the previous frame to find the closest match. This produces the deplacement vector (motion vector). Because the match is not ideal, the pixel value differences in each of the Y, Cb, and Cr components are passed through the normal JPEG compression (DCT, quantization, Huffman encoding) and sent along the motion vector to form a Delta Frame.
Here, you will find a few hints for your further research. I hope you’ll not have to reinvent the wheel. There are some Linux/Unix image processing tools you might harness for your task.
0