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