On Wed, Sep 30, 2009 at 4:58 PM, Alexander Larsson <al...@redhat.com> wrote: > On Wed, 2009-09-30 at 16:07 +0200, Alexander Larsson wrote: >> On Wed, 2009-09-30 at 15:27 +0200, Philip Van Hoof wrote: >> > On Fri, 2009-08-28 at 22:11 +0200, Mark wrote: >> > >> > > >> > > Now for the results: >> > > >> > > Glib >> > > ---------------------- >> > > 1927 images thumbnailed in 2.29 minutes. That is roughly 0.07 seconds >> > > per thumbnail >> > > >> > > GraphicsMagick >> > > ---------------------- >> > > 1927 images thumbnailed in 3.08 minutes. That is roughly 0.09 seconds >> > > per thumbnail >> > > >> > > FreeImage >> > > ---------------------- >> > > 1927 images thumbnailed in 5.45 minutes. That is roughly 0.17 seconds >> > > per thumbnail >> > >> > You want to override GdkPixbuf's support for Jpeg and thumbnail all JPEG >> > images using EPeg. It'll beat GdkPixbuf by 5 times or something. >> > >> > That's because afaik does EPeg use libjpeg in a way that it skips rows >> > and columns, and that way performs better on both I/O (having to read >> > less of the original), memory (same reason) and CPU (having to >> > decompress less, having to scale less or nothing). >> > >> > We are already using EPeg for this on the Maemo Fremantle platform, by >> > the way. Scaling truly large JPEG images goes magically fast with it. >> >> I'm not sure EPeg is really that magic. >> For instance, this: http://www.freshports.org/graphics/epeg says: >> >> It makes use of libjpeg features of being able to load an image by only >> decoding the DCT coefficients needed to reconstruct an image of the size >> desired. This gives a massive speedup. If you do not try and access the >> pixels >> in a format other than YUV (or GRAY8 if the source is grascale) then it >> also >> avoids colorspace conversions as well. >> >> The first part (DCT stuff) we already do in the jpeg loader (its the >> "jpeg loader trick" talked about above). The second we could easily do >> ourself in the jpeg loader for scaled image loads by scaling in >> YUV/GRAY8 space before converting. > > I took a look at the epeg code, and in addition to both these it also > sets dct_method to JDCT_IFAST (whereas gdk-pixbuf leaves this at the > default slower but better one). > > Additionally it also uses NEAREST as a scaling algorithm, causing > horrible looking thumbnails. Look at the attached images for comparison. > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > >
Oh, that does look horrible and is even bigger in size... _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
