Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: 32-bit TIFFs and PIL
From: Ross Harder <rharder@aps.anl.gov>
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: "dvine@aps.anl.gov" <dvine@aps.anl.gov>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>, Timothy Madden <tmadden@aps.anl.gov>
Date: Fri, 23 Mar 2012 15:48:18 -0500
Hi Mark,

Thanks for your effort to decode the tiff issue.
I found this with random googling.  It seems happy to read the Uint32 tiffs.

http://www.lfd.uci.edu/~gohlke/code/tifffile.py.html

Ross


On Tue, Mar 20, 2012 at 11:11 PM, Mark Rivers <rivers@cars.uchicago.edu> wrote:
> Folks,
>
> I added the SampleFormat tag to TIFF files written with the areaDetector NDFileTIFF plugin.  I then ran a test with an IDL script that collects 1 image of each supported areaDetector data type (Int8, UInt8, Int16, UInt16, Int32, UInt32, Float32, Float64), and saves the images to TIFF files.  IDL then reads the TIFF file and displays the data type of the array in the file.  Here are the results:
>
> IDL> .run ~/devel/areaDetector/ADApp/pluginSrc/tiff_test
> DATA            BYTE      = Array[1024, 1024]
> DATA            BYTE      = Array[1024, 1024]
> DATA            INT       = Array[1024, 1024]
> DATA            UINT      = Array[1024, 1024]
> DATA            LONG      = Array[1024, 1024]
> DATA            ULONG     = Array[1024, 1024]
> DATA            FLOAT     = Array[1024, 1024]
> DATA            DOUBLE    = Array[1024, 1024]
>
> This is exactly as expected.  IDL only supports unsigned 8-bit integers, not signed, so it does not distinguish between Int8 and UInt8, but it successfully reads all the TIFF files.
>
> I then tried reading and displaying the files with ImageJ and PIL.
>
> Here are the results with ImageJ:
>
> Int8     OK
> UInt8    OK
> Int16    OK
> UInt16   OK
> Int32    OK
> UInt32   OK
> Float32  OK
> Float64  Fail
>
> So ImageJ does not support Float64, but does support all other types.
>
> Here are the results with PIL:
>
> Int8     Fail
> UInt8    OK
> Int16    OK
> UInt16   OK
> Int32    OK
> UInt32   Fail
> Float32  OK
> Float64  Fail
>
> So PIL does not support Int8, UInt32, or Float64.  It does support UInt8 and Int32, so it can read 8-bit and 32-bit TIFFs, but not both signed and unsigned.
>
> I've committed these changes to the areaDetector SVN repository (https://subversion.xor.aps.anl.gov/synApps/areaDetector/trunk) and they will be in the upcoming R1-8 release.
>
> Mark
>
>
> ________________________________________
> From: Mark Rivers
> Sent: Tuesday, March 20, 2012 2:34 PM
> To: 'J. Lewis Muir'
> Cc: Timothy Madden; dvine@aps.anl.gov; Ross Harder; tech-talk@aps.anl.gov
> Subject: RE: 32-bit TIFFs and PIL
>
> Hi Lewis,
>
> Thanks very much for tracking that down!
>
> I have added the SampleFormat tag to the areaDetector TIFF files, and now I can read signed 32-bit integer TIFFs with PIL. It will not read unsigned 32-bit TIFFs. By adding the SampleFormat tag I can now also successfully write 32-bit float and 64-bit double TIFF files as well. Those can be read fine with IDL, and the 32-bit float files can also be read by PIL.
>
> I will do testing with each areaDetector data type and report which applications (IDL, ImageJ, PIL) can read which data types.
>
> Thanks again,
> Mark
>
>
>
> -----Original Message-----
> From: J. Lewis Muir [mailto:jlmuir@imca-cat.org]
> Sent: Tuesday, March 20, 2012 11:48 AM
> To: Mark Rivers
> Cc: Timothy Madden; dvine@aps.anl.gov; Ross Harder; tech-talk@aps.anl.gov
> Subject: Re: 32-bit TIFFs and PIL
>
> On 3/20/12 11:25 AM, J. Lewis Muir wrote:
>> So it seems to be unhappy about the pixel mode.
>
> Looking further, there's a debug level variable in PIL which
> sheds more light on things:
>
> ===
>>>> import PIL.Image
>>>> PIL.Image.DEBUG = 1
>>>> im = PIL.Image.open("/tmp/im.tif")
> tag: ImageWidth (256) - type: short (3) - value: (1023,)
> tag: ImageLength (257) - type: short (3) - value: (1023,)
> tag: BitsPerSample (258) - type: short (3) - value: (32,)
> tag: Compression (259) - type: short (3) - value: (1,)
> tag: PhotometricInterpretation (262) - type: short (3) - value: (1,)
> tag: Make (271) - type: ascii (2) - value: Unknown
> tag: Model (272) - type: ascii (2) - value: Unknown
> tag: StripOffsets (273) - type: long (4) - value: (8,)
> tag: SamplesPerPixel (277) - type: short (3) - value: (1,)
> tag: RowsPerStrip (278) - type: short (3) - value: (1023,)
> tag: StripByteCounts (279) - type: long (4) - value: (4186116,)
> tag: PlanarConfiguration (284) - type: short (3) - value: (1,)
> *** Summary ***
> - compression: raw
> - photometric_interpretation: 1
> - planar_configuration: 1
> - fill_order: 1
> - size: (1023, 1023)
> format key: ('II', 1, 1, 1, (32,), ())
> - unsupported format
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File
> "/opt3/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL/Image.py",
> line 1980, in open
> raise IOError("cannot identify image file")
> IOError: cannot identify image file
> ===
>
> Looking at TiffImagePlugin.py where it generates the "-
> unsupported format" message, and comparing the output with an
> SLS PILATUS image that works, I see the following difference:
>
> === /tmp/im.tif (bad) ===
> format key: ('II', 1, 1, 1, (32,), ())
> ===
>
> === /tmp/sls-im.tif (good) ===
> format key: ('II', 1, 2, 1, (32,), ())
> ===
>
> The third format key value is different. Looking at
> TiffImagePlugin.py shows that the third value is the value of
> the SAMPLEFORMAT (339) tag. In the bad TIFF, that tag appears
> to be missing, but in the good TIFF, it's present and the debug
> output shows it:
>
> === /tmp/sls-im.tif (good) ===
> tag: SampleFormat (339) - type: short (3) - value: (2,)
> ===
>
> Lewis


References:
32-bit TIFFs and PIL Mark Rivers
Re: 32-bit TIFFs and PIL J. Lewis Muir
Re: 32-bit TIFFs and PIL J. Lewis Muir
RE: 32-bit TIFFs and PIL Mark Rivers
RE: 32-bit TIFFs and PIL Mark Rivers

Navigate by Date:
Prev: Proposed support for additional Modbus data types Mark Rivers
Next: waiting in sseq Pierrick Hanlet
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: RE: 32-bit TIFFs and PIL Mark Rivers
Next: [ASYN-vxi11] can't connect to Tektronix scope on Fedora 16 Pavel Masloff
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·