python PIL 16-bit tiff files

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

python PIL 16-bit tiff files

Dan Blacker
Hello, I wonder if anyone can help with this problem:

I am trying to open 16-bit tif files with the Python Imaging Library, with this code:

im0 = Image.open (incolor)

I get this error:

Traceback (most recent call last):
  File "find.frame.py", line 137, in <module>
    im0 = Image.open (incolor)
  File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1917, in open
    raise IOError("cannot identify image file")
IOError: cannot identify image file

My code works fine with 8bit tiffs. Attatched is an example image file that it won't read in.

Any help would be greatly appreciated
Dan







_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig

16_bit_example.tif (861K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Sebastian Haase-3
Hi,

are you sure it makes even sense to save a 16-bit RGB image ? This is
not meant as an excuse for PIL to not support it,
but 16mio colors should likely be enough for any application (i.e.
8bit per R,G and B)

Regards,
Sebastian Haase


On Mon, Apr 12, 2010 at 10:33 AM, Dan Blacker
<[hidden email]> wrote:

> Hi Sebastian,
>
> Thanks so much for having a look at this,
>
> The image file is actually from an Epson v700 scanner, scanned using Vuescan
> in Ubuntu.
>
> It is an RGB image, not a grayscale one.
>
> Do you think I will be able to use this image with PIL? WIll I need to patch
> my version?
>
> Thanks again,
> Dan
>
>
>
>
>
> On 12 April 2010 08:37, Sebastian Haase <[hidden email]> wrote:
>>
>> Hi Dan,
>>
>> I'm running a patched version of PIL 1.1.6 and could open all (I
>> thought) 16-bit TIF images in the past.
>> But with yours I also got
>> IOError("cannot identify image file")
>>
>> To find out what the problem is I used ImageMagick
>> $: identify Download/16_bit_example.tif
>> Download/16_bit_example.tif TIFF 318x336 318x336+0+0 16-bit
>> DirectClass 645KB 0.000u 0:00.010
>>
>> So far this look fine.
>> But trying to use PIL's TIF module directly, I find:
>> >>> import TiffImagePlugin
>> >>> fp = open("/home/shaase/Download/16_bit_example.tif")
>> >>>
>> >>> TiffImagePlugin.TiffImageFile(fp,"/home/shaase/Download/16_bit_example.tif")
>> Traceback (most recent call last):
>>  File "<input>", line 1, in <module>
>>  File "./PIL/ImageFile.py", line 82, in __init__
>>    self._open()
>>  File "./PIL/TiffImagePlugin.py", line 507, in _open
>>    self._seek(0)
>>  File "./PIL/TiffImagePlugin.py", line 535, in _seek
>>    self._setup()
>>  File "./PIL/TiffImagePlugin.py", line 613, in _setup
>>    raise SyntaxError, "unknown pixel mode"
>> >>> pdb.pm()
>> (Pdb) p key
>> ('l', 2, 1, 1, (16, 16, 16), ())
>>
>> Aha, PIL thinks it's an 16-bit RGB image - i.e. not grayscale.
>> Is this correct ?
>>
>> Just for reference, I will paste my list of recognized "key"s below,
>> maybe someone knows what line would have to be added to support your
>> file.
>>
>> Cheers,
>> Sebastian Haase
>>
>> PS: Did you get this file by any chance from a Zeiss Microscope LSM
>> image ? - I just saw that I tried this in the past ...
>>
>> <code from patched 1.1.6
>>
>> TiffImagePlugin.py---------------------------------------------------------------------------------->
>>
>> OPEN_INFO = {
>>    # (ByteOrder, PhotoInterpretation, SampleFormat, FillOrder,
>> BitsPerSample,
>>    #  ExtraSamples) => mode, rawmode
>>    ('l', 0, 1, 1, (1,), ()): ("1", "1;I"),
>>    ('l', 0, 1, 2, (1,), ()): ("1", "1;IR"),
>>    ('l', 0, 1, 1, (8,), ()): ("L", "L;I"),
>>    ('l', 0, 1, 2, (8,), ()): ("L", "L;IR"),
>>    ('l', 1, 1, 1, (1,), ()): ("1", "1"),
>>    ('l', 1, 1, 2, (1,), ()): ("1", "1;R"),
>>    ('l', 1, 1, 1, (8,), ()): ("L", "L"),
>>    ('l', 1, 1, 1, (8,8), (2,)): ("LA", "LA"),
>>    ('l', 1, 1, 2, (8,), ()): ("L", "L;R"),
>>    ('l', 1, 1, 1, (16,), ()): ("I;16", "I;16"),
>>    ('l', 1, 2, 1, (16,), ()): ("I;16S", "I;16S"),
>>    ('l', 1, 2, 1, (32,), ()): ("I", "I;32S"),
>>    ('l', 1, 3, 1, (32,), ()): ("F", "F;32F"),
>>    ('l', 2, 1, 1, (8,8,8), ()): ("RGB", "RGB"),
>>    ('l', 2, 1, 1, (8,8,0), ()): ("RGB", "RGB"),#seb -- found in
>> LSM(Zeiss) files
>>    #('l', 2, 1, 1, (16,16,16), ()): ("RGB", "RGB"),#seb -- found in
>> LSM(Zeiss) files
>>    ('l', 2, 1, 2, (8,8,8), ()): ("RGB", "RGB;R"),
>>    #seb jeff's ('l', 2, 1, 1, (8,8,8,8), ()): ("RGBX", "RGBX"),#seb
>> -- found in LSM(Zeiss) files
>>    ('l', 2, 1, 1, (8,8,8,8), (0,)): ("RGBX", "RGBX"),
>>    ('l', 2, 1, 1, (8,8,8,8), (1,)): ("RGBA", "RGBa"),
>>    ('l', 2, 1, 1, (8,8,8,8), (2,)): ("RGBA", "RGBA"),
>>    ('l', 2, 1, 1, (8,8,8,8), (999,)): ("RGBA", "RGBA"), # corel draw 10
>>    ('l', 3, 1, 1, (1,), ()): ("P", "P;1"),
>>    ('l', 3, 1, 2, (1,), ()): ("P", "P;1R"),
>>    ('l', 3, 1, 1, (2,), ()): ("P", "P;2"),
>>    ('l', 3, 1, 2, (2,), ()): ("P", "P;2R"),
>>    ('l', 3, 1, 1, (4,), ()): ("P", "P;4"),
>>    ('l', 3, 1, 2, (4,), ()): ("P", "P;4R"),
>>    ('l', 3, 1, 1, (8,), ()): ("P", "P"),
>>    ('l', 3, 1, 1, (8,8), (2,)): ("PA", "PA"),
>>    ('l', 3, 1, 2, (8,), ()): ("P", "P;R"),
>>    ('l', 5, 1, 1, (8,8,8,8), ()): ("CMYK", "CMYK"),
>>    ('l', 6, 1, 1, (8,8,8), ()): ("YCbCr", "YCbCr"),
>>    ('l', 8, 1, 1, (8,8,8), ()): ("LAB", "LAB"),
>>
>>    ('b', 0, 1, 1, (1,), ()): ("1", "1;I"),
>>    ('b', 0, 1, 2, (1,), ()): ("1", "1;IR"),
>>    ('b', 0, 1, 1, (8,), ()): ("L", "L;I"),
>>    ('b', 0, 1, 2, (8,), ()): ("L", "L;IR"),
>>    ('b', 1, 1, 1, (1,), ()): ("1", "1"),
>>    ('b', 1, 1, 2, (1,), ()): ("1", "1;R"),
>>    ('b', 1, 1, 1, (8,), ()): ("L", "L"),
>>    ('b', 1, 1, 1, (8,8), (2,)): ("LA", "LA"),
>>    ('b', 1, 1, 2, (8,), ()): ("L", "L;R"),
>>    ('b', 1, 1, 1, (16,), ()): ("I;16B", "I;16B"),
>>    ('b', 1, 2, 1, (16,), ()): ("I;16BS", "I;16BS"),
>>    ('b', 1, 2, 1, (32,), ()): ("I;32BS", "I;32BS"),
>>    ('b', 1, 3, 1, (32,), ()): ("F;32BF", "F;32BF"),
>>    ('b', 2, 1, 1, (8,8,8), ()): ("RGB", "RGB"),
>>    ('b', 2, 1, 2, (8,8,8), ()): ("RGB", "RGB;R"),
>>    ('b', 2, 1, 1, (8,8,8,8), (0,)): ("RGBX", "RGBX"),
>>    ('b', 2, 1, 1, (8,8,8,8), (1,)): ("RGBA", "RGBa"),
>>    ('b', 2, 1, 1, (8,8,8,8), (2,)): ("RGBA", "RGBA"),
>>    ('b', 2, 1, 1, (8,8,8,8), (999,)): ("RGBA", "RGBA"), # corel draw 10
>>    ('b', 3, 1, 1, (1,), ()): ("P", "P;1"),
>>    ('b', 3, 1, 2, (1,), ()): ("P", "P;1R"),
>>    ('b', 3, 1, 1, (2,), ()): ("P", "P;2"),
>>    ('b', 3, 1, 2, (2,), ()): ("P", "P;2R"),
>>    ('b', 3, 1, 1, (4,), ()): ("P", "P;4"),
>>    ('b', 3, 1, 2, (4,), ()): ("P", "P;4R"),
>>    ('b', 3, 1, 1, (8,), ()): ("P", "P"),
>>    ('b', 3, 1, 1, (8,8), (2,)): ("PA", "PA"),
>>    ('b', 3, 1, 2, (8,), ()): ("P", "P;R"),
>>    ('b', 5, 1, 1, (8,8,8,8), ()): ("CMYK", "CMYK"),
>>    ('b', 6, 1, 1, (8,8,8), ()): ("YCbCr", "YCbCr"),
>>    ('b', 8, 1, 1, (8,8,8), ()): ("LAB", "LAB"),
>> }
>> </code from patched 1.1.6
>>
>> TiffImagePlugin.py---------------------------------------------------------------------------------->
>>
>>
>>
>> On Sat, Apr 10, 2010 at 6:08 PM, Dan Blacker <[hidden email]>
>> wrote:
>> > Hello, I wonder if anyone can help with this problem:
>> >
>> > I am trying to open 16-bit tif files with the Python Imaging Library,
>> > with
>> > this code:
>> >
>> > im0 = Image.open (incolor)
>> >
>> > I get this error:
>> >
>> > Traceback (most recent call last):
>> >   File "find.frame.py", line 137, in <module>
>> >     im0 = Image.open (incolor)
>> >   File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1917, in
>> > open
>> >     raise IOError("cannot identify image file")
>> > IOError: cannot identify image file
>> >
>> > My code works fine with 8bit tiffs. Attatched is an example image file
>> > that
>> > it won't read in.
>> >
>> > Any help would be greatly appreciated
>> > Dan
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Image-SIG maillist  -  [hidden email]
>> > http://mail.python.org/mailman/listinfo/image-sig
>> >
>> >
>
>
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Dan Blacker
Hi Sebastian,

Yes I am scanning film and need to retain the as much of the color information as possble, so 16bit is essential.

Could I perhaps do a convert with imagemagick - that would turn it into a 16bit tif file that PIL could read properly?

Cheers,
Dan





On 12 April 2010 12:32, Sebastian Haase <[hidden email]> wrote:
Hi,

are you sure it makes even sense to save a 16-bit RGB image ? This is
not meant as an excuse for PIL to not support it,
but 16mio colors should likely be enough for any application (i.e.
8bit per R,G and B)

Regards,
Sebastian Haase


On Mon, Apr 12, 2010 at 10:33 AM, Dan Blacker
<[hidden email]> wrote:
> Hi Sebastian,
>
> Thanks so much for having a look at this,
>
> The image file is actually from an Epson v700 scanner, scanned using Vuescan
> in Ubuntu.
>
> It is an RGB image, not a grayscale one.
>
> Do you think I will be able to use this image with PIL? WIll I need to patch
> my version?
>
> Thanks again,
> Dan
>
>
>
>
>
> On 12 April 2010 08:37, Sebastian Haase <[hidden email]> wrote:
>>
>> Hi Dan,
>>
>> I'm running a patched version of PIL 1.1.6 and could open all (I
>> thought) 16-bit TIF images in the past.
>> But with yours I also got
>> IOError("cannot identify image file")
>>
>> To find out what the problem is I used ImageMagick
>> $: identify Download/16_bit_example.tif
>> Download/16_bit_example.tif TIFF 318x336 318x336+0+0 16-bit
>> DirectClass 645KB 0.000u 0:00.010
>>
>> So far this look fine.
>> But trying to use PIL's TIF module directly, I find:
>> >>> import TiffImagePlugin
>> >>> fp = open("/home/shaase/Download/16_bit_example.tif")
>> >>>
>> >>> TiffImagePlugin.TiffImageFile(fp,"/home/shaase/Download/16_bit_example.tif")
>> Traceback (most recent call last):
>>  File "<input>", line 1, in <module>
>>  File "./PIL/ImageFile.py", line 82, in __init__
>>    self._open()
>>  File "./PIL/TiffImagePlugin.py", line 507, in _open
>>    self._seek(0)
>>  File "./PIL/TiffImagePlugin.py", line 535, in _seek
>>    self._setup()
>>  File "./PIL/TiffImagePlugin.py", line 613, in _setup
>>    raise SyntaxError, "unknown pixel mode"
>> >>> pdb.pm()
>> (Pdb) p key
>> ('l', 2, 1, 1, (16, 16, 16), ())
>>
>> Aha, PIL thinks it's an 16-bit RGB image - i.e. not grayscale.
>> Is this correct ?
>>
>> Just for reference, I will paste my list of recognized "key"s below,
>> maybe someone knows what line would have to be added to support your
>> file.
>>
>> Cheers,
>> Sebastian Haase
>>
>> PS: Did you get this file by any chance from a Zeiss Microscope LSM
>> image ? - I just saw that I tried this in the past ...
>>
>> <code from patched 1.1.6
>>
>> TiffImagePlugin.py---------------------------------------------------------------------------------->
>>
>> OPEN_INFO = {
>>    # (ByteOrder, PhotoInterpretation, SampleFormat, FillOrder,
>> BitsPerSample,
>>    #  ExtraSamples) => mode, rawmode
>>    ('l', 0, 1, 1, (1,), ()): ("1", "1;I"),
>>    ('l', 0, 1, 2, (1,), ()): ("1", "1;IR"),
>>    ('l', 0, 1, 1, (8,), ()): ("L", "L;I"),
>>    ('l', 0, 1, 2, (8,), ()): ("L", "L;IR"),
>>    ('l', 1, 1, 1, (1,), ()): ("1", "1"),
>>    ('l', 1, 1, 2, (1,), ()): ("1", "1;R"),
>>    ('l', 1, 1, 1, (8,), ()): ("L", "L"),
>>    ('l', 1, 1, 1, (8,8), (2,)): ("LA", "LA"),
>>    ('l', 1, 1, 2, (8,), ()): ("L", "L;R"),
>>    ('l', 1, 1, 1, (16,), ()): ("I;16", "I;16"),
>>    ('l', 1, 2, 1, (16,), ()): ("I;16S", "I;16S"),
>>    ('l', 1, 2, 1, (32,), ()): ("I", "I;32S"),
>>    ('l', 1, 3, 1, (32,), ()): ("F", "F;32F"),
>>    ('l', 2, 1, 1, (8,8,8), ()): ("RGB", "RGB"),
>>    ('l', 2, 1, 1, (8,8,0), ()): ("RGB", "RGB"),#seb -- found in
>> LSM(Zeiss) files
>>    #('l', 2, 1, 1, (16,16,16), ()): ("RGB", "RGB"),#seb -- found in
>> LSM(Zeiss) files
>>    ('l', 2, 1, 2, (8,8,8), ()): ("RGB", "RGB;R"),
>>    #seb jeff's ('l', 2, 1, 1, (8,8,8,8), ()): ("RGBX", "RGBX"),#seb
>> -- found in LSM(Zeiss) files
>>    ('l', 2, 1, 1, (8,8,8,8), (0,)): ("RGBX", "RGBX"),
>>    ('l', 2, 1, 1, (8,8,8,8), (1,)): ("RGBA", "RGBa"),
>>    ('l', 2, 1, 1, (8,8,8,8), (2,)): ("RGBA", "RGBA"),
>>    ('l', 2, 1, 1, (8,8,8,8), (999,)): ("RGBA", "RGBA"), # corel draw 10
>>    ('l', 3, 1, 1, (1,), ()): ("P", "P;1"),
>>    ('l', 3, 1, 2, (1,), ()): ("P", "P;1R"),
>>    ('l', 3, 1, 1, (2,), ()): ("P", "P;2"),
>>    ('l', 3, 1, 2, (2,), ()): ("P", "P;2R"),
>>    ('l', 3, 1, 1, (4,), ()): ("P", "P;4"),
>>    ('l', 3, 1, 2, (4,), ()): ("P", "P;4R"),
>>    ('l', 3, 1, 1, (8,), ()): ("P", "P"),
>>    ('l', 3, 1, 1, (8,8), (2,)): ("PA", "PA"),
>>    ('l', 3, 1, 2, (8,), ()): ("P", "P;R"),
>>    ('l', 5, 1, 1, (8,8,8,8), ()): ("CMYK", "CMYK"),
>>    ('l', 6, 1, 1, (8,8,8), ()): ("YCbCr", "YCbCr"),
>>    ('l', 8, 1, 1, (8,8,8), ()): ("LAB", "LAB"),
>>
>>    ('b', 0, 1, 1, (1,), ()): ("1", "1;I"),
>>    ('b', 0, 1, 2, (1,), ()): ("1", "1;IR"),
>>    ('b', 0, 1, 1, (8,), ()): ("L", "L;I"),
>>    ('b', 0, 1, 2, (8,), ()): ("L", "L;IR"),
>>    ('b', 1, 1, 1, (1,), ()): ("1", "1"),
>>    ('b', 1, 1, 2, (1,), ()): ("1", "1;R"),
>>    ('b', 1, 1, 1, (8,), ()): ("L", "L"),
>>    ('b', 1, 1, 1, (8,8), (2,)): ("LA", "LA"),
>>    ('b', 1, 1, 2, (8,), ()): ("L", "L;R"),
>>    ('b', 1, 1, 1, (16,), ()): ("I;16B", "I;16B"),
>>    ('b', 1, 2, 1, (16,), ()): ("I;16BS", "I;16BS"),
>>    ('b', 1, 2, 1, (32,), ()): ("I;32BS", "I;32BS"),
>>    ('b', 1, 3, 1, (32,), ()): ("F;32BF", "F;32BF"),
>>    ('b', 2, 1, 1, (8,8,8), ()): ("RGB", "RGB"),
>>    ('b', 2, 1, 2, (8,8,8), ()): ("RGB", "RGB;R"),
>>    ('b', 2, 1, 1, (8,8,8,8), (0,)): ("RGBX", "RGBX"),
>>    ('b', 2, 1, 1, (8,8,8,8), (1,)): ("RGBA", "RGBa"),
>>    ('b', 2, 1, 1, (8,8,8,8), (2,)): ("RGBA", "RGBA"),
>>    ('b', 2, 1, 1, (8,8,8,8), (999,)): ("RGBA", "RGBA"), # corel draw 10
>>    ('b', 3, 1, 1, (1,), ()): ("P", "P;1"),
>>    ('b', 3, 1, 2, (1,), ()): ("P", "P;1R"),
>>    ('b', 3, 1, 1, (2,), ()): ("P", "P;2"),
>>    ('b', 3, 1, 2, (2,), ()): ("P", "P;2R"),
>>    ('b', 3, 1, 1, (4,), ()): ("P", "P;4"),
>>    ('b', 3, 1, 2, (4,), ()): ("P", "P;4R"),
>>    ('b', 3, 1, 1, (8,), ()): ("P", "P"),
>>    ('b', 3, 1, 1, (8,8), (2,)): ("PA", "PA"),
>>    ('b', 3, 1, 2, (8,), ()): ("P", "P;R"),
>>    ('b', 5, 1, 1, (8,8,8,8), ()): ("CMYK", "CMYK"),
>>    ('b', 6, 1, 1, (8,8,8), ()): ("YCbCr", "YCbCr"),
>>    ('b', 8, 1, 1, (8,8,8), ()): ("LAB", "LAB"),
>> }
>> </code from patched 1.1.6
>>
>> TiffImagePlugin.py---------------------------------------------------------------------------------->
>>
>>
>>
>> On Sat, Apr 10, 2010 at 6:08 PM, Dan Blacker <[hidden email]>
>> wrote:
>> > Hello, I wonder if anyone can help with this problem:
>> >
>> > I am trying to open 16-bit tif files with the Python Imaging Library,
>> > with
>> > this code:
>> >
>> > im0 = Image.open (incolor)
>> >
>> > I get this error:
>> >
>> > Traceback (most recent call last):
>> >   File "find.frame.py", line 137, in <module>
>> >     im0 = Image.open (incolor)
>> >   File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1917, in
>> > open
>> >     raise IOError("cannot identify image file")
>> > IOError: cannot identify image file
>> >
>> > My code works fine with 8bit tiffs. Attatched is an example image file
>> > that
>> > it won't read in.
>> >
>> > Any help would be greatly appreciated
>> > Dan
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Image-SIG maillist  -  [hidden email]
>> > http://mail.python.org/mailman/listinfo/image-sig
>> >
>> >
>
>


_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Sebastian Haase-3
Dan,
My point was also, that I would doubt that there is physically(!) more
information than 16e6 possible values per pixel.
A digital gray scale CCD camera with more than 12 bits costs multiple
1000s of Euros or Dollars...

Maybe you could use imagemagick to convert 1 16bit RGB into 3 16bit
gray images and read those into PIL.
Can I ask what your overall intend with all of this is ?

Cheers,
Sebastian



On Mon, Apr 12, 2010 at 1:42 PM, Dan Blacker <[hidden email]> wrote:

> Hi Sebastian,
>
> Yes I am scanning film and need to retain the as much of the color
> information as possble, so 16bit is essential.
>
> Could I perhaps do a convert with imagemagick - that would turn it into a
> 16bit tif file that PIL could read properly?
>
> Cheers,
> Dan
>
>
>
>
>
> On 12 April 2010 12:32, Sebastian Haase <[hidden email]> wrote:
>>
>> Hi,
>>
>> are you sure it makes even sense to save a 16-bit RGB image ? This is
>> not meant as an excuse for PIL to not support it,
>> but 16mio colors should likely be enough for any application (i.e.
>> 8bit per R,G and B)
>>
>> Regards,
>> Sebastian Haase
>>
>>
>> On Mon, Apr 12, 2010 at 10:33 AM, Dan Blacker
>> <[hidden email]> wrote:
>> > Hi Sebastian,
>> >
>> > Thanks so much for having a look at this,
>> >
>> > The image file is actually from an Epson v700 scanner, scanned using
>> > Vuescan
>> > in Ubuntu.
>> >
>> > It is an RGB image, not a grayscale one.
>> >
>> > Do you think I will be able to use this image with PIL? WIll I need to
>> > patch
>> > my version?
>> >
>> > Thanks again,
>> > Dan
>> >
>> >
>> >
>> >
>> >
>> > On 12 April 2010 08:37, Sebastian Haase <[hidden email]> wrote:
>> >>
>> >> Hi Dan,
>> >>
>> >> I'm running a patched version of PIL 1.1.6 and could open all (I
>> >> thought) 16-bit TIF images in the past.
>> >> But with yours I also got
>> >> IOError("cannot identify image file")
>> >>
>> >> To find out what the problem is I used ImageMagick
>> >> $: identify Download/16_bit_example.tif
>> >> Download/16_bit_example.tif TIFF 318x336 318x336+0+0 16-bit
>> >> DirectClass 645KB 0.000u 0:00.010
>> >>
>> >> So far this look fine.
>> >> But trying to use PIL's TIF module directly, I find:
>> >> >>> import TiffImagePlugin
>> >> >>> fp = open("/home/shaase/Download/16_bit_example.tif")
>> >> >>>
>> >> >>>
>> >> >>> TiffImagePlugin.TiffImageFile(fp,"/home/shaase/Download/16_bit_example.tif")
>> >> Traceback (most recent call last):
>> >>  File "<input>", line 1, in <module>
>> >>  File "./PIL/ImageFile.py", line 82, in __init__
>> >>    self._open()
>> >>  File "./PIL/TiffImagePlugin.py", line 507, in _open
>> >>    self._seek(0)
>> >>  File "./PIL/TiffImagePlugin.py", line 535, in _seek
>> >>    self._setup()
>> >>  File "./PIL/TiffImagePlugin.py", line 613, in _setup
>> >>    raise SyntaxError, "unknown pixel mode"
>> >> >>> pdb.pm()
>> >> (Pdb) p key
>> >> ('l', 2, 1, 1, (16, 16, 16), ())
>> >>
>> >> Aha, PIL thinks it's an 16-bit RGB image - i.e. not grayscale.
>> >> Is this correct ?
>> >>
>> >> Just for reference, I will paste my list of recognized "key"s below,
>> >> maybe someone knows what line would have to be added to support your
>> >> file.
>> >>
>> >> Cheers,
>> >> Sebastian Haase
>> >>
>> >> PS: Did you get this file by any chance from a Zeiss Microscope LSM
>> >> image ? - I just saw that I tried this in the past ...
>> >>
>> >> <code from patched 1.1.6
>> >>
>> >>
>> >> TiffImagePlugin.py---------------------------------------------------------------------------------->
>> >>
>> >> OPEN_INFO = {
>> >>    # (ByteOrder, PhotoInterpretation, SampleFormat, FillOrder,
>> >> BitsPerSample,
>> >>    #  ExtraSamples) => mode, rawmode
>> >>    ('l', 0, 1, 1, (1,), ()): ("1", "1;I"),
>> >>    ('l', 0, 1, 2, (1,), ()): ("1", "1;IR"),
>> >>    ('l', 0, 1, 1, (8,), ()): ("L", "L;I"),
>> >>    ('l', 0, 1, 2, (8,), ()): ("L", "L;IR"),
>> >>    ('l', 1, 1, 1, (1,), ()): ("1", "1"),
>> >>    ('l', 1, 1, 2, (1,), ()): ("1", "1;R"),
>> >>    ('l', 1, 1, 1, (8,), ()): ("L", "L"),
>> >>    ('l', 1, 1, 1, (8,8), (2,)): ("LA", "LA"),
>> >>    ('l', 1, 1, 2, (8,), ()): ("L", "L;R"),
>> >>    ('l', 1, 1, 1, (16,), ()): ("I;16", "I;16"),
>> >>    ('l', 1, 2, 1, (16,), ()): ("I;16S", "I;16S"),
>> >>    ('l', 1, 2, 1, (32,), ()): ("I", "I;32S"),
>> >>    ('l', 1, 3, 1, (32,), ()): ("F", "F;32F"),
>> >>    ('l', 2, 1, 1, (8,8,8), ()): ("RGB", "RGB"),
>> >>    ('l', 2, 1, 1, (8,8,0), ()): ("RGB", "RGB"),#seb -- found in
>> >> LSM(Zeiss) files
>> >>    #('l', 2, 1, 1, (16,16,16), ()): ("RGB", "RGB"),#seb -- found in
>> >> LSM(Zeiss) files
>> >>    ('l', 2, 1, 2, (8,8,8), ()): ("RGB", "RGB;R"),
>> >>    #seb jeff's ('l', 2, 1, 1, (8,8,8,8), ()): ("RGBX", "RGBX"),#seb
>> >> -- found in LSM(Zeiss) files
>> >>    ('l', 2, 1, 1, (8,8,8,8), (0,)): ("RGBX", "RGBX"),
>> >>    ('l', 2, 1, 1, (8,8,8,8), (1,)): ("RGBA", "RGBa"),
>> >>    ('l', 2, 1, 1, (8,8,8,8), (2,)): ("RGBA", "RGBA"),
>> >>    ('l', 2, 1, 1, (8,8,8,8), (999,)): ("RGBA", "RGBA"), # corel draw 10
>> >>    ('l', 3, 1, 1, (1,), ()): ("P", "P;1"),
>> >>    ('l', 3, 1, 2, (1,), ()): ("P", "P;1R"),
>> >>    ('l', 3, 1, 1, (2,), ()): ("P", "P;2"),
>> >>    ('l', 3, 1, 2, (2,), ()): ("P", "P;2R"),
>> >>    ('l', 3, 1, 1, (4,), ()): ("P", "P;4"),
>> >>    ('l', 3, 1, 2, (4,), ()): ("P", "P;4R"),
>> >>    ('l', 3, 1, 1, (8,), ()): ("P", "P"),
>> >>    ('l', 3, 1, 1, (8,8), (2,)): ("PA", "PA"),
>> >>    ('l', 3, 1, 2, (8,), ()): ("P", "P;R"),
>> >>    ('l', 5, 1, 1, (8,8,8,8), ()): ("CMYK", "CMYK"),
>> >>    ('l', 6, 1, 1, (8,8,8), ()): ("YCbCr", "YCbCr"),
>> >>    ('l', 8, 1, 1, (8,8,8), ()): ("LAB", "LAB"),
>> >>
>> >>    ('b', 0, 1, 1, (1,), ()): ("1", "1;I"),
>> >>    ('b', 0, 1, 2, (1,), ()): ("1", "1;IR"),
>> >>    ('b', 0, 1, 1, (8,), ()): ("L", "L;I"),
>> >>    ('b', 0, 1, 2, (8,), ()): ("L", "L;IR"),
>> >>    ('b', 1, 1, 1, (1,), ()): ("1", "1"),
>> >>    ('b', 1, 1, 2, (1,), ()): ("1", "1;R"),
>> >>    ('b', 1, 1, 1, (8,), ()): ("L", "L"),
>> >>    ('b', 1, 1, 1, (8,8), (2,)): ("LA", "LA"),
>> >>    ('b', 1, 1, 2, (8,), ()): ("L", "L;R"),
>> >>    ('b', 1, 1, 1, (16,), ()): ("I;16B", "I;16B"),
>> >>    ('b', 1, 2, 1, (16,), ()): ("I;16BS", "I;16BS"),
>> >>    ('b', 1, 2, 1, (32,), ()): ("I;32BS", "I;32BS"),
>> >>    ('b', 1, 3, 1, (32,), ()): ("F;32BF", "F;32BF"),
>> >>    ('b', 2, 1, 1, (8,8,8), ()): ("RGB", "RGB"),
>> >>    ('b', 2, 1, 2, (8,8,8), ()): ("RGB", "RGB;R"),
>> >>    ('b', 2, 1, 1, (8,8,8,8), (0,)): ("RGBX", "RGBX"),
>> >>    ('b', 2, 1, 1, (8,8,8,8), (1,)): ("RGBA", "RGBa"),
>> >>    ('b', 2, 1, 1, (8,8,8,8), (2,)): ("RGBA", "RGBA"),
>> >>    ('b', 2, 1, 1, (8,8,8,8), (999,)): ("RGBA", "RGBA"), # corel draw 10
>> >>    ('b', 3, 1, 1, (1,), ()): ("P", "P;1"),
>> >>    ('b', 3, 1, 2, (1,), ()): ("P", "P;1R"),
>> >>    ('b', 3, 1, 1, (2,), ()): ("P", "P;2"),
>> >>    ('b', 3, 1, 2, (2,), ()): ("P", "P;2R"),
>> >>    ('b', 3, 1, 1, (4,), ()): ("P", "P;4"),
>> >>    ('b', 3, 1, 2, (4,), ()): ("P", "P;4R"),
>> >>    ('b', 3, 1, 1, (8,), ()): ("P", "P"),
>> >>    ('b', 3, 1, 1, (8,8), (2,)): ("PA", "PA"),
>> >>    ('b', 3, 1, 2, (8,), ()): ("P", "P;R"),
>> >>    ('b', 5, 1, 1, (8,8,8,8), ()): ("CMYK", "CMYK"),
>> >>    ('b', 6, 1, 1, (8,8,8), ()): ("YCbCr", "YCbCr"),
>> >>    ('b', 8, 1, 1, (8,8,8), ()): ("LAB", "LAB"),
>> >> }
>> >> </code from patched 1.1.6
>> >>
>> >>
>> >> TiffImagePlugin.py---------------------------------------------------------------------------------->
>> >>
>> >>
>> >>
>> >> On Sat, Apr 10, 2010 at 6:08 PM, Dan Blacker
>> >> <[hidden email]>
>> >> wrote:
>> >> > Hello, I wonder if anyone can help with this problem:
>> >> >
>> >> > I am trying to open 16-bit tif files with the Python Imaging Library,
>> >> > with
>> >> > this code:
>> >> >
>> >> > im0 = Image.open (incolor)
>> >> >
>> >> > I get this error:
>> >> >
>> >> > Traceback (most recent call last):
>> >> >   File "find.frame.py", line 137, in <module>
>> >> >     im0 = Image.open (incolor)
>> >> >   File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1917, in
>> >> > open
>> >> >     raise IOError("cannot identify image file")
>> >> > IOError: cannot identify image file
>> >> >
>> >> > My code works fine with 8bit tiffs. Attatched is an example image
>> >> > file
>> >> > that
>> >> > it won't read in.
>> >> >
>> >> > Any help would be greatly appreciated
>> >> > Dan
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Image-SIG maillist  -  [hidden email]
>> >> > http://mail.python.org/mailman/listinfo/image-sig
>> >> >
>> >> >
>> >
>> >
>
>
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Dan Blacker
It is the CCD in this that is capturing the information:

http://www.epson.com/cgi-bin/Store/consumer/consDetail.jsp?oid=63056499

Are you saying that scanning at 48bit is pointless? Surley to advertise that feature on the scanner it must yeild more color information than at 24bit.

My script reads in an image of a strip of 8mm film, detects sprocket holes and crops and saves out each individual frame. It works with the 24bit color images from the scanner - but when I set the scanner to 48 bit color, PIL cannot read in the resultant 16-bit tiff files.





On 12 April 2010 13:34, Sebastian Haase <[hidden email]> wrote:
Dan,
My point was also, that I would doubt that there is physically(!) more
information than 16e6 possible values per pixel.
A digital gray scale CCD camera with more than 12 bits costs multiple
1000s of Euros or Dollars...

Maybe you could use imagemagick to convert 1 16bit RGB into 3 16bit
gray images and read those into PIL.
Can I ask what your overall intend with all of this is ?

Cheers,
Sebastian



On Mon, Apr 12, 2010 at 1:42 PM, Dan Blacker <[hidden email]> wrote:
> Hi Sebastian,
>
> Yes I am scanning film and need to retain the as much of the color
> information as possble, so 16bit is essential.
>
> Could I perhaps do a convert with imagemagick - that would turn it into a
> 16bit tif file that PIL could read properly?
>
> Cheers,
> Dan
>
>
>
>
>
> On 12 April 2010 12:32, Sebastian Haase <[hidden email]> wrote:
>>
>> Hi,
>>
>> are you sure it makes even sense to save a 16-bit RGB image ? This is
>> not meant as an excuse for PIL to not support it,
>> but 16mio colors should likely be enough for any application (i.e.
>> 8bit per R,G and B)
>>
>> Regards,
>> Sebastian Haase
>>
>>
>> On Mon, Apr 12, 2010 at 10:33 AM, Dan Blacker
>> <[hidden email]> wrote:
>> > Hi Sebastian,
>> >
>> > Thanks so much for having a look at this,
>> >
>> > The image file is actually from an Epson v700 scanner, scanned using
>> > Vuescan
>> > in Ubuntu.
>> >
>> > It is an RGB image, not a grayscale one.
>> >
>> > Do you think I will be able to use this image with PIL? WIll I need to
>> > patch
>> > my version?
>> >
>> > Thanks again,
>> > Dan
>> >
>> >
>> >
>> >
>> >
>> > On 12 April 2010 08:37, Sebastian Haase <[hidden email]> wrote:
>> >>
>> >> Hi Dan,
>> >>
>> >> I'm running a patched version of PIL 1.1.6 and could open all (I
>> >> thought) 16-bit TIF images in the past.
>> >> But with yours I also got
>> >> IOError("cannot identify image file")
>> >>
>> >> To find out what the problem is I used ImageMagick
>> >> $: identify Download/16_bit_example.tif
>> >> Download/16_bit_example.tif TIFF 318x336 318x336+0+0 16-bit
>> >> DirectClass 645KB 0.000u 0:00.010
>> >>
>> >> So far this look fine.
>> >> But trying to use PIL's TIF module directly, I find:
>> >> >>> import TiffImagePlugin
>> >> >>> fp = open("/home/shaase/Download/16_bit_example.tif")
>> >> >>>
>> >> >>>
>> >> >>> TiffImagePlugin.TiffImageFile(fp,"/home/shaase/Download/16_bit_example.tif")
>> >> Traceback (most recent call last):
>> >>  File "<input>", line 1, in <module>
>> >>  File "./PIL/ImageFile.py", line 82, in __init__
>> >>    self._open()
>> >>  File "./PIL/TiffImagePlugin.py", line 507, in _open
>> >>    self._seek(0)
>> >>  File "./PIL/TiffImagePlugin.py", line 535, in _seek
>> >>    self._setup()
>> >>  File "./PIL/TiffImagePlugin.py", line 613, in _setup
>> >>    raise SyntaxError, "unknown pixel mode"
>> >> >>> pdb.pm()
>> >> (Pdb) p key
>> >> ('l', 2, 1, 1, (16, 16, 16), ())
>> >>
>> >> Aha, PIL thinks it's an 16-bit RGB image - i.e. not grayscale.
>> >> Is this correct ?
>> >>
>> >> Just for reference, I will paste my list of recognized "key"s below,
>> >> maybe someone knows what line would have to be added to support your
>> >> file.
>> >>
>> >> Cheers,
>> >> Sebastian Haase
>> >>
>> >> PS: Did you get this file by any chance from a Zeiss Microscope LSM
>> >> image ? - I just saw that I tried this in the past ...
>> >>
>> >> <code from patched 1.1.6
>> >>
>> >>
>> >> TiffImagePlugin.py---------------------------------------------------------------------------------->
>> >>
>> >> OPEN_INFO = {
>> >>    # (ByteOrder, PhotoInterpretation, SampleFormat, FillOrder,
>> >> BitsPerSample,
>> >>    #  ExtraSamples) => mode, rawmode
>> >>    ('l', 0, 1, 1, (1,), ()): ("1", "1;I"),
>> >>    ('l', 0, 1, 2, (1,), ()): ("1", "1;IR"),
>> >>    ('l', 0, 1, 1, (8,), ()): ("L", "L;I"),
>> >>    ('l', 0, 1, 2, (8,), ()): ("L", "L;IR"),
>> >>    ('l', 1, 1, 1, (1,), ()): ("1", "1"),
>> >>    ('l', 1, 1, 2, (1,), ()): ("1", "1;R"),
>> >>    ('l', 1, 1, 1, (8,), ()): ("L", "L"),
>> >>    ('l', 1, 1, 1, (8,8), (2,)): ("LA", "LA"),
>> >>    ('l', 1, 1, 2, (8,), ()): ("L", "L;R"),
>> >>    ('l', 1, 1, 1, (16,), ()): ("I;16", "I;16"),
>> >>    ('l', 1, 2, 1, (16,), ()): ("I;16S", "I;16S"),
>> >>    ('l', 1, 2, 1, (32,), ()): ("I", "I;32S"),
>> >>    ('l', 1, 3, 1, (32,), ()): ("F", "F;32F"),
>> >>    ('l', 2, 1, 1, (8,8,8), ()): ("RGB", "RGB"),
>> >>    ('l', 2, 1, 1, (8,8,0), ()): ("RGB", "RGB"),#seb -- found in
>> >> LSM(Zeiss) files
>> >>    #('l', 2, 1, 1, (16,16,16), ()): ("RGB", "RGB"),#seb -- found in
>> >> LSM(Zeiss) files
>> >>    ('l', 2, 1, 2, (8,8,8), ()): ("RGB", "RGB;R"),
>> >>    #seb jeff's ('l', 2, 1, 1, (8,8,8,8), ()): ("RGBX", "RGBX"),#seb
>> >> -- found in LSM(Zeiss) files
>> >>    ('l', 2, 1, 1, (8,8,8,8), (0,)): ("RGBX", "RGBX"),
>> >>    ('l', 2, 1, 1, (8,8,8,8), (1,)): ("RGBA", "RGBa"),
>> >>    ('l', 2, 1, 1, (8,8,8,8), (2,)): ("RGBA", "RGBA"),
>> >>    ('l', 2, 1, 1, (8,8,8,8), (999,)): ("RGBA", "RGBA"), # corel draw 10
>> >>    ('l', 3, 1, 1, (1,), ()): ("P", "P;1"),
>> >>    ('l', 3, 1, 2, (1,), ()): ("P", "P;1R"),
>> >>    ('l', 3, 1, 1, (2,), ()): ("P", "P;2"),
>> >>    ('l', 3, 1, 2, (2,), ()): ("P", "P;2R"),
>> >>    ('l', 3, 1, 1, (4,), ()): ("P", "P;4"),
>> >>    ('l', 3, 1, 2, (4,), ()): ("P", "P;4R"),
>> >>    ('l', 3, 1, 1, (8,), ()): ("P", "P"),
>> >>    ('l', 3, 1, 1, (8,8), (2,)): ("PA", "PA"),
>> >>    ('l', 3, 1, 2, (8,), ()): ("P", "P;R"),
>> >>    ('l', 5, 1, 1, (8,8,8,8), ()): ("CMYK", "CMYK"),
>> >>    ('l', 6, 1, 1, (8,8,8), ()): ("YCbCr", "YCbCr"),
>> >>    ('l', 8, 1, 1, (8,8,8), ()): ("LAB", "LAB"),
>> >>
>> >>    ('b', 0, 1, 1, (1,), ()): ("1", "1;I"),
>> >>    ('b', 0, 1, 2, (1,), ()): ("1", "1;IR"),
>> >>    ('b', 0, 1, 1, (8,), ()): ("L", "L;I"),
>> >>    ('b', 0, 1, 2, (8,), ()): ("L", "L;IR"),
>> >>    ('b', 1, 1, 1, (1,), ()): ("1", "1"),
>> >>    ('b', 1, 1, 2, (1,), ()): ("1", "1;R"),
>> >>    ('b', 1, 1, 1, (8,), ()): ("L", "L"),
>> >>    ('b', 1, 1, 1, (8,8), (2,)): ("LA", "LA"),
>> >>    ('b', 1, 1, 2, (8,), ()): ("L", "L;R"),
>> >>    ('b', 1, 1, 1, (16,), ()): ("I;16B", "I;16B"),
>> >>    ('b', 1, 2, 1, (16,), ()): ("I;16BS", "I;16BS"),
>> >>    ('b', 1, 2, 1, (32,), ()): ("I;32BS", "I;32BS"),
>> >>    ('b', 1, 3, 1, (32,), ()): ("F;32BF", "F;32BF"),
>> >>    ('b', 2, 1, 1, (8,8,8), ()): ("RGB", "RGB"),
>> >>    ('b', 2, 1, 2, (8,8,8), ()): ("RGB", "RGB;R"),
>> >>    ('b', 2, 1, 1, (8,8,8,8), (0,)): ("RGBX", "RGBX"),
>> >>    ('b', 2, 1, 1, (8,8,8,8), (1,)): ("RGBA", "RGBa"),
>> >>    ('b', 2, 1, 1, (8,8,8,8), (2,)): ("RGBA", "RGBA"),
>> >>    ('b', 2, 1, 1, (8,8,8,8), (999,)): ("RGBA", "RGBA"), # corel draw 10
>> >>    ('b', 3, 1, 1, (1,), ()): ("P", "P;1"),
>> >>    ('b', 3, 1, 2, (1,), ()): ("P", "P;1R"),
>> >>    ('b', 3, 1, 1, (2,), ()): ("P", "P;2"),
>> >>    ('b', 3, 1, 2, (2,), ()): ("P", "P;2R"),
>> >>    ('b', 3, 1, 1, (4,), ()): ("P", "P;4"),
>> >>    ('b', 3, 1, 2, (4,), ()): ("P", "P;4R"),
>> >>    ('b', 3, 1, 1, (8,), ()): ("P", "P"),
>> >>    ('b', 3, 1, 1, (8,8), (2,)): ("PA", "PA"),
>> >>    ('b', 3, 1, 2, (8,), ()): ("P", "P;R"),
>> >>    ('b', 5, 1, 1, (8,8,8,8), ()): ("CMYK", "CMYK"),
>> >>    ('b', 6, 1, 1, (8,8,8), ()): ("YCbCr", "YCbCr"),
>> >>    ('b', 8, 1, 1, (8,8,8), ()): ("LAB", "LAB"),
>> >> }
>> >> </code from patched 1.1.6
>> >>
>> >>
>> >> TiffImagePlugin.py---------------------------------------------------------------------------------->
>> >>
>> >>
>> >>
>> >> On Sat, Apr 10, 2010 at 6:08 PM, Dan Blacker
>> >> <[hidden email]>
>> >> wrote:
>> >> > Hello, I wonder if anyone can help with this problem:
>> >> >
>> >> > I am trying to open 16-bit tif files with the Python Imaging Library,
>> >> > with
>> >> > this code:
>> >> >
>> >> > im0 = Image.open (incolor)
>> >> >
>> >> > I get this error:
>> >> >
>> >> > Traceback (most recent call last):
>> >> >   File "find.frame.py", line 137, in <module>
>> >> >     im0 = Image.open (incolor)
>> >> >   File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1917, in
>> >> > open
>> >> >     raise IOError("cannot identify image file")
>> >> > IOError: cannot identify image file
>> >> >
>> >> > My code works fine with 8bit tiffs. Attatched is an example image
>> >> > file
>> >> > that
>> >> > it won't read in.
>> >> >
>> >> > Any help would be greatly appreciated
>> >> > Dan
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Image-SIG maillist  -  [hidden email]
>> >> > http://mail.python.org/mailman/listinfo/image-sig
>> >> >
>> >> >
>> >
>> >
>
>


_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Oliver Tonnhofer-4
In reply to this post by Sebastian Haase-3

On 12.04.2010, at 14:34, Sebastian Haase wrote:
> My point was also, that I would doubt that there is physically(!) more
> information than 16e6 possible values per pixel.
> A digital gray scale CCD camera with more than 12 bits costs multiple
> 1000s of Euros or Dollars...

Every current DSLR camera has more than 8bits per color, a Canon EOS  
450D has 14bit for example. While a human eye might not see any  
difference with more than 8bits, you can use the information when  
manipulating the image (e.g. change the exposure/brightness).

Regards,
Oliver
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Dan Blacker
Yes, it is important for me to have all this extra color information, although you are unable to see it, it is very useful when color grading /adjusting levels etc of the scanned film.

But does anyone have any idea how I can get PIL to read my file?

Thanks,




On 12 April 2010 15:30, Oliver Tonnhofer <[hidden email]> wrote:

On 12.04.2010, at 14:34, Sebastian Haase wrote:
My point was also, that I would doubt that there is physically(!) more
information than 16e6 possible values per pixel.
A digital gray scale CCD camera with more than 12 bits costs multiple
1000s of Euros or Dollars...

Every current DSLR camera has more than 8bits per color, a Canon EOS 450D has 14bit for example. While a human eye might not see any difference with more than 8bits, you can use the information when manipulating the image (e.g. change the exposure/brightness).

Regards,
Oliver


_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

jcupitt
In reply to this post by Oliver Tonnhofer-4
On 12 April 2010 15:30, Oliver Tonnhofer <[hidden email]> wrote:
> On 12.04.2010, at 14:34, Sebastian Haase wrote:
>> My point was also, that I would doubt that there is physically(!) more
>> information than 16e6 possible values per pixel.
>> A digital gray scale CCD camera with more than 12 bits costs multiple
>> 1000s of Euros or Dollars...
>
> Every current DSLR camera has more than 8bits per color, a Canon EOS 450D
> has 14bit for example.

That's linear bits though. Once you add a companding curve (like a
gamma) to it, you can get away with many fewer bits than that. As a
rough guide, a high-quality uncooled CCD is good for up to about 12
bits linear, or 8 - 10 bits with a gamma.

Most flatbed scanners use a line sensor with rather a short exposure
time (only a few ms) to keep the scan-speed up. As Sebastian says, you
are unlikely to be getting more than 8 bits of signal.

John
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Guy K. Kloss-2
In reply to this post by Sebastian Haase-3
On Mon, 12 Apr 2010 23:32:32 Sebastian Haase wrote:
> are you sure it makes even sense to save a 16-bit RGB image ? This is
> not meant as an excuse for PIL to not support it,
> but 16mio colors should likely be enough for any application (i.e.
> 8bit per R,G and B)

It does make sense. Absolutely! Maybe not if you are *just* thinking in terms
of final output for an end user, but during the whole
capturing/processing/manipulation phase one can reduce many artifacts
introduced through rounding, etc. Also when images are touched up by changing
lightness or contrast images tend to expose "banding" quite severely.

This and other effects are also the background behind the increasing
popularity of HDR (High Dynamic Range) imaging. Particularly in scientific
imaging subtle differences are much preserved this way. And it looked like
Dan's image is the result of a microscopic picture, or something like that,
with low contrast. So it could strongly benefit from a change in lightness and
contrast.

Higher channel bit depth are important for these cases, and even more to keep
up with needed capabilities for the future!

Guy

--
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Pūtaiao o Mōhiohio me Pāngarau
Massey University, Albany (North Shore City, Auckland)
473 State Highway 17, Gate 1, Mailroom, Quad B Building
voice: +64 9 414-0800 ext. 9266   fax: +64 9 441-8181
[hidden email] http://www.massey.ac.nz/~gkloss

_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Sebastian Haase-3
On Tue, Apr 13, 2010 at 2:16 AM, Guy K. Kloss <[hidden email]> wrote:

> On Mon, 12 Apr 2010 23:32:32 Sebastian Haase wrote:
>> are you sure it makes even sense to save a 16-bit RGB image ? This is
>> not meant as an excuse for PIL to not support it,
>> but 16mio colors should likely be enough for any application (i.e.
>> 8bit per R,G and B)
>
> It does make sense. Absolutely! Maybe not if you are *just* thinking in terms
> of final output for an end user, but during the whole
> capturing/processing/manipulation phase one can reduce many artifacts
> introduced through rounding, etc. Also when images are touched up by changing
> lightness or contrast images tend to expose "banding" quite severely.
>
> This and other effects are also the background behind the increasing
> popularity of HDR (High Dynamic Range) imaging. Particularly in scientific
> imaging subtle differences are much preserved this way. And it looked like
> Dan's image is the result of a microscopic picture, or something like that,
> with low contrast. So it could strongly benefit from a change in lightness and
> contrast.
>
> Higher channel bit depth are important for these cases, and even more to keep
> up with needed capabilities for the future!
>
> Guy

I was talking only about the information content captured by
physically collecting photons from a film with very short exposure
times. That is, the "capturing" phase; for what you call the
"processing/manipulation" phase I would always convert to
single-precision float (numpy.float) if that fits into memory. This
way you are save if values get negative or intermittently very small,
for example.
I'm just a bit confused here, because I am used to collecting gray
scale images, not RGB images, (from a cooled CCD on a microscope).
Those I also save as unsigned 16 bit integers.
BTW, the original example image looked also pretty "gray" to me, could
you tell the scanner to use 16-bit gray, maybe then the (physical)
scanning quality might even be better - don't know, just wild guess...

Sebastian
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Dan Blacker
Hey guys,

Thanks for your input,

The image is only of a tiny cropped area of a long strip of color kodachrome film - I will send a better example with some more color in it when I get a chance.

I was under the impression that PIL handled 16 bit images (experimentally) but does this only apply to 16-bit grayscale images?

Am I going up a dead end trying to read my images with PIL?





On 13 April 2010 08:09, Sebastian Haase <[hidden email]> wrote:
On Tue, Apr 13, 2010 at 2:16 AM, Guy K. Kloss <[hidden email]> wrote:
> On Mon, 12 Apr 2010 23:32:32 Sebastian Haase wrote:
>> are you sure it makes even sense to save a 16-bit RGB image ? This is
>> not meant as an excuse for PIL to not support it,
>> but 16mio colors should likely be enough for any application (i.e.
>> 8bit per R,G and B)
>
> It does make sense. Absolutely! Maybe not if you are *just* thinking in terms
> of final output for an end user, but during the whole
> capturing/processing/manipulation phase one can reduce many artifacts
> introduced through rounding, etc. Also when images are touched up by changing
> lightness or contrast images tend to expose "banding" quite severely.
>
> This and other effects are also the background behind the increasing
> popularity of HDR (High Dynamic Range) imaging. Particularly in scientific
> imaging subtle differences are much preserved this way. And it looked like
> Dan's image is the result of a microscopic picture, or something like that,
> with low contrast. So it could strongly benefit from a change in lightness and
> contrast.
>
> Higher channel bit depth are important for these cases, and even more to keep
> up with needed capabilities for the future!
>
> Guy

I was talking only about the information content captured by
physically collecting photons from a film with very short exposure
times. That is, the "capturing" phase; for what you call the
"processing/manipulation" phase I would always convert to
single-precision float (numpy.float) if that fits into memory. This
way you are save if values get negative or intermittently very small,
for example.
I'm just a bit confused here, because I am used to collecting gray
scale images, not RGB images, (from a cooled CCD on a microscope).
Those I also save as unsigned 16 bit integers.
BTW, the original example image looked also pretty "gray" to me, could
you tell the scanner to use 16-bit gray, maybe then the (physical)
scanning quality might even be better - don't know, just wild guess...

Sebastian
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig


_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Sebastian Haase-3
On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
<[hidden email]> wrote:

> Hey guys,
>
> Thanks for your input,
>
> The image is only of a tiny cropped area of a long strip of color kodachrome
> film - I will send a better example with some more color in it when I get a
> chance.
>
> I was under the impression that PIL handled 16 bit images (experimentally)
> but does this only apply to 16-bit grayscale images?
>
> Am I going up a dead end trying to read my images with PIL?
>
Dan,
read my first reply: if someone could figure out how to add the
"correct" key line,
it might be an easy fix.
Otherwise I would try to use imagemagick (or alike) to separate RGB
into 3 separate gray images.
I am working with 16-bit gray TIFs in PIL for many years without
problem. (only to go immediately to numpy arrays then though; I can't
say anything about PIL's other functions, like cropping...)

- Sebastian
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Edward Cannon
PIL handles 8x3 bit images with mode RGB. higher bit depth images are
grayscale only. I have gotten around this particular problem by
storing bands separately in tupples as (R, G, B). I did have to write
my own file decoder to handle this though.
Edward

On Tue, Apr 13, 2010 at 2:21 AM, Sebastian Haase <[hidden email]> wrote:

> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
> <[hidden email]> wrote:
>> Hey guys,
>>
>> Thanks for your input,
>>
>> The image is only of a tiny cropped area of a long strip of color kodachrome
>> film - I will send a better example with some more color in it when I get a
>> chance.
>>
>> I was under the impression that PIL handled 16 bit images (experimentally)
>> but does this only apply to 16-bit grayscale images?
>>
>> Am I going up a dead end trying to read my images with PIL?
>>
> Dan,
> read my first reply: if someone could figure out how to add the
> "correct" key line,
> it might be an easy fix.
> Otherwise I would try to use imagemagick (or alike) to separate RGB
> into 3 separate gray images.
> I am working with 16-bit gray TIFs in PIL for many years without
> problem. (only to go immediately to numpy arrays then though; I can't
> say anything about PIL's other functions, like cropping...)
>
> - Sebastian
> _______________________________________________
> Image-SIG maillist  -  [hidden email]
> http://mail.python.org/mailman/listinfo/image-sig
>
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

jcupitt
In reply to this post by Dan Blacker
On 12 April 2010 13:48, Dan Blacker <[hidden email]> wrote:
> It is the CCD in this that is capturing the information:
>
> http://www.epson.com/cgi-bin/Store/consumer/consDetail.jsp?oid=63056499
>
> Are you saying that scanning at 48bit is pointless? Surley to advertise that
> feature on the scanner it must yeild more color information than at 24bit.

My background: I used to design and build high-end (>$20,000) cameras
and scanners. I did the software. It's 5 years now since I worked in
the area, but I don't think it's changed that much.

You could almost certainly use 8-bit images from the scanner with no
loss of colour detail or resolution. It's quite easy to see how many
bits you need: scan a very gentle gradient at a high resolution, look
through your image bitplane by bitplane, see how far down the 16 bits
you have to go before all the structure vanishes in a sea of noise.

I had a look at the sample image you posted earlier, and from a quick
look I'd say the bottom 7 bits of your image is just noise, so you
have about 9 bits of real data. You can easily represent 9 bits of
typical CCD data in an 8-bit byte if you use a gamma function.

People like 16-bit source data (and manufactures oblige) for two main reasons:

*) You can use linear encoding in 16-bit pixels without losing
precision, 8-bit pixels need a companding curve (eg. a gamma) of some
sort. Linear encoding can make downstream processing simpler.

*) The extra bits, although they contain no signal, are great for
avoiding rounding and banding in subsequent processing.

But for archiving, there's no point keeping them. You can just throw
the bottom 8 bits away and recreate them when you load the image.

Anyway, I'm getting off-topic, ahem. As Sebastian says, a quick
workaround would be to use imagemagick or equivalent to convert to
three 16-bit mono images and then load.

John
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Fredrik Lundh
In reply to this post by Dan Blacker
On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
<[hidden email]> wrote:

> Hey guys,
>
> Thanks for your input,
>
> The image is only of a tiny cropped area of a long strip of color kodachrome
> film - I will send a better example with some more color in it when I get a
> chance.
>
> I was under the impression that PIL handled 16 bit images (experimentally)
> but does this only apply to 16-bit grayscale images?
>
> Am I going up a dead end trying to read my images with PIL?

The current PIL release only supports 8 and 32-bit/pixel internal
storage; that's enough to hold e.g. RGB triplets or 32-bit signed
integers, but not 3x16 bit pixels.  I'd love to support more storage
formats (machines are a lot bigger now than when the internal,
intentionally very simple storage model was designed) including HDR
formats (float16 etc), but rearchitecting the internals without
breaking all existing code is a pretty big project...

There is some limited support for 16-bit storage, by packing two
pixels per 32-bit storage unit, but not all operations support this
(it's mainly intended to support working with huge, memory mapped
single-layer images, such as satellite data).

There are some non-standard tricks that may help you with your
specific case, though.  All codecs do things in two steps; the first
is to identify the file format and build a descriptor of where the
image data is in the file (the "tile" map).  The second step then
loads pixel data on demand, using that descriptor.  You might be able
to tweak the descriptor before loading the image, to load one layer at
a time.  Do you have any samples?

</F>
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Fredrik Lundh
Oh, missed that there was one in your first post.  I'm a bit busy
right now, but I'll take a look when I find some spare time.

</F>

On Thu, Apr 22, 2010 at 10:56 PM, Fredrik Lundh <[hidden email]> wrote:

> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
> <[hidden email]> wrote:
>> Hey guys,
>>
>> Thanks for your input,
>>
>> The image is only of a tiny cropped area of a long strip of color kodachrome
>> film - I will send a better example with some more color in it when I get a
>> chance.
>>
>> I was under the impression that PIL handled 16 bit images (experimentally)
>> but does this only apply to 16-bit grayscale images?
>>
>> Am I going up a dead end trying to read my images with PIL?
>
> The current PIL release only supports 8 and 32-bit/pixel internal
> storage; that's enough to hold e.g. RGB triplets or 32-bit signed
> integers, but not 3x16 bit pixels.  I'd love to support more storage
> formats (machines are a lot bigger now than when the internal,
> intentionally very simple storage model was designed) including HDR
> formats (float16 etc), but rearchitecting the internals without
> breaking all existing code is a pretty big project...
>
> There is some limited support for 16-bit storage, by packing two
> pixels per 32-bit storage unit, but not all operations support this
> (it's mainly intended to support working with huge, memory mapped
> single-layer images, such as satellite data).
>
> There are some non-standard tricks that may help you with your
> specific case, though.  All codecs do things in two steps; the first
> is to identify the file format and build a descriptor of where the
> image data is in the file (the "tile" map).  The second step then
> loads pixel data on demand, using that descriptor.  You might be able
> to tweak the descriptor before loading the image, to load one layer at
> a time.  Do you have any samples?
>
> </F>
>
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Fredrik Lundh
This isn't really a full solution, but the following patch at least
allows PIL to read 3x16-bit RGB TIFF files, converting them on the fly
to 24-bit RGB.  Note that it requires new binaries to handle little
endian (intel) files:

http://hg.effbot.org/pil-2009-raclette/changeset/45c2debe0fc3

Unfortunately, your sample use "contiguous" pixel storage, which makes
the descriptor manipulation tricks I mentioned harder to implement
efficiently for PIL 1.1.7.  I played a bit with libtiff's tiffcp
utility to see if that could be used as a preprocessor (which is
otherwise a great way to handle more "obscure" TIFF flavours), but at
least the version I have doesn't handle 16-bit images well either.  I
need to think a bit more about this, I think...

</F>

On Thu, Apr 22, 2010 at 10:57 PM, Fredrik Lundh <[hidden email]> wrote:

> Oh, missed that there was one in your first post.  I'm a bit busy
> right now, but I'll take a look when I find some spare time.
>
> </F>
>
> On Thu, Apr 22, 2010 at 10:56 PM, Fredrik Lundh <[hidden email]> wrote:
>> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
>> <[hidden email]> wrote:
>>> Hey guys,
>>>
>>> Thanks for your input,
>>>
>>> The image is only of a tiny cropped area of a long strip of color kodachrome
>>> film - I will send a better example with some more color in it when I get a
>>> chance.
>>>
>>> I was under the impression that PIL handled 16 bit images (experimentally)
>>> but does this only apply to 16-bit grayscale images?
>>>
>>> Am I going up a dead end trying to read my images with PIL?
>>
>> The current PIL release only supports 8 and 32-bit/pixel internal
>> storage; that's enough to hold e.g. RGB triplets or 32-bit signed
>> integers, but not 3x16 bit pixels.  I'd love to support more storage
>> formats (machines are a lot bigger now than when the internal,
>> intentionally very simple storage model was designed) including HDR
>> formats (float16 etc), but rearchitecting the internals without
>> breaking all existing code is a pretty big project...
>>
>> There is some limited support for 16-bit storage, by packing two
>> pixels per 32-bit storage unit, but not all operations support this
>> (it's mainly intended to support working with huge, memory mapped
>> single-layer images, such as satellite data).
>>
>> There are some non-standard tricks that may help you with your
>> specific case, though.  All codecs do things in two steps; the first
>> is to identify the file format and build a descriptor of where the
>> image data is in the file (the "tile" map).  The second step then
>> loads pixel data on demand, using that descriptor.  You might be able
>> to tweak the descriptor before loading the image, to load one layer at
>> a time.  Do you have any samples?
>>
>> </F>
>>
>
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Fredrik Lundh
Oops, that patch was broken, due to pilot error.  Here's an incremental fix:

http://hg.effbot.org/pil-2009-raclette/changeset/c3fb89aa181e

Alternatively, just grab the latest PIL/TiffImagePlugin.py and
libImaging/Unpack.c and drop them on top of the existing versions.

</F>

On Sun, Apr 25, 2010 at 1:07 PM, Fredrik Lundh <[hidden email]> wrote:

> This isn't really a full solution, but the following patch at least
> allows PIL to read 3x16-bit RGB TIFF files, converting them on the fly
> to 24-bit RGB.  Note that it requires new binaries to handle little
> endian (intel) files:
>
> http://hg.effbot.org/pil-2009-raclette/changeset/45c2debe0fc3
>
> Unfortunately, your sample use "contiguous" pixel storage, which makes
> the descriptor manipulation tricks I mentioned harder to implement
> efficiently for PIL 1.1.7.  I played a bit with libtiff's tiffcp
> utility to see if that could be used as a preprocessor (which is
> otherwise a great way to handle more "obscure" TIFF flavours), but at
> least the version I have doesn't handle 16-bit images well either.  I
> need to think a bit more about this, I think...
>
> </F>
>
> On Thu, Apr 22, 2010 at 10:57 PM, Fredrik Lundh <[hidden email]> wrote:
>> Oh, missed that there was one in your first post.  I'm a bit busy
>> right now, but I'll take a look when I find some spare time.
>>
>> </F>
>>
>> On Thu, Apr 22, 2010 at 10:56 PM, Fredrik Lundh <[hidden email]> wrote:
>>> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
>>> <[hidden email]> wrote:
>>>> Hey guys,
>>>>
>>>> Thanks for your input,
>>>>
>>>> The image is only of a tiny cropped area of a long strip of color kodachrome
>>>> film - I will send a better example with some more color in it when I get a
>>>> chance.
>>>>
>>>> I was under the impression that PIL handled 16 bit images (experimentally)
>>>> but does this only apply to 16-bit grayscale images?
>>>>
>>>> Am I going up a dead end trying to read my images with PIL?
>>>
>>> The current PIL release only supports 8 and 32-bit/pixel internal
>>> storage; that's enough to hold e.g. RGB triplets or 32-bit signed
>>> integers, but not 3x16 bit pixels.  I'd love to support more storage
>>> formats (machines are a lot bigger now than when the internal,
>>> intentionally very simple storage model was designed) including HDR
>>> formats (float16 etc), but rearchitecting the internals without
>>> breaking all existing code is a pretty big project...
>>>
>>> There is some limited support for 16-bit storage, by packing two
>>> pixels per 32-bit storage unit, but not all operations support this
>>> (it's mainly intended to support working with huge, memory mapped
>>> single-layer images, such as satellite data).
>>>
>>> There are some non-standard tricks that may help you with your
>>> specific case, though.  All codecs do things in two steps; the first
>>> is to identify the file format and build a descriptor of where the
>>> image data is in the file (the "tile" map).  The second step then
>>> loads pixel data on demand, using that descriptor.  You might be able
>>> to tweak the descriptor before loading the image, to load one layer at
>>> a time.  Do you have any samples?
>>>
>>> </F>
>>>
>>
>
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Dan Blacker
Hi Fredrik,

Thanks for taking a look at this, I have downloaded the latest PIL source and installed it, and replaced the TiffImagePlugin.py that was in pyShared with the latest one.

When running my script, I no longer get errors when reading my 16-bit tiff file in.

I do however now get an error when I try and convert and make a grayscale copy of my file, in the middle of my script. (this should be 8bit):

  File "16bittest.py", line 147, in <module>
    im1 = im0.convert ("L", dither=Image.NONE)
  File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 654, in convert
    self.load()
  File "/usr/lib/python2.6/dist-packages/PIL/ImageFile.py", line 180, in load
    d = Image._getdecoder(self.mode, d, a, self.decoderconfig)
  File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 374, in _getdecoder
    return apply(decoder, (mode,) + args + extra)
ValueError: unknown raw mode


Am I missing a value to pass into convert() to tell it to make an 8bit file?

Thanks,


On 25 April 2010 13:48, Fredrik Lundh <[hidden email]> wrote:
Oops, that patch was broken, due to pilot error.  Here's an incremental fix:

http://hg.effbot.org/pil-2009-raclette/changeset/c3fb89aa181e

Alternatively, just grab the latest PIL/TiffImagePlugin.py and
libImaging/Unpack.c and drop them on top of the existing versions.

</F>

On Sun, Apr 25, 2010 at 1:07 PM, Fredrik Lundh <[hidden email]> wrote:
> This isn't really a full solution, but the following patch at least
> allows PIL to read 3x16-bit RGB TIFF files, converting them on the fly
> to 24-bit RGB.  Note that it requires new binaries to handle little
> endian (intel) files:
>
> http://hg.effbot.org/pil-2009-raclette/changeset/45c2debe0fc3
>
> Unfortunately, your sample use "contiguous" pixel storage, which makes
> the descriptor manipulation tricks I mentioned harder to implement
> efficiently for PIL 1.1.7.  I played a bit with libtiff's tiffcp
> utility to see if that could be used as a preprocessor (which is
> otherwise a great way to handle more "obscure" TIFF flavours), but at
> least the version I have doesn't handle 16-bit images well either.  I
> need to think a bit more about this, I think...
>
> </F>
>
> On Thu, Apr 22, 2010 at 10:57 PM, Fredrik Lundh <[hidden email]> wrote:
>> Oh, missed that there was one in your first post.  I'm a bit busy
>> right now, but I'll take a look when I find some spare time.
>>
>> </F>
>>
>> On Thu, Apr 22, 2010 at 10:56 PM, Fredrik Lundh <[hidden email]> wrote:
>>> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
>>> <[hidden email]> wrote:
>>>> Hey guys,
>>>>
>>>> Thanks for your input,
>>>>
>>>> The image is only of a tiny cropped area of a long strip of color kodachrome
>>>> film - I will send a better example with some more color in it when I get a
>>>> chance.
>>>>
>>>> I was under the impression that PIL handled 16 bit images (experimentally)
>>>> but does this only apply to 16-bit grayscale images?
>>>>
>>>> Am I going up a dead end trying to read my images with PIL?
>>>
>>> The current PIL release only supports 8 and 32-bit/pixel internal
>>> storage; that's enough to hold e.g. RGB triplets or 32-bit signed
>>> integers, but not 3x16 bit pixels.  I'd love to support more storage
>>> formats (machines are a lot bigger now than when the internal,
>>> intentionally very simple storage model was designed) including HDR
>>> formats (float16 etc), but rearchitecting the internals without
>>> breaking all existing code is a pretty big project...
>>>
>>> There is some limited support for 16-bit storage, by packing two
>>> pixels per 32-bit storage unit, but not all operations support this
>>> (it's mainly intended to support working with huge, memory mapped
>>> single-layer images, such as satellite data).
>>>
>>> There are some non-standard tricks that may help you with your
>>> specific case, though.  All codecs do things in two steps; the first
>>> is to identify the file format and build a descriptor of where the
>>> image data is in the file (the "tile" map).  The second step then
>>> loads pixel data on demand, using that descriptor.  You might be able
>>> to tweak the descriptor before loading the image, to load one layer at
>>> a time.  Do you have any samples?
>>>
>>> </F>
>>>
>>
>


_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: python PIL 16-bit tiff files

Fredrik Lundh
I'm afraid you need to rebuild the _imaging module; the patch touches libImaging/Unpack.c too (without that, you can only read big-endian 48-bit RGB files; that is, files that start with MM instead of II).

</F>

On Sun, Apr 25, 2010 at 5:53 PM, Dan Blacker <[hidden email]> wrote:
Hi Fredrik,

Thanks for taking a look at this, I have downloaded the latest PIL source and installed it, and replaced the TiffImagePlugin.py that was in pyShared with the latest one.

When running my script, I no longer get errors when reading my 16-bit tiff file in.

I do however now get an error when I try and convert and make a grayscale copy of my file, in the middle of my script. (this should be 8bit):

  File "16bittest.py", line 147, in <module>
    im1 = im0.convert ("L", dither=Image.NONE)
  File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 654, in convert
    self.load()
  File "/usr/lib/python2.6/dist-packages/PIL/ImageFile.py", line 180, in load
    d = Image._getdecoder(self.mode, d, a, self.decoderconfig)
  File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 374, in _getdecoder
    return apply(decoder, (mode,) + args + extra)
ValueError: unknown raw mode


Am I missing a value to pass into convert() to tell it to make an 8bit file?

Thanks,



On 25 April 2010 13:48, Fredrik Lundh <[hidden email]> wrote:
Oops, that patch was broken, due to pilot error.  Here's an incremental fix:

http://hg.effbot.org/pil-2009-raclette/changeset/c3fb89aa181e

Alternatively, just grab the latest PIL/TiffImagePlugin.py and
libImaging/Unpack.c and drop them on top of the existing versions.

</F>

On Sun, Apr 25, 2010 at 1:07 PM, Fredrik Lundh <[hidden email]> wrote:
> This isn't really a full solution, but the following patch at least
> allows PIL to read 3x16-bit RGB TIFF files, converting them on the fly
> to 24-bit RGB.  Note that it requires new binaries to handle little
> endian (intel) files:
>
> http://hg.effbot.org/pil-2009-raclette/changeset/45c2debe0fc3
>
> Unfortunately, your sample use "contiguous" pixel storage, which makes
> the descriptor manipulation tricks I mentioned harder to implement
> efficiently for PIL 1.1.7.  I played a bit with libtiff's tiffcp
> utility to see if that could be used as a preprocessor (which is
> otherwise a great way to handle more "obscure" TIFF flavours), but at
> least the version I have doesn't handle 16-bit images well either.  I
> need to think a bit more about this, I think...
>
> </F>
>
> On Thu, Apr 22, 2010 at 10:57 PM, Fredrik Lundh <[hidden email]> wrote:
>> Oh, missed that there was one in your first post.  I'm a bit busy
>> right now, but I'll take a look when I find some spare time.
>>
>> </F>
>>
>> On Thu, Apr 22, 2010 at 10:56 PM, Fredrik Lundh <[hidden email]> wrote:
>>> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
>>> <[hidden email]> wrote:
>>>> Hey guys,
>>>>
>>>> Thanks for your input,
>>>>
>>>> The image is only of a tiny cropped area of a long strip of color kodachrome
>>>> film - I will send a better example with some more color in it when I get a
>>>> chance.
>>>>
>>>> I was under the impression that PIL handled 16 bit images (experimentally)
>>>> but does this only apply to 16-bit grayscale images?
>>>>
>>>> Am I going up a dead end trying to read my images with PIL?
>>>
>>> The current PIL release only supports 8 and 32-bit/pixel internal
>>> storage; that's enough to hold e.g. RGB triplets or 32-bit signed
>>> integers, but not 3x16 bit pixels.  I'd love to support more storage
>>> formats (machines are a lot bigger now than when the internal,
>>> intentionally very simple storage model was designed) including HDR
>>> formats (float16 etc), but rearchitecting the internals without
>>> breaking all existing code is a pretty big project...
>>>
>>> There is some limited support for 16-bit storage, by packing two
>>> pixels per 32-bit storage unit, but not all operations support this
>>> (it's mainly intended to support working with huge, memory mapped
>>> single-layer images, such as satellite data).
>>>
>>> There are some non-standard tricks that may help you with your
>>> specific case, though.  All codecs do things in two steps; the first
>>> is to identify the file format and build a descriptor of where the
>>> image data is in the file (the "tile" map).  The second step then
>>> loads pixel data on demand, using that descriptor.  You might be able
>>> to tweak the descriptor before loading the image, to load one layer at
>>> a time.  Do you have any samples?
>>>
>>> </F>
>>>
>>
>



_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
12