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 <[email protected]> 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; [email protected]; Ross Harder; [email protected]
> 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:[email protected]]
> Sent: Tuesday, March 20, 2012 11:48 AM
> To: Mark Rivers
> Cc: Timothy Madden; [email protected]; Ross Harder; [email protected]
> 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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|