Subject: Re: Graphic Images
From: Hubert Figuiere (hfiguiere@teaser.fr)
Date: Fri Apr 20 2001 - 03:53:21 CDT
According to Dom Lachowicz <cinamod@hotmail.com>:
> > > - which is most efficient at run-time? (both speed and memory)
> >
> >The less layer we have, the best efficient it is. libpng and libjpeg are
> >low level
> >and easy to use. So I think we should use them directly.
>
> I haven't seen the JPEG code yet so I'm not quite sure what you're doing to
> get a JPEG onto the screen (much less to a unix PS printer) but I have a
> feeling that you're doing:
>
> JPEG->RGBA->PNG->RGBA->SCREEN (much like the BPM loader code) which
That is what I'm doing because Abiword does not support JPEG internally.
> certainly wouldn't be faster or easier on memory than JPEG->RGBA->SCREEN
> that IM or GdkPixbuf would allow for. I also don't see the need for learning
> many low-level APIs instead of 1 or two high-level ones.
Sure but if JPEG is supported internally, I'll do like the PNG importer.
Currently the result of a JPEG import is stored as a PNG within Abiword and
JPEG -> is done only once.
See:
<d name="/home/hub/compile/jpeg-6b/testorig.jpg_0" mime-type="image/png" base64="yes">
iVBORw0KGgoAAAANSUhEUgAAAOMAAACVCAIAAAAll9rHAAAgAElEQVR4nIy8aY8kS5IcKKJq
(I can send you an actual Abiword that you can open with the stock 0.7.14 binaries
and that have been created with my home build abiword with JPEG import)
> Let me be the devil's advocate here for a second. (ignoring patent/other
> issues) We want to load a GIF. Ok, so we want to turn a GIF into a PNG. So
> what can we do? Well, we have libungif to disassemble the GIF, so we have to
> learn that (or gif2png... quite a bit of code itself). Or maybe we don't
> want libungif. So we go and write our own. Now we put the RGBA back together
> into a PNG, meaning that we now have libungif linked to our binary as well
> as libjpeg and libpng.
Yes that what we can do. But this process only need to ne done at import time.
Later on you no longer need to conmvert from GIF since it would have been stored
as PNG within the file.
> Now I want to do TIFF. Then XPM. Then XBM. Then &c... So for every useful
> image format that we want to support, we end up adding 1 library on top of
> those we already ship + a new low-level API that someone must now learn and
> use and maintain code for. <sarcasm>Sounds pleasant</sarcasm>
Same.
That is where ImageMagick, QuickTime Be OS translator and al. can play the game:
provide infrastructure to *import* the image. This is done only once.
Note that I have begun the ie_impGraphic_Magick to prove that this is the
way we should go. It will *import* anything IM can read and convert it to
PNG for Abiword use.
> Now, I ask, how is this better than IM or some other similar solution? If
> for some reason we do want to support libjpeg, libungif, etc.. why don't we
> use libungif to just extract RGBA data from the image and render that to
> screen instead of all this middleware conversion stuff?
Because you actually have to store that data to disk to be able to use it back
again. That is why we are all using Word processing system instead of
ancient mechanic typewriter that are rather noisy. No ?
Hub
This archive was generated by hypermail 2b25 : Fri Apr 20 2001 - 03:54:01 CDT