<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I can confirm that this bug exists and that this patch works. I hope it
gets included in PIL 1.1.7<br>
<br>
Stani<br>
--<br>
<a class="moz-txt-link-freetext" href="http://photobatch.stani.be">http://photobatch.stani.be</a><br>
<br>
Florian H&ouml;ch wrote:
<blockquote cite="mid:47C7EA9E.4080405@hoech.org" type="cite">
  <pre wrap="">Hello Guy,

PIL 1.1.6 still seems to have a bug regarding its interpretation of 
TIFFTAG_RESOLUTIONUNIT, which could lead to "strange" values being 
written to the TIFF file.

I and Gary Bloom posted fixes to the list awhile ago. For convenience, 
here's the diff patch for TiffImagePlugin.py again, containing both mine 
(reading) and Gary's (writing) fix:


577,578c577,578
&lt;         xdpi = getscalar(X_RESOLUTION, (1, 1))
&lt;         ydpi = getscalar(Y_RESOLUTION, (1, 1))
---
 &gt;         xres = getscalar(X_RESOLUTION, (1, 1))
 &gt;         yres = getscalar(Y_RESOLUTION, (1, 1))
580,583c580,589
&lt;         if xdpi and ydpi and getscalar(RESOLUTION_UNIT, 1) == 1:
&lt;             xdpi = xdpi[0] / (xdpi[1] or 1)
&lt;             ydpi = ydpi[0] / (ydpi[1] or 1)
&lt;             self.info["dpi"] = xdpi, ydpi
---
 &gt;         if xres and yres:
 &gt;             xres = xres[0] / (xres[1] or 1)
 &gt;             yres = yres[0] / (yres[1] or 1)
 &gt;             resunit = getscalar(RESOLUTION_UNIT, 1)
 &gt;             if resunit == 2: # dots per inch
 &gt;                 self.info["dpi"] = xres, yres
 &gt;             elif resunit == 3: # dots per centimeter. convert to dpi
 &gt;                 self.info["dpi"] = xres * 2.54, yres * 2.54
 &gt;             else: # No absolute unit of measurement. Used for images 
that may
have a non-square aspect ratio, but no meaningful absolute dimensions.
 &gt;                 self.info["resolution"] = xres, yres
721c727
&lt;         ifd[RESOLUTION_UNIT] = 1
---
 &gt;         ifd[RESOLUTION_UNIT] = 2


To explain what the patch does: Without the fix, PIL's interpretation of 
RESOLUTION_UNIT is "off by one", e.g. RESOLUTION_UNIT 1 (no absolute 
unit of measurement) is treated as RESOLUTION_UNIT 2 (dots per inch).
The patch solves this and also takes into account RESOLUTION_UNIT 3 
(dots per centimeters) by converting to dots per inch and setting 
info["dpi"] accordingly. In the case of RESOLUTION_UNIT other than 2 or 
3, there may be no meaningful resolution set in the image. After 
applying the patch, this case can be checked for in your code if needed 
with yourimage.info.has_key("dpi") and if that returns False, checking 
yourimage.info["resolution"].
The fix currently has the small drawback that, if RESOLUTION_UNIT was 3 
(dpc) in the input image, when saving the TIFF file the resolution unit 
will always be dpi.

Regards,

Florian

Guy K. Kloss schrieb:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi,

I've just had some problems with PIL's implementation of the Image.save() 
method when writing TIFF files. Apparently some internal tags on resolution 
are totally out of the normal. Using the TIFFs from libtiff later on produces 
some warning on a tag with bad information.

This is what libtiff's warning handler produces:

_TIFFVSetField: diag.tif: Bad value 47088 for "ResolutionUnit".
diag.tif: Warning, "YResolution": Information lost writing value 
(-2.94176e-05) as (unsigned) RATIONAL.

According to Graeme Gill's information (who implements Argyll CMS, that's 
using libtiff for its purposes)

"""
[...] According to the TIFF spec, the ResolutionUnit tag can have one of three
values: (From tiff/libtiff/tiff.h)

#define TIFFTAG_RESOLUTIONUNIT      296 /* units of resolutions */
#define     RESUNIT_NONE        1   /* no meaningful units */
#define     RESUNIT_INCH        2   /* english */
#define     RESUNIT_CENTIMETER      3   /* metric */
"""

It seems like the implementation in PIL.Image for save() puts a non standard 
value (here 47088) into the field ResolutionUnit, and there also seems to be 
something funny with the YResolution field in the TIFF file.

To me this very much sounds like an issue with uninitialised variables in some 
structures, as the values tend to be different on different runs, as well as 
the fact that they're well out of whack indicates this.

Guy
    </pre>
  </blockquote>
  <pre wrap=""><!---->_______________________________________________
Image-SIG maillist  -  <a class="moz-txt-link-abbreviated" href="mailto:Image-SIG@python.org">Image-SIG@python.org</a>
<a class="moz-txt-link-freetext" href="http://mail.python.org/mailman/listinfo/image-sig">http://mail.python.org/mailman/listinfo/image-sig</a>
  </pre>
</blockquote>
<br>
</body>
</html>