At 01:55 AM 24/08/2005 -0400, Greg Hudson wrote:
>This is a self-compressed delta, so I think it should be the vdelta
>algorithm. Since we're compressing already-compressed data, one
>wouldn't expect to be able to do any better than "insert the new data",
>which is one instructions. But there seem to be scores of instructions,
>which is not what one would expect from vdelta since it shouldn't be
>finding four-byte matches within the target.
I'm not quite sure what "self-compressed" means, but I think you're
forgetting something quite important: JPEG files have header information,
and sometimes quite a lot of it (I have seen JPEG files with more than 30KB
of information preceding the SOI tag). It is binary, but it would tend to
change infrequently over the course of editing an image. Fields such as the
software used to produce the JPEG ("Adobe Photoshop v7.0"), the width,
height, colour space, gamma and other parameters, and any other comment
data would not change. Also, with traditional JFIF, thumbnail data is
stored uncompressed, and depending on how it is generated, it may share
some data with the previous revision of the file. With the new EXIF,
thumbnails are stored JPEG-compressed, but other information about the
image is stored uncompressed, in a TIFF dictionary embedded into the JPEG
APP1 tag. That data and the TIFF dictionary itself can remain unchanged.
Certainly, though, with a lossy format, it would be exceedingly rare to see
actual image data unchanged, even if the user had not edited those pixels;
the chance of the DCT & quantization phases finding exactly the same fit is
pretty low. :-)
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 24 21:20:03 2005