Subject: Re: gdk-pixbuf vs. ImageMagick
From: Paul Rohr (paul@abisource.com)
Date: Thu Apr 19 2001 - 18:04:23 CDT
At 20:20 PM 4/18/01 -0500, Paolo Molaro wrote:
>On 04/18/01 Leonard Rosenthol wrote:
>> 1) Yes, gdk-pixbuf is smaller because it only support about 10% (if that)
>> of all the functionality of ImageMagick. Now admittedly, a bunch of that
>> functionality is overkill for a word processor (eg. when was the last time
>> you color corrected or embossed a picture in Word?), but support for
vector
>> formats like PS, PDF, SVG, WMF will definitely be a nice plume in
AbiWord's
>> cap that IM can bring "for free".
>
>That 10% is exactly what a WP needs. Moreover vector data should better
>not be converted to RGB. We'll want a component to handle that properly
>(and probably libsvg for SVG).
Yep. Leonard, is Paolo correct when he suggests that IM's vector support
results in a rasterized image? (You've probably told me before, but I
forgot.)
>> 2) Faster - I doubt it for the same functionality since both products
leave
>> the "heavy lifting" of image format handling to libraries like libjpg,
>
>I must admit I wrote that because I find myself many times running
>display image, hitting ctrl-C and starting Gimp itself, only
>to view the image... But this doesn't compare to gdk-pixbuf, so I wrote
>a little program to load an image, scale and save it back.
>I haven't investigated in what operation libMagick gets slow, but
>loading and saving time has a lot to do with the user experience and
>scaling needs to be fast because abiword uses it for the display.
>Yeah, I now we don't save to png files, but it's just to make
>the program comparable to convert...
>
>I tested image sizes 250x250, 600x600, 1329x1515
>(with time program args...) and gdk-pixbuf is at least twice as fast.
>The program is small enough to inline it here:
>
>#include <gdk-pixbuf/gdk-pixbuf.h>
>int main(int argc, char * argv[]) {
> GdkPixbuf *pixbuf, *p2;
> g_type_init(0);
> pixbuf = gdk_pixbuf_new_from_file (argv[1], NULL);
> p2 = gdk_pixbuf_scale_simple(pixbuf, 50, 50, 0);
> gdk_pixbuf_save (p2, "test.png", "png", NULL, NULL, NULL);
> return 0;
>}
>
>For ImageMagickk I used convert -scale 50x50 image1.png test.png.
>Note also the convert uses 4 times as much memory (as reported with
>memprof).
Oooh. Data on serious speed *and* memory improvements! Sweet! Does anyone
have reason to believe that this isn't a fair test?
>> 3) ImageMagick 5.2 and later also use dynamic loading of the image
>> libraries AND our "coder" modules.
>
>Ok, I checked my debian package (version 5.3.x) and the library is linked
>to a lot of image libs, should probably file a bug report on the package
>so that it's compiled with the dynamic modules.
If we're to use IM *or* gdk-pixbuf, the ability to dynamically load stuff on
all our supported platforms would certainly be a plus. How the platform
coverage for IM on this?
Still sounds like a tossup on this one, but in any event, we ought to be
able to use the best-available dynamic-loading code for whichever solution
we choose (provided there's no licensing clash).
>> 4) That's great - BUT that doesn't help us on all the other platforms (Mac
>> OS, Windows, QNX, BeOS, etc.) that Abiword is available on that GTK is
>> not. ImageMagick, on the other hand, is available for all of those
>> platforms and many others.
>
>Gdk-Pixbuf depends only on GLib (talking about version 2.0 here)
>and there shouldn't be any portability problems.
Good. Do you know how much of Glib it needs? IIRC, Dom's gotten a subset
ported already for all our supported platforms.
>Anyway I don't have any problem with the other platforms using libMagick,
>the point is, do not add classes for each image file type, add a single
>class that loads many types of images using a library such as gdk-pixbuf,
>libMagick or the OS services.
Agreed. Whatever API we use for the switching mechanism should be able to
easily instantiate or invoke converters for all formats the underlying
conversion service supports.
There are lots of ways to write such an API, but I tend to be more familiar
with low-tech C-based function-pointer style interfaces, so I'll defer to
the pattern whizzes on the list for C++ stylistics.
That way Mike won't have to start by slapping me upside the head. ;-)
Paul
This archive was generated by hypermail 2b25 : Thu Apr 19 2001 - 17:56:46 CDT