Subject: Re: big honkin' images
From: Paul Rohr (paul@abisource.com)
Date: Thu Apr 26 2001 - 08:22:54 CDT
At 02:58 PM 4/26/01 +0200, Hubert Figuiere wrote:
>According to Paul Rohr <paul@abisource.com>:
>>
>> In any event, I guess I'm still tempted to let people insert big honkin'
>> images (BHIs) if they really want to. However, I see no particular reason
>> to prevent them from paying a scaling price if they do so. For example,
the
>> following FAQ seems to be entirely appropriate:
>>
>> Q: I just inserted a BHI into my document, and now the resulting .abw
>> file is huge. How do I make my document smaller?
>>
>> A1: Make the image smaller before you insert it.
>> A2. Compress the document when you save it (ie, as .zabw).
>>
>> On that theory, adding native JPEG support to the file format is less
>> necessary, but I'm not sure whether I've convinced anyone of that argument
>> yet.
>
>It still is necessary. Compressing a PNG, even if the binary is
>base64 will have almost no effects. This is a basic information theory
>since compression tends to bring entropy of the information to a level
>where another compression would be inefficient. This means that
>compressing the .abw file will not bring a noticeable size improvement.
>So answer A2 is useless.
>
>On the other side keeping JPEG as JPEG (and yes I'm not advocating
>conversion from any other format to JPEG) will help not wasting the file
>size.
>
>I can provide practical results. I already did with PNG / JPEG
>file size comparison.
Doh! Sorry for being sloppy there. That's what I get for posting in the
middle of the night. :-(
I agree that the PNG won't compress as well as the JPEG would. The A2
strategy should help reduce the size of the *rest* of the file, but not the
PNG. Clearly A1 has much more impact than A2.
As you point out, if we require JPEG support on all our platforms, then we
can have a tacit A3 strategy (ie don't convert the JPEGs to PNG internally)
to hold down the filesize bloat due to their BHI.
The design tradeoff is clear, but my original point still stands. If users
insert BHIs, I don't mind forcing them to pay a scaling penalty for doing
so. I *do* mind forcing all platforms to include JPEG support. In a
resource-constrained environment (my hypothetical settop box), that kind of
cost gets expensive. [1]
Paul
[1] It's more than just the memory cost of the JPEG code. Not all low-end
devices support floating-point math, for example.
This archive was generated by hypermail 2b25 : Thu Apr 26 2001 - 08:15:16 CDT