[Image-SIG] PIL image resizing quality seems a little rough, any workarounds?

[Gary Speer]

Hi Fredrik -
I'm trying to tackle two issues -
1.  The syntax you suggested for the Photo module to use ANTIALIAS is
generating errors.  I tried the BICUBIC filter so that I could test it on a
working?? PIL 1.1.2 installation..  Please see no. 2 as this might be
installation related.
I tried:
            img = img.resize((width, height),Image.BICUBIC)
which gives an error type AttributeError, error value BICUBIC
and
            img = img.resize((width, height),"BICUBIC")  or
            img = img.resize((width, height),'BICUBIC')
patterned after your PIL documentation which gives an error type ValueError,
error value: undefined resampling filter

The last version gave me some hope that at least the syntax was getting to
the module that understands that a filter is being specified.

Any suggestions ???

2.  My second challenge may be related to the first in some way.  I am
trying to install PIL 1.1.3 in a Zope 2.5.1/Python 2.1.3/Win32 environment.
I have PIL successfully installed (or at least no errors until this one) by
following a how-to that said - Install the PY21 bundle.  Copy the PIL
directory to c:\Zope\libs\python\PIL,
copy the PIL.pth file to that python directory, copy the files _imaging.pyd,
tcl83.dll and tk83.dll to the c:\Zope\bin\lib\win32 directory.  That seems
to have been working.  I applied your PIL 113 upgrade on the PY21
installation and simply copied the newer PIL directory and newer
_imaging.pyd over their older counterparts.  I now appear to be functioning
normally again and presume I am successfully upgraded.

I noticed in attempting the steps above that in my traceback, the file
c:\PY21\PIL\Image.py was being called instead of the copy of that file that
is under the python directory in the Zope installation.  Apparently the
paths are embedded into the compiled files.  Would deleting all the pyc
files in the PIL directory help or is the issue in the _imaging.pyd? Since
the files are being found, I presume this kludge is working, but I would
rather simply have a clean install of PIL fully within a clean install of
Zope, but that puts me back to the lack of a Python registry key being
created when Zope is installed for your PIL installer to read that I
described in my last note

I don't know if this could be contributing to the error, above.  I am
struggling because I am not a Python programmer and have learned enough Zope
to be damgerous.  Nevertheless, after trying to get PIL into Zope for months
without replies until two weeks ago, I finally do have a (fully??)
functioning photo site via this installation and I would love to enhance it
with the ANTIALIAS filter.

Knowing PIL as you do, do I have a broken installation and should I start
clean and somehow hack the registry values to get your installer to work?
My concern is that the Python directory tree is different than zope's and in
zope the python executable is in C:\Zope\bin while most of the Python files
and products are under C:\Zope\lib\python.

I am so close to success with PIL and Photo123!  Any and all guidance would
be greatly appreciated!
Gary

By the way - I have been testing the syntax changes by editing the Photo.py
file in the Photo product directory using Idle, deleting the photo.pyc file,
Killing the Zope server and restarting Start.Bat so that it recompiles
photo.pyc as it loads.  Is there a faster/easier way to recompile a python
product file like photo.pyc on the fly without killing and restarting the
server for each iteration?

Again. many thanks for any suggestions you can provide.

----- Original Message -----
From: "Mail System Administrator" <mailhost@cdc.edu>
To: "Fredrik Lundh" <fredrik@pythonware.com>; <image-sig@python.org>
Cc: "Jeff Kowalczyk" <jtk@yahoo.com>
Sent: Saturday, July 13, 2002 9:32 AM
Subject: Re: [Image-SIG] PIL image resizing quality seems a little rough,
any workarounds?


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.)