[Image-SIG] PIL image resizing quality seems a little rough, any workarounds?
Mail System Administrator
mailhost@cdc.edu
Sat, 13 Jul 2002 09:32:25 -0700
Fredrik -
Great suggestion! Sadly it appears that the Anti-Alias rendering is only in
version 1.1.3 which has not been compiled by Secret Labs for us poor windoze
folks yet. I am still stuck with 1.1.2.
I know you put an installer on your site (effbot.org) that works for python
installations, but for zope users it doesn't get past the Enter Python Path
screen because the zope installer doesn't create a registry key for the
python installation path and the field does not allow manual entry of the
path.
Would it work to hand enter a registry key for the zope installation?
Is there another work-around you can suggest?
Thanks,
Gary
----- Original Message -----
From: "Fredrik Lundh" <fredrik@pythonware.com>
To: <image-sig@python.org>
Cc: "Jeff Kowalczyk" <jtk@yahoo.com>
Sent: Saturday, July 13, 2002 8:37 AM
Subject: Re: [Image-SIG] PIL image resizing quality seems a little rough,
any workarounds?
Jeff Kowalczyk wrote (in a message pretending to be a "comp.python.image"
newsgroup posting, which caused my mailer to mess up completely):
> Is this just an area PIL isn't strong in yet, or are there tricks to
improve
> the quality? Speed isn't an issue for me, this is a one-time resizing
> operation at upload time. Is improved resizing quality available in the
> development version?
did you look for "resize" options in the 1.1.3 documentation, or in
the README or CHANGES documents? (the new ANTIALIAS filter
was one of the major features in this release ;-)
> Here's the function in Photo that does the work. I use quality=100.
>
> def _resize(self, display, width, height, engine='ImageMagick',
> quality=75):
> """Resize and resample photo."""
> origimg = self._original
> newimg = StringIO()
> if engine == 'PIL': # Use PIL
> img = PIL.Image.open(origimg._PILdata())
> fmt = img.format
> img = img.resize((width, height))
try this instead:
img = img.resize((width, height),Image.ANTIALIAS)
> img.save(newimg, fmt, quality=quality)
JPEG quality 100 is overkill, btw -- it completely disables JPEG's
quantization stage, and "mainly of interest for experimental pur-
poses", according to the JPEG library documentation, which
continues:
"Quality values above about 95 are NOT recommended for
normal use; the compressed file size goes up dramatically
for hardly any gain in output image quality."
(full text below):
Should probably add something about this to the PIL docs...
regards /F
::: from the IJG library documentation:
The quality switch lets you trade off compressed file size against quality
of
the reconstructed image: the higher the quality setting, the larger the JPEG
file, and the closer the output image will be to the original input.
Normally
you want to use the lowest quality setting (smallest file) that decompresses
into something visually indistinguishable from the original image. For this
purpose the quality setting should be between 50 and 95; the default of 75
is
often about right. If you see defects at quality 75, then go up 5 or 10
counts at a time until you are happy with the output image. (The optimal
setting will vary from one image to another.)
quality 100 will generate a quantization table of all 1's, minimizing loss
in the quantization step (but there is still information loss in
subsampling,
as well as roundoff error). This setting is mainly of interest for
experimental purposes. Quality values above about 95 are NOT recommended
for
normal use; the compressed file size goes up dramatically for hardly any
gain
in output image quality.
In the other direction, quality values below 50 will produce very small
files
of low image quality. Settings around 5 to 10 might be useful in preparing
an
index of a large image library, for example. Try quality 2 (or so) for some
amusing Cubist effects. (Note: quality values below about 25 generate
2-byte
quantization tables, which are considered optional in the JPEG standard.)