Hi all,
[...]
> I've noticed that png representations of camera images are about a
> factor of 5 larger than jpegs. Put this together with the EXTREMELY low
> compression of an rtf file where each pixel gets about 16 bytes to
> describe it and a few large images in an rtf file give the situation you
> describe.
That's exactly the problem. The original defect I reported was saying
exactly this.
http://bugzilla.abisource.com/show_bug.cgi?id=1349
> Though I have to also say that the situation of AbiWord you describe is
> also a symptom of a badly behaving kernel. There should be sufficient
> swap present to load the file.
That's exactly the wrong approach. You forget the very high impact of
virtual memory an swap on the overall system performance, on the battery
life (whoever does not use a laptop throw me the first stone), etc.
Saying "the virtual memory will handle it" is not a good thing. Remember
the Nokia does not really have swap, or barely.
> I agree that it makes sense to keep images in their native format on the
> unix build of abiword where we can use gdkpixbuf to display them on
> screen. We win particularly big for svg's doing things this way.
>
> However all the document exporters will need to be patched to handle the
> potential non-png images and there is a real issue about incompatible
> *.abw files from unix to windows and OSX. We definitely lose back
> compatibility too.
Just to make things clear. It does not depend on the platform. All the
supported platform we run have builting JPEG support. This is a non
issue. I already back in these days implemented a cross-platform JPEG
loader using libjpeg, and that's what made me file the bug.
As for saving in the original format, it is a bit too dastric.
It should be done the following way:
If the bitmap is a JPEG, store the JPEG content (image/jpeg).
If the bitmap is anything else, convert it to PNG if needed and store it
as PNG (image/png). Always set the maximum compression.
Vector drawing are a different story.... let's keep it that way.
> Finally the situation on OLPC may not be as bad even without this fix
> for a couple of reasons:
>
> 1. The OLPC camera is only 640x480 resolution.
So you can have JPEG in 25KB :-)
> 2. We can demand that docs get saved in gzipped abiword or odt format.
No. That's exactly inefficient. Compressed data does not recompress well
when using similar algorithm, zip, gzip and png using very similar if
not identical algorithms ; that make compressing PNG images inside a zip
very inefficient, or worse, yield to an actually bigger blob.
> So the question is: It it worth losing backward compatibility of *.abw
> to support non-png images internally?
Yes. But I think we should first determine how an older version will
handle having an image as image/jpeg. It might end up being that it
works and just save it back as image/png. If that's the case, then go
with it.
> Frankly if the original designers of AbiWord has realized this factor of
> 5 difference in compression quality between png and jpeg I can't imagine
> they would have chosen png.
They did. The original argument back in 2001 was that we wanted to be
able to run on things like WebTV that were unable to handle JPEG, etc.
As of today this is completely irrelevant. The least powerful platform
today is much more capable than that.
> Is there something dramatically wrong with how we're dealing with png or
> is it a feature of the format?
It is the raison d'être of JPEG, and why it is a lossy format.
Hub
Received on Tue May 8 01:20:23 2007
This archive was generated by hypermail 2.1.8 : Tue May 08 2007 - 01:20:24 CEST