[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Binary diffs: real-world differencing?

From: Daniel Griscom <griscom_at_suitable.com>
Date: 2006-02-04 16:54:30 CET

At 7:47 AM -0800 2/4/06, dberlin@dberlin.org wrote:
> >
>>> - An 85kB JPEG file didn't compress at all, even when I saved at 100%
>>> quality, opened the copy, saved THAT at 100% quality, and then
>>> compared the first and second copies.
>>
>> either your program did not save at 100% or you used two different JPEG
>> implementations for this.
>
>What?
>
>It is likely an artifact that floating point computation is not exact, and
>you are performing a lossy transform (quantization) on top of it, so you
>continually lose a little bit of precision.
>
>Hint: Loading and saving the same jpeg file multiple times, in the same
>program, will generally not give you the same file back.
>Try it.

True, and understood, but the real-world implication is that binary
diffs on JPEG files aren't any better than just copying changed files
in toto.

>
>>> - Adding a character to a text file in a ZIP archive compressed
>>> badly, with a diff almost as large as the archive itself.
>>
>> If it was the only file in there: this should be about correct - the
>> compression state engine changes at the changed character and yields a
>> different stream from there on.
>
>It will general only yield a different stream for the window size of the
>zip compression, which is 64 or 128k or something.

... but if a character is inserted, doesn't that push a character
into the next window?

Dan

-- 
Daniel T. Griscom             griscom@suitable.com
Suitable Systems              http://www.suitable.com/
1 Centre Street, Suite 204    (781) 665-0053
Wakefield, MA  01880-2400
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 4 16:55:45 2006

This is an archived mail posted to the Subversion Users mailing list.