1. imlib2 uses libjpeg to load/save jpeg's. as does imagemagick, netpbm etc.
etc. etc. so it's the same encoder/decoder code.
2. default (if unspecified) quality of saved jpegs byimlib2 is 80%
3. the speedup does not drop quality at all- it's just better written code.
quoted from rasterman
"when you scale an image down the artifacts and lack of detail due to the
high-res, but low quality original begin to vanish (due to the multiple-pixels
becoming one nature of scaling down). thsi is especialyl true of filtered
scaling (which is what you are using) where the output is the result of sampling
a region of the original, averaging the result and using that as your output
pixel. in the case of non-filtered scaling (i cannot rememebr if the pbm
utilties did non-filtered scaling - if someone gets me an original image and
then a faily highly scaled down outptu (in on jpg) i could tell you visually),
yout artifacts will be just as bad.. maybe worse (due to the sampling nature
where you may sample a "bad" part of an artifact for an output pixel).
the quality of the saved jpeg is almost entirely unrelated to the speed. the
speed is int eh simple data path in memory and minimised number of copies and
keepign in the same memory space (and not dumpign via pipes), and the massively
optimised scaling routines."
hope that clears things up, if not gimme a shout :)
* Edward Wildgoose (Edward.Wildgoose@...) wrote:
> Actually you and I already had this discussion a few days ago on the
> Gallery-Users list (see subject "--Quality error in gallery"). But
> thanks for the tip
> I was directing my question to Kirth and his replacement for NetPBM
> really. I wonder whether the speedup is at the cost of "quality" in the
> JPEG compression...? Clearly some encoders can really do quite well at
> low quality settings and other struggle and introduce many artifacts.
> AS AN ASIDE: you told me where to modify the quality setting, and after
> a bit of tweaking I came up with 60% as a satisfactory number for my
> Hi-Res Sony DSC-707 shots. For me this dropped thumbnail size from
> about 10K to about 3.3K (at 150 pixels). Quality is visually slightly
> lower (if you have before and after to compare), but quite satisfactory
> and obviously this makes a huge difference for dialup users.
> The size for the main pictures drops from about 100K each to 16K
> although I also dropped the size to 500 pixels because this looks more
> satisfactory on 1024x768 screens (when embedded in Nuke.)
> Obviously I am starting with high quality shots, but I imagine that the
> majority of other users are also. If so then you may want to try those
> quality settings for a speedup...
> Thanks for your help Markus!
> Ed Wildgoose
> -----Original Message-----
> From: Markus Illenseer [mailto:markus@...]
> Sent: 14 January 2002 10:05
> To: Edward Wildgoose
> Cc: gallery-devel@...
> Subject: RE: [Gallery-devel] Gallery Image processing speedup
> > I would like to see some independent thoughts on image quality though?
> > Also is the param "--quality" supported?
> Clearly, the quality of the thumbnails (and the smaller picture set)
> depends on what you upload as original file and thus cannot be dynamicly
> set up and - in the NetPBM environment - not be detected before or after
> converting to the PPM-format. Low quality originals need to have higher
> quality thumbnails (otherwise you wont see anything on the thumb). High
> quality originals normally would require low or medium quality for the
> thumbnail - though, this depends on the size of the thumbnail...
> --quality is "supported", yes. It is set to 95% and can be manipulated
> manually in the source.
> Markus Illenseer
> __[ g a l l e r y - d e v e l ]_________________________
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]
Jaded @ opn/#e efnet/#dunno,#us-opers,#eu-opers,#uk,#rejected
kirth@... / kirth@...