From hastings at indiana.edu  Thu Apr  1 01:17:17 2010
From: hastings at indiana.edu (Scott Hastings)
Date: Wed, 31 Mar 2010 19:17:17 -0400
Subject: [Image-SIG] _grabscreen???
Message-ID: <2E997DB9-B889-4691-B2A7-3E1782966766@indiana.edu>

Hi,

I'm having a difficult time using the python imaging library on my  
mac.  Being naive, I installed a universal binary that someone  
compiled from  "http://pythonmac.org/packages/py25-fat/index.html".   
This is after trying for a few hours to install from the source code;  
however, couldn't get it to run without a laundry list of errors.

With the binary version, I have been successful running most modules;  
however, cannot an essential function for my module to work, the  
ImageGrab().  When running, it reports an error: ImportError: No  
module named _grabscreen

How do I fix this? or Work around?

I'm not adverse to reinstalling from the sourcecode, re-formating my  
mac, or buying a cheap PC!  It's important that I can do a screen  
capture with python.

Thanks for the help!

Cheers,
Scott

From fredrik at pythonware.com  Thu Apr  1 18:12:07 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 1 Apr 2010 18:12:07 +0200
Subject: [Image-SIG] _grabscreen???
In-Reply-To: <2E997DB9-B889-4691-B2A7-3E1782966766@indiana.edu>
References: <2E997DB9-B889-4691-B2A7-3E1782966766@indiana.edu>
Message-ID: <x2p368a5cd51004010912m15e99608w34193f1e17b5eb7c@mail.gmail.com>

I'm afraid ImageGrab isn't available for Mac OS X; it's Windows only in 1.1.7.

(Contributions from mac hackers are welcome!)

</F>

On Thu, Apr 1, 2010 at 1:17 AM, Scott Hastings <hastings at indiana.edu> wrote:
> Hi,
>
> I'm having a difficult time using the python imaging library on my mac.
> ?Being naive, I installed a universal binary that someone compiled from
> ?"http://pythonmac.org/packages/py25-fat/index.html". ?This is after trying
> for a few hours to install from the source code; however, couldn't get it to
> run without a laundry list of errors.
>
> With the binary version, I have been successful running most modules;
> however, cannot an essential function for my module to work, the
> ImageGrab(). ?When running, it reports an error: ImportError: No module
> named _grabscreen
>
> How do I fix this? or Work around?
>
> I'm not adverse to reinstalling from the sourcecode, re-formating my mac, or
> buying a cheap PC! ?It's important that I can do a screen capture with
> python.
>
> Thanks for the help!
>
> Cheers,
> Scott
> _______________________________________________
> Image-SIG maillist ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>

From janssen at parc.com  Thu Apr  1 18:30:03 2010
From: janssen at parc.com (Bill Janssen)
Date: Thu, 1 Apr 2010 09:30:03 PDT
Subject: [Image-SIG] _grabscreen???
In-Reply-To: <2E997DB9-B889-4691-B2A7-3E1782966766@indiana.edu>
References: <2E997DB9-B889-4691-B2A7-3E1782966766@indiana.edu>
Message-ID: <54638.1270139403@parc.com>

http://livingcode.org/2006/03/10/screencast-in-cocoa-python.html


From agagne at genome.med.harvard.edu  Thu Apr  1 19:28:11 2010
From: agagne at genome.med.harvard.edu (andrew)
Date: Thu, 1 Apr 2010 17:28:11 +0000 (UTC)
Subject: [Image-SIG] 16-bit TIFF decoding and endianness problem
References: <D3F3B0BA-2944-11D8-80AE-000A956861F6@stanford.edu>
Message-ID: <loom.20100401T192606-712@post.gmane.org>

Zachary Pincus <zpincus <at> stanford.edu> writes:

> 
> I've encountered an issue in PIL-1.1.4 having to do with decoding 
> 16-bit TIFFs.
> 
> Specifically, it appears that the TIFF decoder does not properly 
> process the byte ordering of 16-bit integers in TIFF files. The decoder 
> can detect big-endian files, but then decodes them in a little-endian 
> manner.
> 


>
Did you ever get this working? 
I'm having a similar problem with the tif files im 
looking at.


From seb.haase at gmail.com  Sat Apr  3 17:50:40 2010
From: seb.haase at gmail.com (Sebastian Haase)
Date: Sat, 3 Apr 2010 17:50:40 +0200
Subject: [Image-SIG] 16-bit TIFF decoding and endianness problem
In-Reply-To: <loom.20100401T192606-712@post.gmane.org>
References: <D3F3B0BA-2944-11D8-80AE-000A956861F6@stanford.edu> 
	<loom.20100401T192606-712@post.gmane.org>
Message-ID: <k2tbc657ead1004030850qa87963a1q8c848408db2ec6e7@mail.gmail.com>

Hi,

1.1.4 is a really old version - 1.1.6 plus some patches  OR the "new"
1.1.7 should have this working , please try it ....

Regards,
Sebastian


On Thu, Apr 1, 2010 at 7:28 PM, andrew <agagne at genome.med.harvard.edu> wrote:
> Zachary Pincus <zpincus <at> stanford.edu> writes:
>
>>
>> I've encountered an issue in PIL-1.1.4 having to do with decoding
>> 16-bit TIFFs.
>>
>> Specifically, it appears that the TIFF decoder does not properly
>> process the byte ordering of 16-bit integers in TIFF files. The decoder
>> can detect big-endian files, but then decodes them in a little-endian
>> manner.
>>
>
>
>>
> Did you ever get this working?
> I'm having a similar problem with the tif files im
> looking at.
>
> _______________________________________________
> Image-SIG maillist ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>

From janssen at parc.com  Sat Apr  3 19:52:53 2010
From: janssen at parc.com (Bill Janssen)
Date: Sat, 3 Apr 2010 10:52:53 PDT
Subject: [Image-SIG] patch for 1.1.7 to support automated builds and msys
Message-ID: <87816.1270317173@parc.com>

I've been building an automated build framework for my UpLib system,
which requires PIL.  I've made a couple of changes to the PIL setup.py
which might go into the standard release, and attach a patch.

Basically two changes:

1.  It's useful to be able to set TIFF_ROOT, JPEG_ROOT, etc. without
editing the setup.py file.  This patch modifies the default values for
those setup variables to be read from the environment, as PIL_TIFF_ROOT,
PIL_JPEG_ROOT, etc.  This allows a build script to just set the
environment variables to pass them in to setup.py.

2.  When linking _imagingft on msys, the auxiliary libraries (-ljpeg,
-lz, etc.) need to be passed as arguments to the link command.  So I've
modified the link code

        if feature.freetype:
            defs = []
            if feature.freetype_version == 20:
                defs.append(("USE_FREETYPE_2_0", None))
            exts.append(Extension(
                "_imagingft", ["_imagingft.c"], libraries=["freetype"],
                define_macros=defs
                ))

to read instead

        if feature.freetype:
            defs = []
            if feature.freetype_version == 20:
                defs.append(("USE_FREETYPE_2_0", None))
            exts.append(Extension(
                "_imagingft", ["_imagingft.c"], libraries=["freetype"] + libs,
                define_macros=defs
                ))

adding back in the necessary libraries.  Similarly for _imagingtiff and
_imagingcms.

Should this perhaps be done only for msys, via an "extra" parameter,
such as that used with _imagingcms?  Be happy to change it, but it seems
to work fine on OS X and Ubuntu, too, as is.

Bill

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PIL-1.1.7-msys-PATCH
Type: text/x-python
Size: 3191 bytes
Desc: patch for PIL configuration and msys build
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100403/727866e9/attachment.py>

From janssen at parc.com  Mon Apr  5 04:41:41 2010
From: janssen at parc.com (Bill Janssen)
Date: Sun, 4 Apr 2010 19:41:41 PDT
Subject: [Image-SIG] AccessInit: hash collision: 3 for both 1 and 1
In-Reply-To: <k2tbc657ead1004030850qa87963a1q8c848408db2ec6e7@mail.gmail.com>
References: <D3F3B0BA-2944-11D8-80AE-000A956861F6@stanford.edu>
	<loom.20100401T192606-712@post.gmane.org>
	<k2tbc657ead1004030850qa87963a1q8c848408db2ec6e7@mail.gmail.com>
Message-ID: <7993.1270435301@parc.com>

Seems to me that in libImaging, Access.c:add_item should really read

static ImagingAccess
add_item(const char* mode)
{
    UINT32 i = hash(mode);
    /* printf("hash %s => %d\n", mode, i); */
    if (access_table[i].mode && (strcmp(mode, access_table[i].mode) != 0)) {
        fprintf(stderr, "AccessInit: hash collision: %d for both %s and %s\n",
                i, mode, access_table[i].mode);
        exit(1);
    }
    access_table[i].mode = mode;
    return &access_table[i];
}

Currently, it reads:

static ImagingAccess
add_item(const char* mode)
{
    UINT32 i = hash(mode);
    /* printf("hash %s => %d\n", mode, i); */
    if (access_table[i].mode) {
        fprintf(stderr, "AccessInit: hash collision: %d for both %s and %s\n",
                i, mode, access_table[i].mode);
        exit(1);
    }
    access_table[i].mode = mode;
    return &access_table[i];
}

And there's a number of Google hits for "AccessInit: hash collision: 3
for both 1 and 1", starting about the release of 1.1.7.

Bill

From bdfy at mail.ru  Tue Apr  6 11:37:50 2010
From: bdfy at mail.ru (Ivan)
Date: Tue, 06 Apr 2010 13:37:50 +0400
Subject: [Image-SIG] reading image from database
Message-ID: <E1Nz5EE-0003J0-00.bdfy-mail-ru@f233.mail.ru>

I want to use PIL library for crop image on the fly. In my python script:

cursor = connection.cursor()
cursor.execute("SELECT file from table");
row = cursor.fetchone();
filetype = imghdr.what(0,row[0]);
mimetype = 'image/' + filetype;
response = HttpResponse(row[0],mimetype = mimetype );

How to correct use PIL library for read image to Image object and return image after crop ?


From nils.de.reus at ivm.vu.nl  Tue Apr  6 15:10:49 2010
From: nils.de.reus at ivm.vu.nl (Nils de Reus)
Date: Tue, 6 Apr 2010 15:10:49 +0200
Subject: [Image-SIG] reading image from database
In-Reply-To: <E1Nz5EE-0003J0-00.bdfy-mail-ru@f233.mail.ru>
References: <E1Nz5EE-0003J0-00.bdfy-mail-ru@f233.mail.ru>
Message-ID: <57AE160B221E6F4EA096548C7DEE199B6802B6C3@ivm-mail>

When I am getting a binary stored image from a database or as output from another process and I need to dynamically feed it into PIL, I usually resort to StringIO. The charm there is that I can simply use Image.open() and leave the hassle of figuring out the image header to PIL.

import StringIO
import Image

...

cursor = connection.cursor()
cursor.execute("SELECT file from table")
row = cursor.fetchone()

img_stringio_in = StringIO.StringIO( row[0] )

img_full = Image.open( img_stringio_in )

# You did not specify how you wanted to crop, so I leave defining the box parameter as an exercise to your imagination - but for the example I'll crop to the top-left 100x100 area.

box = ( 0 , 0 , 100 , 100 )

img_cropped = img_full.crop( box )

Now you have a cropped image, and if I understand well, you want to write it back somehow into your database? Several different ways you could proceed now.. you could either dump a raw string with the toString function, or create another StringIO object and specify that as the file to save into using save() or one of the other means of saving the image, and dump that thing back into your database. Remember that if using the StringIO trick, you need to seek() back to the start after saving into it, like this:

img_stringio_out = StringIO.StringIO()
img_cropped.save( img_stringio_out, format="png" )
img_stringio_out.seek( 0 )

Otherwise, a later img_stringio_out.read() would return nothing, since the internal cursor would already be at EOF after the save()

Kind regards,
Nils


> 
> I want to use PIL library for crop image on the fly. In my python script:
> 
> cursor = connection.cursor()
> cursor.execute("SELECT file from table");
> row = cursor.fetchone();
> filetype = imghdr.what(0,row[0]);
> mimetype = 'image/' + filetype;
> response = HttpResponse(row[0],mimetype = mimetype );
> 
> How to correct use PIL library for read image to Image object and return image after crop ?
>
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig

From bdfy at mail.ru  Tue Apr  6 16:05:41 2010
From: bdfy at mail.ru (Ivan)
Date: Tue, 06 Apr 2010 18:05:41 +0400
Subject: [Image-SIG] =?koi8-r?b?cmVhZGluZyBpbWFnZSBmcm9tIGRhdGFiYXNl?=
In-Reply-To: <57AE160B221E6F4EA096548C7DEE199B6802B6C3@ivm-mail>
References: <57AE160B221E6F4EA096548C7DEE199B6802B6C3@ivm-mail>
Message-ID: <E1Nz9PS-00060W-00.bdfy-mail-ru@f294.mail.ru>


Tue, 6 Apr 2010 15:10:49 +0200 ?????? ?? Nils de Reus <nils.de.reus at ivm.vu.nl>:

> When I am getting a binary stored image from a database or as output from another process and I need to dynamically feed it into PIL, I usually resort to StringIO. The charm there is that I can simply use Image.open() and leave the hassle of figuring out the image header to PIL.
> 
> import StringIO
> import Image
> 
> ...
> 
> cursor = connection.cursor()
> cursor.execute("SELECT file from table")
> row = cursor.fetchone()
> 
> img_stringio_in = StringIO.StringIO( row[0] )
> 
> img_full = Image.open( img_stringio_in )
> 
> # You did not specify how you wanted to crop, so I leave defining the box parameter as an exercise to your imagination - but for the example I'll crop to the top-left 100x100 area.
> 
> box = ( 0 , 0 , 100 , 100 )
> 
> img_cropped = img_full.crop( box )
> 
> Now you have a cropped image, and if I understand well, you want to write it back somehow into your database? Several different ways you could proceed now.. you could either dump a raw string with the toString function, or create another StringIO object and specify that as the file to save into using save() or one of the other means of saving the image, and dump that thing back into your database. Remember that if using the StringIO trick, you need to seek() back to the start after saving into it, like this:
> 
> img_stringio_out = StringIO.StringIO()
> img_cropped.save( img_stringio_out, format="png" )
> img_stringio_out.seek( 0 )
> 
> Otherwise, a later img_stringio_out.read() would return nothing, since the internal cursor would already be at EOF after the save()
> 
> Kind regards,
> Nils
> 
> 
> > 
> > I want to use PIL library for crop image on the fly. In my python script:
> > 
> > cursor = connection.cursor()
> > cursor.execute("SELECT file from table");
> > row = cursor.fetchone();
> > filetype = imghdr.what(0,row[0]);
> > mimetype = 'image/' + filetype;
> > response = HttpResponse(row[0],mimetype = mimetype );
> > 
> > How to correct use PIL library for read image to Image object and return image after crop ?
> >
> > _______________________________________________
> > Image-SIG maillist  -  Image-SIG at python.org
> > http://mail.python.org/mailman/listinfo/image-sig
> 

Thanks



From fredrik at pythonware.com  Thu Apr  8 19:33:53 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 8 Apr 2010 19:33:53 +0200
Subject: [Image-SIG] AccessInit: hash collision: 3 for both 1 and 1
In-Reply-To: <7993.1270435301@parc.com>
References: <D3F3B0BA-2944-11D8-80AE-000A956861F6@stanford.edu> 
	<loom.20100401T192606-712@post.gmane.org>
	<k2tbc657ead1004030850qa87963a1q8c848408db2ec6e7@mail.gmail.com>
	<7993.1270435301@parc.com>
Message-ID: <q2j368a5cd51004081033h18bc88fcn3c9b91f2dda10bd1@mail.gmail.com>

The idea is that add_item should only be called once for each mode
(see ImagingAccessInit).  What did you do to trick Python into calling
the module initializer multiple times?

</F>

On Mon, Apr 5, 2010 at 4:41 AM, Bill Janssen <janssen at parc.com> wrote:
> Seems to me that in libImaging, Access.c:add_item should really read
>
> static ImagingAccess
> add_item(const char* mode)
> {
> ? ?UINT32 i = hash(mode);
> ? ?/* printf("hash %s => %d\n", mode, i); */
> ? ?if (access_table[i].mode && (strcmp(mode, access_table[i].mode) != 0)) {
> ? ? ? ?fprintf(stderr, "AccessInit: hash collision: %d for both %s and %s\n",
> ? ? ? ? ? ? ? ?i, mode, access_table[i].mode);
> ? ? ? ?exit(1);
> ? ?}
> ? ?access_table[i].mode = mode;
> ? ?return &access_table[i];
> }
>
> Currently, it reads:
>
> static ImagingAccess
> add_item(const char* mode)
> {
> ? ?UINT32 i = hash(mode);
> ? ?/* printf("hash %s => %d\n", mode, i); */
> ? ?if (access_table[i].mode) {
> ? ? ? ?fprintf(stderr, "AccessInit: hash collision: %d for both %s and %s\n",
> ? ? ? ? ? ? ? ?i, mode, access_table[i].mode);
> ? ? ? ?exit(1);
> ? ?}
> ? ?access_table[i].mode = mode;
> ? ?return &access_table[i];
> }
>
> And there's a number of Google hits for "AccessInit: hash collision: 3
> for both 1 and 1", starting about the release of 1.1.7.
>
> Bill
> _______________________________________________
> Image-SIG maillist ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>

From mdeas2000 at yahoo.com  Thu Apr  8 07:25:27 2010
From: mdeas2000 at yahoo.com (Mahmoud Deas)
Date: Wed, 7 Apr 2010 22:25:27 -0700 (PDT)
Subject: [Image-SIG] Trying to convert JPG image to .Sig , How?
Message-ID: <155795.67086.qm@web112107.mail.gq1.yahoo.com>

Hi

?I'm trying to convert JPG image to .Sig?format signaturie file again??.?
You have any idias or refrence please help .
?How shuld i do to get that?

S Web developer
Mahmoud Ideis

?


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100407/8131e124/attachment.html>

From fredrik at pythonware.com  Thu Apr  8 20:03:08 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 8 Apr 2010 20:03:08 +0200
Subject: [Image-SIG] Trying to convert JPG image to .Sig , How?
In-Reply-To: <155795.67086.qm@web112107.mail.gq1.yahoo.com>
References: <155795.67086.qm@web112107.mail.gq1.yahoo.com>
Message-ID: <m2t368a5cd51004081103z4b44dbe9m6b4c0a154ce5b669@mail.gmail.com>

What's a ".sig format signature"?  If you want to embed a JPEG image
in a mail, you need to read up on the MIME mail format and Python's
email package (http://docs.python.org/library/email).  Traditional
sigs are usually plain text, though, so maybe you meant something
else?

</F>

On Thu, Apr 8, 2010 at 7:25 AM, Mahmoud Deas <mdeas2000 at yahoo.com> wrote:
>
> Hi
>
> ?I'm trying to convert JPG image to .Sig?format signaturie file again??.
> You have any idias or refrence please help .
> ?How shuld i do to get that?
> S Web developer
> Mahmoud Ideis
>
>
> _______________________________________________
> Image-SIG maillist ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>

From janssen at parc.com  Thu Apr  8 20:17:32 2010
From: janssen at parc.com (Bill Janssen)
Date: Thu, 8 Apr 2010 11:17:32 PDT
Subject: [Image-SIG] AccessInit: hash collision: 3 for both 1 and 1
In-Reply-To: <q2j368a5cd51004081033h18bc88fcn3c9b91f2dda10bd1@mail.gmail.com>
References: <D3F3B0BA-2944-11D8-80AE-000A956861F6@stanford.edu>
	<loom.20100401T192606-712@post.gmane.org>
	<k2tbc657ead1004030850qa87963a1q8c848408db2ec6e7@mail.gmail.com>
	<7993.1270435301@parc.com>
	<q2j368a5cd51004081033h18bc88fcn3c9b91f2dda10bd1@mail.gmail.com>
Message-ID: <74375.1270750652@parc.com>

Fredrik Lundh <fredrik at pythonware.com> wrote:

> The idea is that add_item should only be called once for each mode
> (see ImagingAccessInit).  What did you do to trick Python into calling
> the module initializer multiple times?

I was using epydoc and docutils 0.5 to build my documentation.  Epydoc
crashed with this error.  If you google "AccessInit: hash collision: 3
for both 1 and 1", you'll see it's not just me.  After I applied my
patch, things seem to work fine.

Seems to be a problem with Django and Sphinx and Satchmo, too.  And
it looks like maybe it only occurs on Windows.  I ran into it using
PIL built with msys for Python 2.6.4 on Windows XP.  I've never seen
it on OS X or Ubuntu or Fedora.

By the way, "exit(1)" is pretty harsh.  Shouldn't you somehow throw a
Python exception there?  Give us a better chance of figuring out where
it's being called from.

Bill

> 
> </F>
> 
> On Mon, Apr 5, 2010 at 4:41 AM, Bill Janssen <janssen at parc.com> wrote:
> > Seems to me that in libImaging, Access.c:add_item should really read
> >
> > static ImagingAccess
> > add_item(const char* mode)
> > {
> > ? ?UINT32 i = hash(mode);
> > ? ?/* printf("hash %s => %d\n", mode, i); */
> > ? ?if (access_table[i].mode && (strcmp(mode, access_table[i].mode) != 0)) {
> > ? ? ? ?fprintf(stderr, "AccessInit: hash collision: %d for both %s and %s\n",
> > ? ? ? ? ? ? ? ?i, mode, access_table[i].mode);
> > ? ? ? ?exit(1);
> > ? ?}
> > ? ?access_table[i].mode = mode;
> > ? ?return &access_table[i];
> > }
> >
> > Currently, it reads:
> >
> > static ImagingAccess
> > add_item(const char* mode)
> > {
> > ? ?UINT32 i = hash(mode);
> > ? ?/* printf("hash %s => %d\n", mode, i); */
> > ? ?if (access_table[i].mode) {
> > ? ? ? ?fprintf(stderr, "AccessInit: hash collision: %d for both %s and %s\n",
> > ? ? ? ? ? ? ? ?i, mode, access_table[i].mode);
> > ? ? ? ?exit(1);
> > ? ?}
> > ? ?access_table[i].mode = mode;
> > ? ?return &access_table[i];
> > }
> >
> > And there's a number of Google hits for "AccessInit: hash collision: 3
> > for both 1 and 1", starting about the release of 1.1.7.
> >
> > Bill
> > _______________________________________________
> > Image-SIG maillist ?- ?Image-SIG at python.org
> > http://mail.python.org/mailman/listinfo/image-sig
> >

From shane.geiger at gmail.com  Thu Apr  8 20:58:06 2010
From: shane.geiger at gmail.com (Shane Geiger)
Date: Thu, 08 Apr 2010 14:58:06 -0400
Subject: [Image-SIG] Trying to convert JPG image to .Sig , How?
In-Reply-To: <m2t368a5cd51004081103z4b44dbe9m6b4c0a154ce5b669@mail.gmail.com>
References: <155795.67086.qm@web112107.mail.gq1.yahoo.com>
	<m2t368a5cd51004081103z4b44dbe9m6b4c0a154ce5b669@mail.gmail.com>
Message-ID: <4BBE273E.1050109@gmail.com>

It appears that what Mahmoud wants is to send out MIME-encoded email 
messages so that he can include an image at the bottom of the message 
(in the fashion of a signature).





Fredrik Lundh wrote:
> What's a ".sig format signature"?  If you want to embed a JPEG image
> in a mail, you need to read up on the MIME mail format and Python's
> email package (http://docs.python.org/library/email).  Traditional
> sigs are usually plain text, though, so maybe you meant something
> else?
>
> </F>
>
> On Thu, Apr 8, 2010 at 7:25 AM, Mahmoud Deas <mdeas2000 at yahoo.com> wrote:
>   
>> Hi
>>
>>  I'm trying to convert JPG image to .Sig format signaturie file again  .
>> You have any idias or refrence please help .
>>  How shuld i do to get that?
>> S Web developer
>> Mahmoud Ideis
>>
>>
>> _______________________________________________
>> Image-SIG maillist  -  Image-SIG at python.org
>> http://mail.python.org/mailman/listinfo/image-sig
>>
>>     
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>
>   


-- 
Shane Geiger
shane.geiger at gmail.com
Phone: 347-237-7108
Texting: 60611002

"Principles for the development of a complete mind:
Study the science of art.
Study the art of science.
Develop your senses--especially learn how to see.
Realize how everything connects to everything else."
  -- Leonardo DaVinci 


From fredrik at pythonware.com  Thu Apr  8 21:06:33 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 8 Apr 2010 21:06:33 +0200
Subject: [Image-SIG] AccessInit: hash collision: 3 for both 1 and 1
In-Reply-To: <74375.1270750652@parc.com>
References: <D3F3B0BA-2944-11D8-80AE-000A956861F6@stanford.edu> 
	<loom.20100401T192606-712@post.gmane.org>
	<k2tbc657ead1004030850qa87963a1q8c848408db2ec6e7@mail.gmail.com>
	<7993.1270435301@parc.com>
	<q2j368a5cd51004081033h18bc88fcn3c9b91f2dda10bd1@mail.gmail.com>
	<74375.1270750652@parc.com>
Message-ID: <i2h368a5cd51004081206n31a1bf60uecf34720e6aac2bd@mail.gmail.com>

The error should only occur if the C module's initialization function
is called twice.  That shouldn't happen under normal use of Python
(and if it happens anyway, it invariably results in resource leaks for
many modules, and potentially also more serious issues -- the C module
interface doesn't have a "uninit" mechanism).  Changing the init to
ignore double initializations only addresses the symptoms.

(the reason this is a hard error is that collision under normal
circumstances means that the library is unusable unless rebuilt with
proper hash settings).

Googling led me to someone mentioning that this happened after he'd
used easy_install, but that it went away after rebuilding with
setup.py.  How did you build your copy?

</F>

On Thu, Apr 8, 2010 at 8:17 PM, Bill Janssen <janssen at parc.com> wrote:
> Fredrik Lundh <fredrik at pythonware.com> wrote:
>
>> The idea is that add_item should only be called once for each mode
>> (see ImagingAccessInit). ?What did you do to trick Python into calling
>> the module initializer multiple times?
>
> I was using epydoc and docutils 0.5 to build my documentation. ?Epydoc
> crashed with this error. ?If you google "AccessInit: hash collision: 3
> for both 1 and 1", you'll see it's not just me. ?After I applied my
> patch, things seem to work fine.
>
> Seems to be a problem with Django and Sphinx and Satchmo, too. ?And
> it looks like maybe it only occurs on Windows. ?I ran into it using
> PIL built with msys for Python 2.6.4 on Windows XP. ?I've never seen
> it on OS X or Ubuntu or Fedora.
>
> By the way, "exit(1)" is pretty harsh. ?Shouldn't you somehow throw a
> Python exception there? ?Give us a better chance of figuring out where
> it's being called from.
>
> Bill
>
>>
>> </F>
>>
>> On Mon, Apr 5, 2010 at 4:41 AM, Bill Janssen <janssen at parc.com> wrote:
>> > Seems to me that in libImaging, Access.c:add_item should really read
>> >
>> > static ImagingAccess
>> > add_item(const char* mode)
>> > {
>> > ? ?UINT32 i = hash(mode);
>> > ? ?/* printf("hash %s => %d\n", mode, i); */
>> > ? ?if (access_table[i].mode && (strcmp(mode, access_table[i].mode) != 0)) {
>> > ? ? ? ?fprintf(stderr, "AccessInit: hash collision: %d for both %s and %s\n",
>> > ? ? ? ? ? ? ? ?i, mode, access_table[i].mode);
>> > ? ? ? ?exit(1);
>> > ? ?}
>> > ? ?access_table[i].mode = mode;
>> > ? ?return &access_table[i];
>> > }
>> >
>> > Currently, it reads:
>> >
>> > static ImagingAccess
>> > add_item(const char* mode)
>> > {
>> > ? ?UINT32 i = hash(mode);
>> > ? ?/* printf("hash %s => %d\n", mode, i); */
>> > ? ?if (access_table[i].mode) {
>> > ? ? ? ?fprintf(stderr, "AccessInit: hash collision: %d for both %s and %s\n",
>> > ? ? ? ? ? ? ? ?i, mode, access_table[i].mode);
>> > ? ? ? ?exit(1);
>> > ? ?}
>> > ? ?access_table[i].mode = mode;
>> > ? ?return &access_table[i];
>> > }
>> >
>> > And there's a number of Google hits for "AccessInit: hash collision: 3
>> > for both 1 and 1", starting about the release of 1.1.7.
>> >
>> > Bill
>> > _______________________________________________
>> > Image-SIG maillist ?- ?Image-SIG at python.org
>> > http://mail.python.org/mailman/listinfo/image-sig
>> >
>

From fredrik at pythonware.com  Thu Apr  8 22:30:03 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 8 Apr 2010 22:30:03 +0200
Subject: [Image-SIG] AccessInit: hash collision: 3 for both 1 and 1
In-Reply-To: <i2h368a5cd51004081206n31a1bf60uecf34720e6aac2bd@mail.gmail.com>
References: <D3F3B0BA-2944-11D8-80AE-000A956861F6@stanford.edu> 
	<loom.20100401T192606-712@post.gmane.org>
	<k2tbc657ead1004030850qa87963a1q8c848408db2ec6e7@mail.gmail.com>
	<7993.1270435301@parc.com>
	<q2j368a5cd51004081033h18bc88fcn3c9b91f2dda10bd1@mail.gmail.com>
	<74375.1270750652@parc.com>
	<i2h368a5cd51004081206n31a1bf60uecf34720e6aac2bd@mail.gmail.com>
Message-ID: <n2q368a5cd51004081330va4f2a3e0w2d9f700caa1f0d1d@mail.gmail.com>

Are you using some virtual env thing that might move modules around,
btw?  I tried messing with the path to see if I could trick Python
into importing the same thing twice on Windows, but failed under 2.6.

</F>

On Thu, Apr 8, 2010 at 9:06 PM, Fredrik Lundh <fredrik at pythonware.com> wrote:
> The error should only occur if the C module's initialization function
> is called twice. ?That shouldn't happen under normal use of Python
> (and if it happens anyway, it invariably results in resource leaks for
> many modules, and potentially also more serious issues -- the C module
> interface doesn't have a "uninit" mechanism). ?Changing the init to
> ignore double initializations only addresses the symptoms.
>
> (the reason this is a hard error is that collision under normal
> circumstances means that the library is unusable unless rebuilt with
> proper hash settings).
>
> Googling led me to someone mentioning that this happened after he'd
> used easy_install, but that it went away after rebuilding with
> setup.py. ?How did you build your copy?
>
> </F>
>
> On Thu, Apr 8, 2010 at 8:17 PM, Bill Janssen <janssen at parc.com> wrote:
>> Fredrik Lundh <fredrik at pythonware.com> wrote:
>>
>>> The idea is that add_item should only be called once for each mode
>>> (see ImagingAccessInit). ?What did you do to trick Python into calling
>>> the module initializer multiple times?
>>
>> I was using epydoc and docutils 0.5 to build my documentation. ?Epydoc
>> crashed with this error. ?If you google "AccessInit: hash collision: 3
>> for both 1 and 1", you'll see it's not just me. ?After I applied my
>> patch, things seem to work fine.
>>
>> Seems to be a problem with Django and Sphinx and Satchmo, too. ?And
>> it looks like maybe it only occurs on Windows. ?I ran into it using
>> PIL built with msys for Python 2.6.4 on Windows XP. ?I've never seen
>> it on OS X or Ubuntu or Fedora.
>>
>> By the way, "exit(1)" is pretty harsh. ?Shouldn't you somehow throw a
>> Python exception there? ?Give us a better chance of figuring out where
>> it's being called from.
>>
>> Bill
>>
>>>
>>> </F>
>>>
>>> On Mon, Apr 5, 2010 at 4:41 AM, Bill Janssen <janssen at parc.com> wrote:
>>> > Seems to me that in libImaging, Access.c:add_item should really read
>>> >
>>> > static ImagingAccess
>>> > add_item(const char* mode)
>>> > {
>>> > ? ?UINT32 i = hash(mode);
>>> > ? ?/* printf("hash %s => %d\n", mode, i); */
>>> > ? ?if (access_table[i].mode && (strcmp(mode, access_table[i].mode) != 0)) {
>>> > ? ? ? ?fprintf(stderr, "AccessInit: hash collision: %d for both %s and %s\n",
>>> > ? ? ? ? ? ? ? ?i, mode, access_table[i].mode);
>>> > ? ? ? ?exit(1);
>>> > ? ?}
>>> > ? ?access_table[i].mode = mode;
>>> > ? ?return &access_table[i];
>>> > }
>>> >
>>> > Currently, it reads:
>>> >
>>> > static ImagingAccess
>>> > add_item(const char* mode)
>>> > {
>>> > ? ?UINT32 i = hash(mode);
>>> > ? ?/* printf("hash %s => %d\n", mode, i); */
>>> > ? ?if (access_table[i].mode) {
>>> > ? ? ? ?fprintf(stderr, "AccessInit: hash collision: %d for both %s and %s\n",
>>> > ? ? ? ? ? ? ? ?i, mode, access_table[i].mode);
>>> > ? ? ? ?exit(1);
>>> > ? ?}
>>> > ? ?access_table[i].mode = mode;
>>> > ? ?return &access_table[i];
>>> > }
>>> >
>>> > And there's a number of Google hits for "AccessInit: hash collision: 3
>>> > for both 1 and 1", starting about the release of 1.1.7.
>>> >
>>> > Bill
>>> > _______________________________________________
>>> > Image-SIG maillist ?- ?Image-SIG at python.org
>>> > http://mail.python.org/mailman/listinfo/image-sig
>>> >
>>
>

From dan.blacker at googlemail.com  Sat Apr 10 18:08:06 2010
From: dan.blacker at googlemail.com (Dan Blacker)
Date: Sat, 10 Apr 2010 17:08:06 +0100
Subject: [Image-SIG] python PIL 16-bit tiff files
Message-ID: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100410/cdef2c34/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 16_bit_example.tif
Type: image/tiff
Size: 644728 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100410/cdef2c34/attachment-0001.tif>

From yury at shurup.com  Mon Apr 12 10:03:52 2010
From: yury at shurup.com (Yury V. Zaytsev)
Date: Mon, 12 Apr 2010 10:03:52 +0200
Subject: [Image-SIG] How to quickly read a Z-axis cut of a multipage TIFF
	images?
Message-ID: <1271059432.7049.31.camel@mypride>

Hello PIL experts,

I am writing a Python script to analyse a multipage TIFF image stacks
coming from a microscope. The average file size is around several
gigabytes with few thousand grayscale frames and the resolution is
around 640x480 or thereabouts.

For this I need to apply some temporal filtering to individual pixels
(temporal means that I need to construct a "line" from the values of
this pixel along the pages). 

Currently I am using Image.getpixel() in cycle, but it turns out that
it's prohibitively slow (much slower than the filtering that I am
applying). I estimated that on my 2 Ghz laptop it will take around 400
hours to analyse one pack (all the pixels).

Therefore I'd like to inquire whether this is an issue with PIL, or
underlying TIFF reader, or maybe there's a built-in method to quickly
read Z-axis cut that I didn't consider (I'm a total PIL n00b).

Also I was considering that maybe reading the whole page with some
built-in method, such as Image.getdata() and switching through the pages
may be faster, but I can't store the whole stack in memory (the stacks
that we have now will take around ~4 Gb, but this will quickly grow...).

Fortunately I can apply filters to a window, but this will introduce a
lot of complication in the algorithm, so I'm really looking forward to
hearing from you whether it is possible to speed up my code as is.

Many thanks!

P.S. Snippet attached:

           import numpy as np

           def getvalue(im, position):

                pixel = im.getpixel( position )

                if isinstance(pixel, int):
                    return pixel
                else:
                    return np.sqrt( np.sum( np.array(pixel) ** 2 ) )

            im_name = 'bleaching.tiff'
            im = Image.open(im_name)

            page = 0
            line = []
            try:
                while True:
                    im.seek(page)
                    line.append(getvalue(im, (x, y) ))
                    page += 1
            except EOFError:
                pass

            <do something with line and take another pixel>
 
-- 
Sincerely yours,
Yury V. Zaytsev


From seb.haase at gmail.com  Mon Apr 12 13:32:32 2010
From: seb.haase at gmail.com (Sebastian Haase)
Date: Mon, 12 Apr 2010 13:32:32 +0200
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com> 
	<y2ibc657ead1004120037ib572a302h26ec5f4ad0f3d92@mail.gmail.com> 
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com>
Message-ID: <u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com>

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
<dan.blacker at googlemail.com> 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 <seb.haase at gmail.com> 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 <dan.blacker at googlemail.com>
>> 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 ?- ?Image-SIG at python.org
>> > http://mail.python.org/mailman/listinfo/image-sig
>> >
>> >
>
>

From seb.haase at gmail.com  Mon Apr 12 14:34:52 2010
From: seb.haase at gmail.com (Sebastian Haase)
Date: Mon, 12 Apr 2010 14:34:52 +0200
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <z2v85e6e6d41004120442j3205df6fj43cc66e3b466373b@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com> 
	<y2ibc657ead1004120037ib572a302h26ec5f4ad0f3d92@mail.gmail.com> 
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com> 
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com> 
	<z2v85e6e6d41004120442j3205df6fj43cc66e3b466373b@mail.gmail.com>
Message-ID: <t2tbc657ead1004120534j22e1578eu2130a88cc74f536@mail.gmail.com>

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 <dan.blacker at googlemail.com> 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 <seb.haase at gmail.com> 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
>> <dan.blacker at googlemail.com> 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 <seb.haase at gmail.com> 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
>> >> <dan.blacker at googlemail.com>
>> >> 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 ?- ?Image-SIG at python.org
>> >> > http://mail.python.org/mailman/listinfo/image-sig
>> >> >
>> >> >
>> >
>> >
>
>

From yury at shurup.com  Mon Apr 12 14:42:03 2010
From: yury at shurup.com (Yury V. Zaytsev)
Date: Mon, 12 Apr 2010 14:42:03 +0200
Subject: [Image-SIG] How to quickly read a Z-axis cut of a
	multipage	TIFF images?
In-Reply-To: <1271059432.7049.31.camel@mypride>
References: <1271059432.7049.31.camel@mypride>
Message-ID: <1271076123.7049.69.camel@mypride>

Hi!

On Mon, 2010-04-12 at 10:03 +0200, Yury V. Zaytsev wrote:

> Therefore I'd like to inquire whether this is an issue with PIL, or
> underlying TIFF reader, or maybe there's a built-in method to quickly
> read Z-axis cut that I didn't consider (I'm a total PIL n00b).

As a follow-up I have got another idea (which I would be quite reluctant
to implement though) on how to dramatically speed up things, that is to
convert the image to an uncompressed binary format which would allow
random seeking (given that the resolution is known and so is the number
of bytes per pixel). 

Or even consider storing lines of pixel luminosity over time one after
another which of course would require to rewrite the whole file to
append frames, but this is not really an issue since the length of the
recording does not change.

However, I'd really like to hear to some other ideas, since these TIFF
files do not seem to be using any compression anyway, so in theory,
sequential seeking operation should not be too expensive?
 
-- 
Sincerely yours,
Yury V. Zaytsev


From olt at bogosoft.com  Mon Apr 12 16:30:57 2010
From: olt at bogosoft.com (Oliver Tonnhofer)
Date: Mon, 12 Apr 2010 16:30:57 +0200
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <t2tbc657ead1004120534j22e1578eu2130a88cc74f536@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com>
	<y2ibc657ead1004120037ib572a302h26ec5f4ad0f3d92@mail.gmail.com>
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com>
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com>
	<z2v85e6e6d41004120442j3205df6fj43cc66e3b466373b@mail.gmail.com>
	<t2tbc657ead1004120534j22e1578eu2130a88cc74f536@mail.gmail.com>
Message-ID: <C359CC3C-777B-483F-8F50-F9C1287DAB46@bogosoft.com>


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

From jcupitt at gmail.com  Mon Apr 12 17:31:00 2010
From: jcupitt at gmail.com (jcupitt at gmail.com)
Date: Mon, 12 Apr 2010 16:31:00 +0100
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <C359CC3C-777B-483F-8F50-F9C1287DAB46@bogosoft.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com> 
	<y2ibc657ead1004120037ib572a302h26ec5f4ad0f3d92@mail.gmail.com> 
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com> 
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com> 
	<z2v85e6e6d41004120442j3205df6fj43cc66e3b466373b@mail.gmail.com> 
	<t2tbc657ead1004120534j22e1578eu2130a88cc74f536@mail.gmail.com> 
	<C359CC3C-777B-483F-8F50-F9C1287DAB46@bogosoft.com>
Message-ID: <n2x522c6461004120831h4c03a599l88fa711ff6d663b0@mail.gmail.com>

On 12 April 2010 15:30, Oliver Tonnhofer <olt at bogosoft.com> 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

From janssen at parc.com  Mon Apr 12 18:23:34 2010
From: janssen at parc.com (Bill Janssen)
Date: Mon, 12 Apr 2010 09:23:34 PDT
Subject: [Image-SIG] AccessInit: hash collision: 3 for both 1 and 1
In-Reply-To: <i2h368a5cd51004081206n31a1bf60uecf34720e6aac2bd@mail.gmail.com>
References: <D3F3B0BA-2944-11D8-80AE-000A956861F6@stanford.edu>
	<loom.20100401T192606-712@post.gmane.org>
	<k2tbc657ead1004030850qa87963a1q8c848408db2ec6e7@mail.gmail.com>
	<7993.1270435301@parc.com>
	<q2j368a5cd51004081033h18bc88fcn3c9b91f2dda10bd1@mail.gmail.com>
	<74375.1270750652@parc.com>
	<i2h368a5cd51004081206n31a1bf60uecf34720e6aac2bd@mail.gmail.com>
Message-ID: <94038.1271089414@parc.com>

Fredrik Lundh <fredrik at pythonware.com> wrote:

> The error should only occur if the C module's initialization function
> is called twice.  That shouldn't happen under normal use of Python
> (and if it happens anyway, it invariably results in resource leaks for
> many modules, and potentially also more serious issues -- the C module
> interface doesn't have a "uninit" mechanism).  Changing the init to
> ignore double initializations only addresses the symptoms.
> 
> (the reason this is a hard error is that collision under normal
> circumstances means that the library is unusable unless rebuilt with
> proper hash settings).
> 
> Googling led me to someone mentioning that this happened after he'd
> used easy_install, but that it went away after rebuilding with
> setup.py.  How did you build your copy?

Setup.py:

python setup.py build --compiler=mingw32 install --prefix="C:\\UpLib\\1.7.9\\python"

I do have setuptools installed in that prefix, though -- need it for
some other modules.  But as long as PIL's setup.py doesn't load it, it
shouldn't be an issue.  I think.  Not sure, perhaps installing
setuptools pollutes distutils right off the bat.

>From the Google hits, it looks to me as if this is something docutils is
doing, perhaps only on Windows, but I don't know what.  That's why I
suggested changing (if possible) the exit(1) to some way of triggering a
Python exception or error, so that we can get a stack trace.

Bill

> 
> </F>
> 
> On Thu, Apr 8, 2010 at 8:17 PM, Bill Janssen <janssen at parc.com> wrote:
> > Fredrik Lundh <fredrik at pythonware.com> wrote:
> >
> >> The idea is that add_item should only be called once for each mode
> >> (see ImagingAccessInit). ?What did you do to trick Python into calling
> >> the module initializer multiple times?
> >
> > I was using epydoc and docutils 0.5 to build my documentation. ?Epydoc
> > crashed with this error. ?If you google "AccessInit: hash collision: 3
> > for both 1 and 1", you'll see it's not just me. ?After I applied my
> > patch, things seem to work fine.
> >
> > Seems to be a problem with Django and Sphinx and Satchmo, too. ?And
> > it looks like maybe it only occurs on Windows. ?I ran into it using
> > PIL built with msys for Python 2.6.4 on Windows XP. ?I've never seen
> > it on OS X or Ubuntu or Fedora.
> >
> > By the way, "exit(1)" is pretty harsh. ?Shouldn't you somehow throw a
> > Python exception there? ?Give us a better chance of figuring out where
> > it's being called from.
> >
> > Bill
> >
> >>
> >> </F>
> >>
> >> On Mon, Apr 5, 2010 at 4:41 AM, Bill Janssen <janssen at parc.com> wrote:
> >> > Seems to me that in libImaging, Access.c:add_item should really read
> >> >
> >> > static ImagingAccess
> >> > add_item(const char* mode)
> >> > {
> >> > ? ?UINT32 i = hash(mode);
> >> > ? ?/* printf("hash %s => %d\n", mode, i); */
> >> > ? ?if (access_table[i].mode && (strcmp(mode, access_table[i].mode) != 0)) {
> >> > ? ? ? ?fprintf(stderr, "AccessInit: hash collision: %d for both %s and %s\n",
> >> > ? ? ? ? ? ? ? ?i, mode, access_table[i].mode);
> >> > ? ? ? ?exit(1);
> >> > ? ?}
> >> > ? ?access_table[i].mode = mode;
> >> > ? ?return &access_table[i];
> >> > }
> >> >
> >> > Currently, it reads:
> >> >
> >> > static ImagingAccess
> >> > add_item(const char* mode)
> >> > {
> >> > ? ?UINT32 i = hash(mode);
> >> > ? ?/* printf("hash %s => %d\n", mode, i); */
> >> > ? ?if (access_table[i].mode) {
> >> > ? ? ? ?fprintf(stderr, "AccessInit: hash collision: %d for both %s and %s\n",
> >> > ? ? ? ? ? ? ? ?i, mode, access_table[i].mode);
> >> > ? ? ? ?exit(1);
> >> > ? ?}
> >> > ? ?access_table[i].mode = mode;
> >> > ? ?return &access_table[i];
> >> > }
> >> >
> >> > And there's a number of Google hits for "AccessInit: hash collision: 3
> >> > for both 1 and 1", starting about the release of 1.1.7.
> >> >
> >> > Bill
> >> > _______________________________________________
> >> > Image-SIG maillist ?- ?Image-SIG at python.org
> >> > http://mail.python.org/mailman/listinfo/image-sig
> >> >
> >

From janssen at parc.com  Mon Apr 12 18:28:58 2010
From: janssen at parc.com (Bill Janssen)
Date: Mon, 12 Apr 2010 09:28:58 PDT
Subject: [Image-SIG] AccessInit: hash collision: 3 for both 1 and 1
In-Reply-To: <n2q368a5cd51004081330va4f2a3e0w2d9f700caa1f0d1d@mail.gmail.com>
References: <D3F3B0BA-2944-11D8-80AE-000A956861F6@stanford.edu>
	<loom.20100401T192606-712@post.gmane.org>
	<k2tbc657ead1004030850qa87963a1q8c848408db2ec6e7@mail.gmail.com>
	<7993.1270435301@parc.com>
	<q2j368a5cd51004081033h18bc88fcn3c9b91f2dda10bd1@mail.gmail.com>
	<74375.1270750652@parc.com>
	<i2h368a5cd51004081206n31a1bf60uecf34720e6aac2bd@mail.gmail.com>
	<n2q368a5cd51004081330va4f2a3e0w2d9f700caa1f0d1d@mail.gmail.com>
Message-ID: <94077.1271089738@parc.com>

Fredrik Lundh <fredrik at pythonware.com> wrote:

> Are you using some virtual env thing that might move modules around,
> btw?  I tried messing with the path to see if I could trick Python
> into importing the same thing twice on Windows, but failed under 2.6.

No, but I am doing something somewhat unusual -- I install all my
extensions, including PIL, in a private directory,
C:\UpLib\1.7.9\python\Lib\site-packages\, and I set PYTHONPATH to that
before running.  What I'm running is epydoc:

  python C:\UpLib\1.7.9\python\Scripts\epydoc --config-file=...

> 
> </F>
> 
> On Thu, Apr 8, 2010 at 9:06 PM, Fredrik Lundh <fredrik at pythonware.com> wrote:
> > The error should only occur if the C module's initialization function
> > is called twice. ?That shouldn't happen under normal use of Python
> > (and if it happens anyway, it invariably results in resource leaks for
> > many modules, and potentially also more serious issues -- the C module
> > interface doesn't have a "uninit" mechanism). ?Changing the init to
> > ignore double initializations only addresses the symptoms.
> >
> > (the reason this is a hard error is that collision under normal
> > circumstances means that the library is unusable unless rebuilt with
> > proper hash settings).
> >
> > Googling led me to someone mentioning that this happened after he'd
> > used easy_install, but that it went away after rebuilding with
> > setup.py. ?How did you build your copy?
> >
> > </F>
> >
> > On Thu, Apr 8, 2010 at 8:17 PM, Bill Janssen <janssen at parc.com> wrote:
> >> Fredrik Lundh <fredrik at pythonware.com> wrote:
> >>
> >>> The idea is that add_item should only be called once for each mode
> >>> (see ImagingAccessInit). ?What did you do to trick Python into calling
> >>> the module initializer multiple times?
> >>
> >> I was using epydoc and docutils 0.5 to build my documentation. ?Epydoc
> >> crashed with this error. ?If you google "AccessInit: hash collision: 3
> >> for both 1 and 1", you'll see it's not just me. ?After I applied my
> >> patch, things seem to work fine.
> >>
> >> Seems to be a problem with Django and Sphinx and Satchmo, too. ?And
> >> it looks like maybe it only occurs on Windows. ?I ran into it using
> >> PIL built with msys for Python 2.6.4 on Windows XP. ?I've never seen
> >> it on OS X or Ubuntu or Fedora.
> >>
> >> By the way, "exit(1)" is pretty harsh. ?Shouldn't you somehow throw a
> >> Python exception there? ?Give us a better chance of figuring out where
> >> it's being called from.
> >>
> >> Bill
> >>
> >>>
> >>> </F>
> >>>
> >>> On Mon, Apr 5, 2010 at 4:41 AM, Bill Janssen <janssen at parc.com> wrote:
> >>> > Seems to me that in libImaging, Access.c:add_item should really read
> >>> >
> >>> > static ImagingAccess
> >>> > add_item(const char* mode)
> >>> > {
> >>> > ? ?UINT32 i = hash(mode);
> >>> > ? ?/* printf("hash %s => %d\n", mode, i); */
> >>> > ? ?if (access_table[i].mode && (strcmp(mode, access_table[i].mode) != 0)) {
> >>> > ? ? ? ?fprintf(stderr, "AccessInit: hash collision: %d for both %s and %s\n",
> >>> > ? ? ? ? ? ? ? ?i, mode, access_table[i].mode);
> >>> > ? ? ? ?exit(1);
> >>> > ? ?}
> >>> > ? ?access_table[i].mode = mode;
> >>> > ? ?return &access_table[i];
> >>> > }
> >>> >
> >>> > Currently, it reads:
> >>> >
> >>> > static ImagingAccess
> >>> > add_item(const char* mode)
> >>> > {
> >>> > ? ?UINT32 i = hash(mode);
> >>> > ? ?/* printf("hash %s => %d\n", mode, i); */
> >>> > ? ?if (access_table[i].mode) {
> >>> > ? ? ? ?fprintf(stderr, "AccessInit: hash collision: %d for both %s and %s\n",
> >>> > ? ? ? ? ? ? ? ?i, mode, access_table[i].mode);
> >>> > ? ? ? ?exit(1);
> >>> > ? ?}
> >>> > ? ?access_table[i].mode = mode;
> >>> > ? ?return &access_table[i];
> >>> > }
> >>> >
> >>> > And there's a number of Google hits for "AccessInit: hash collision: 3
> >>> > for both 1 and 1", starting about the release of 1.1.7.
> >>> >
> >>> > Bill
> >>> > _______________________________________________
> >>> > Image-SIG maillist ?- ?Image-SIG at python.org
> >>> > http://mail.python.org/mailman/listinfo/image-sig
> >>> >
> >>
> >

From Chris.Barker at noaa.gov  Mon Apr 12 18:34:18 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Mon, 12 Apr 2010 09:34:18 -0700
Subject: [Image-SIG] How to quickly read a Z-axis cut of
 a	multipage	TIFF images?
In-Reply-To: <1271076123.7049.69.camel@mypride>
References: <1271059432.7049.31.camel@mypride>
	<1271076123.7049.69.camel@mypride>
Message-ID: <4BC34B8A.1030103@noaa.gov>

Yury V. Zaytsev wrote:
>> Therefore I'd like to inquire whether this is an issue with PIL, or
>> underlying TIFF reader, or maybe there's a built-in method to quickly
>> read Z-axis cut that I didn't consider (I'm a total PIL n00b).

I"m not sure I quite follow what you need to do, but in general, doing 
things one pixel, or line, or... at a time is going to be slow in 
Python. You can't hold it all in memory, but maybe you could work with a 
bunch of frames at a time -- as many as you can hold in memory?

> As a follow-up I have got another idea (which I would be quite reluctant
> to implement though) on how to dramatically speed up things, that is to
> convert the image to an uncompressed binary format which would allow
> random seeking (given that the resolution is known and so is the number
> of bytes per pixel). 

Maybe you could load it all into a numpy memory mapped array, and then 
work with it there? Or maybe hdf5, via PyTables or H5Py.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From Chris.Barker at noaa.gov  Mon Apr 12 20:09:04 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Mon, 12 Apr 2010 11:09:04 -0700
Subject: [Image-SIG] How to quickly read a Z-axis cut of a multipage
 TIFF images?
In-Reply-To: <y2k4207a7ce1004121057q302dc4f3yf94c5bedae9200b1@mail.gmail.com>
References: <1271059432.7049.31.camel@mypride>
	<1271076123.7049.69.camel@mypride> <4BC34B8A.1030103@noaa.gov>
	<y2k4207a7ce1004121057q302dc4f3yf94c5bedae9200b1@mail.gmail.com>
Message-ID: <4BC361C0.50002@noaa.gov>

Joao S. O. Bueno wrote:
> I once implementd a Tiff reader in C using libtiff, and it was not hard 
> to do - maybe you should try and move part of your processing to C , and 
> implement some Python itnerface that would allow you to drive everything 
> with simpler scripting. 
> 
> (For example, you could have a libtiff C function that would create you 
> an Y-Z slice of your data, and return that as a 2d array to python)

If you go this route, I'd strongly recommend using Cython, or maybe 
ctypes for the bindings.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From seb.haase at gmail.com  Mon Apr 12 21:10:33 2010
From: seb.haase at gmail.com (Sebastian Haase)
Date: Mon, 12 Apr 2010 21:10:33 +0200
Subject: [Image-SIG] How to quickly read a Z-axis cut of a multipage
	TIFF images?
In-Reply-To: <4BC361C0.50002@noaa.gov>
References: <1271059432.7049.31.camel@mypride>
	<1271076123.7049.69.camel@mypride> <4BC34B8A.1030103@noaa.gov>
	<y2k4207a7ce1004121057q302dc4f3yf94c5bedae9200b1@mail.gmail.com>
	<4BC361C0.50002@noaa.gov>
Message-ID: <x2ibc657ead1004121210s2af9bde4zbc0f14303df626fb@mail.gmail.com>

Joao,

could you (shortly) outline what kind of  functions you could benefit
from using libtiff directly, rather than PIL (which uses raw python
for this, as
I understand).
Maybe you even show us a short example.
Another reason why I ask, is that I read that libtiff has functions
using memory mapping. So far, I have considered TIF a rather
inappropriate format for large (multi-dimensional) data because it's
not compatible to the mem-map operations I can do using numpy. (i.e. I
always have to read everything  sequentially from the start)

Thanks,
Sebastian Haase



On Mon, Apr 12, 2010 at 8:09 PM, Christopher Barker
<Chris.Barker at noaa.gov> wrote:
> Joao S. O. Bueno wrote:
>>
>> I once implementd a Tiff reader in C using libtiff, and it was not hard to
>> do - maybe you should try and move part of your processing to C , and
>> implement some Python itnerface that would allow you to drive everything
>> with simpler scripting.
>> (For example, you could have a libtiff C function that would create you an
>> Y-Z slice of your data, and return that as a 2d array to python)
>
> If you go this route, I'd strongly recommend using Cython, or maybe ctypes
> for the bindings.
>
> -Chris
>
>
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R ? ? ? ? ? ?(206) 526-6959 ? voice
> 7600 Sand Point Way NE ? (206) 526-6329 ? fax
> Seattle, WA ?98115 ? ? ? (206) 526-6317 ? main reception
>
> Chris.Barker at noaa.gov
> _______________________________________________
> Image-SIG maillist ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>

From g.kloss at massey.ac.nz  Tue Apr 13 02:16:07 2010
From: g.kloss at massey.ac.nz (Guy K. Kloss)
Date: Tue, 13 Apr 2010 12:16:07 +1200
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com>
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com>
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com>
Message-ID: <201004131216.08289.g.kloss@massey.ac.nz>

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
G.Kloss at massey.ac.nz http://www.massey.ac.nz/~gkloss
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100413/68d4596c/attachment.pgp>

From seb.haase at gmail.com  Tue Apr 13 09:09:43 2010
From: seb.haase at gmail.com (Sebastian Haase)
Date: Tue, 13 Apr 2010 09:09:43 +0200
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <201004131216.08289.g.kloss@massey.ac.nz>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com> 
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com> 
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com> 
	<201004131216.08289.g.kloss@massey.ac.nz>
Message-ID: <u2xbc657ead1004130009q57b416dfi6f9f02cea323c985@mail.gmail.com>

On Tue, Apr 13, 2010 at 2:16 AM, Guy K. Kloss <g.kloss at massey.ac.nz> 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

From seb.haase at gmail.com  Tue Apr 13 11:21:09 2010
From: seb.haase at gmail.com (Sebastian Haase)
Date: Tue, 13 Apr 2010 11:21:09 +0200
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <i2s85e6e6d41004130152l8628c15eq92d31841c802ced4@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com> 
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com> 
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com> 
	<201004131216.08289.g.kloss@massey.ac.nz>
	<u2xbc657ead1004130009q57b416dfi6f9f02cea323c985@mail.gmail.com>
	<i2s85e6e6d41004130152l8628c15eq92d31841c802ced4@mail.gmail.com>
Message-ID: <n2kbc657ead1004130221t81a3cbbm626dbecbd5ed106b@mail.gmail.com>

On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
<dan.blacker at googlemail.com> 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

From edward at unicornschool.org  Tue Apr 13 20:56:34 2010
From: edward at unicornschool.org (Edward Cannon)
Date: Tue, 13 Apr 2010 11:56:34 -0700
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <n2kbc657ead1004130221t81a3cbbm626dbecbd5ed106b@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com>
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com>
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com>
	<201004131216.08289.g.kloss@massey.ac.nz>
	<u2xbc657ead1004130009q57b416dfi6f9f02cea323c985@mail.gmail.com>
	<i2s85e6e6d41004130152l8628c15eq92d31841c802ced4@mail.gmail.com>
	<n2kbc657ead1004130221t81a3cbbm626dbecbd5ed106b@mail.gmail.com>
Message-ID: <z2jb986b291004131156zdf9c68b8u564f5aeb770c2d3d@mail.gmail.com>

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 <seb.haase at gmail.com> wrote:
> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
> <dan.blacker at googlemail.com> 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 ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>

From yury at shurup.com  Fri Apr 16 15:40:43 2010
From: yury at shurup.com (Yury V. Zaytsev)
Date: Fri, 16 Apr 2010 15:40:43 +0200
Subject: [Image-SIG] Flood fill with threshold
Message-ID: <1271425243.7122.54.camel@mypride>

Hi!

I have an image with certain areas that are bounded by color boundaries.
I'd like to have a program that flood fills the region with a certain
threshold after the user clicks on the image and records the pixels that
belong to this area.

I found out that Gimp's flood fill tool with threshold 48 does exactly
what I want. Has anyone got a clue on what is the algorithm they used?

All I could find after short Googling are flood-fill algorithms where
you give the target color explicitly which I do not want to do, because
I don't know it and also it varies slightly across the border.

Is there any implementation I might refer to other than downloading
Gimp's source code and trying to make sense out of it?

Thanks!
 
-- 
Sincerely yours,
Yury V. Zaytsev


From yury at shurup.com  Fri Apr 16 16:50:22 2010
From: yury at shurup.com (Yury V. Zaytsev)
Date: Fri, 16 Apr 2010 16:50:22 +0200
Subject: [Image-SIG] Flood fill with threshold
In-Reply-To: <CAD40DEA-6703-4A11-A7B6-F00FF049E5CD@gmail.com>
References: <1271425243.7122.54.camel@mypride>
	<CAD40DEA-6703-4A11-A7B6-F00FF049E5CD@gmail.com>
Message-ID: <1271429422.7122.62.camel@mypride>

Hi!

On Fri, 2010-04-16 at 07:42 -0700, Edward Cannon wrote:
> What you need to do is pass the color to one of these algorithms at  
> run time. Getting the color is a UI problem--use tinker or the like.

I can't to this, because I don't know it. I only know the seed point.
Also, the border color is not constant, it varies a little bit. What I
want to get is the analog of the Gimp thresholded flood fill tool. 

Right know I have found Eric Raymond's flood fill code in ImgDraw.py and
trying to adapt it to use a threshold, but it's not entirely clear how
to define distance in terms of colors. Maybe just as the distance
between vectors will do.
 
-- 
Sincerely yours,
Yury V. Zaytsev


From dan.blacker at googlemail.com  Mon Apr 12 13:42:19 2010
From: dan.blacker at googlemail.com (Dan Blacker)
Date: Mon, 12 Apr 2010 12:42:19 +0100
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com>
	<y2ibc657ead1004120037ib572a302h26ec5f4ad0f3d92@mail.gmail.com>
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com>
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com>
Message-ID: <z2v85e6e6d41004120442j3205df6fj43cc66e3b466373b@mail.gmail.com>

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 <seb.haase at gmail.com> 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
> <dan.blacker at googlemail.com> 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 <seb.haase at gmail.com> 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 <
> dan.blacker at googlemail.com>
> >> 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  -  Image-SIG at python.org
> >> > http://mail.python.org/mailman/listinfo/image-sig
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100412/dd0b56d5/attachment-0001.html>

From dan.blacker at googlemail.com  Mon Apr 12 14:48:09 2010
From: dan.blacker at googlemail.com (Dan Blacker)
Date: Mon, 12 Apr 2010 13:48:09 +0100
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <t2tbc657ead1004120534j22e1578eu2130a88cc74f536@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com>
	<y2ibc657ead1004120037ib572a302h26ec5f4ad0f3d92@mail.gmail.com>
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com>
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com>
	<z2v85e6e6d41004120442j3205df6fj43cc66e3b466373b@mail.gmail.com>
	<t2tbc657ead1004120534j22e1578eu2130a88cc74f536@mail.gmail.com>
Message-ID: <t2y85e6e6d41004120548iabfe9e5dwf781fd44323e9f7e@mail.gmail.com>

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 <seb.haase at gmail.com> 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 <dan.blacker at googlemail.com>
> 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 <seb.haase at gmail.com> 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
> >> <dan.blacker at googlemail.com> 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 <seb.haase at gmail.com> 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
> >> >> <dan.blacker at googlemail.com>
> >> >> 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  -  Image-SIG at python.org
> >> >> > http://mail.python.org/mailman/listinfo/image-sig
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100412/85145245/attachment-0001.html>

From dan.blacker at googlemail.com  Mon Apr 12 16:40:03 2010
From: dan.blacker at googlemail.com (Dan Blacker)
Date: Mon, 12 Apr 2010 15:40:03 +0100
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <C359CC3C-777B-483F-8F50-F9C1287DAB46@bogosoft.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com>
	<y2ibc657ead1004120037ib572a302h26ec5f4ad0f3d92@mail.gmail.com>
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com>
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com>
	<z2v85e6e6d41004120442j3205df6fj43cc66e3b466373b@mail.gmail.com>
	<t2tbc657ead1004120534j22e1578eu2130a88cc74f536@mail.gmail.com>
	<C359CC3C-777B-483F-8F50-F9C1287DAB46@bogosoft.com>
Message-ID: <r2j85e6e6d41004120740hfe33432fy713d20395bd89eb2@mail.gmail.com>

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 <olt at bogosoft.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100412/9e898676/attachment-0001.html>

From gwidion at mpc.com.br  Mon Apr 12 19:57:39 2010
From: gwidion at mpc.com.br (Joao S. O. Bueno)
Date: Mon, 12 Apr 2010 14:57:39 -0300
Subject: [Image-SIG] How to quickly read a Z-axis cut of a multipage
	TIFF images?
In-Reply-To: <4BC34B8A.1030103@noaa.gov>
References: <1271059432.7049.31.camel@mypride>
	<1271076123.7049.69.camel@mypride> <4BC34B8A.1030103@noaa.gov>
Message-ID: <y2k4207a7ce1004121057q302dc4f3yf94c5bedae9200b1@mail.gmail.com>

Hi Christopher -

Image these sizes are certainly not apropriate to be dealt with straight
from Python code on a pixel by pixel basis.

I once implementd a Tiff reader in C using libtiff, and it was not hard to
do - maybe you should try and move part of your processing to C , and
implement some Python itnerface that would allow you to drive everything
with simpler scripting.

(For example, you could have a libtiff C function that would create you an
Y-Z slice of your data, and return that as a 2d array to python)


I don't know the hdf5 tables or H5Py Dr. barker mentioned above, but if you
feel like purisuing the C-libtiff with python bindings line, feel free to
contact me.


  js
  -><-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100412/dddad659/attachment-0001.html>

From dan.blacker at googlemail.com  Tue Apr 13 10:52:43 2010
From: dan.blacker at googlemail.com (Dan Blacker)
Date: Tue, 13 Apr 2010 09:52:43 +0100
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <u2xbc657ead1004130009q57b416dfi6f9f02cea323c985@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com>
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com>
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com>
	<201004131216.08289.g.kloss@massey.ac.nz>
	<u2xbc657ead1004130009q57b416dfi6f9f02cea323c985@mail.gmail.com>
Message-ID: <i2s85e6e6d41004130152l8628c15eq92d31841c802ced4@mail.gmail.com>

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 <seb.haase at gmail.com> wrote:

> On Tue, Apr 13, 2010 at 2:16 AM, Guy K. Kloss <g.kloss at massey.ac.nz>
> 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  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100413/200a4a86/attachment-0001.html>

From ioannis87 at gmail.com  Wed Apr 14 11:14:37 2010
From: ioannis87 at gmail.com (ioannis syntychakis)
Date: Wed, 14 Apr 2010 11:14:37 +0200
Subject: [Image-SIG] indicate object with square
Message-ID: <i2sdd7e20151004140214g620f26e9hd06e294bcaf8a2@mail.gmail.com>

Hallo,

can anybody halp me with the follow;

ik have a gryscale image with round objectsin it. I have written a program
to detect this objects. (this objects are 10x10 pixel big) then i calculate
the average pixelvalue of these objects.  Some of the objects can't be found
automatically. so, i want that the usser of the program could be able
to indicate these objects.
i was thinking about that the user has a square on his mouse and can
indicate the object.

Is this possible?

thanks in advance,

greetings, Jannis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100414/5550c7c8/attachment-0001.html>

From blindlemonsam at gmail.com  Fri Apr 16 14:48:38 2010
From: blindlemonsam at gmail.com (Samuel Moore)
Date: Fri, 16 Apr 2010 14:48:38 +0200
Subject: [Image-SIG] DPI
Message-ID: <000401cadd63$25d30e50$71792af0$@com>

I am trying to determine DPI from images. Can anyone help?

I tried:

 

img = Image.open("Hamerkop.jpg")

img.info["dpi"] 

 

but it doesn't work for all jpegs. 

 

Python 2.5.1

PIL 1.1.7

 

Regards,

Sam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100416/93bd1717/attachment-0001.html>

From cannon.el at gmail.com  Fri Apr 16 16:42:36 2010
From: cannon.el at gmail.com (Edward Cannon)
Date: Fri, 16 Apr 2010 07:42:36 -0700
Subject: [Image-SIG] Flood fill with threshold
In-Reply-To: <1271425243.7122.54.camel@mypride>
References: <1271425243.7122.54.camel@mypride>
Message-ID: <CAD40DEA-6703-4A11-A7B6-F00FF049E5CD@gmail.com>

What you need to do is pass the color to one of these algorithms at  
run time. Getting the color is a UI problem--use tinker or the like.
Edward Cannon
Unicorn School



On Apr 16, 2010, at 6:40 AM, "Yury V. Zaytsev" <yury at shurup.com> wrote:

> Hi!
>
> I have an image with certain areas that are bounded by color  
> boundaries.
> I'd like to have a program that flood fills the region with a certain
> threshold after the user clicks on the image and records the pixels  
> that
> belong to this area.
>
> I found out that Gimp's flood fill tool with threshold 48 does exactly
> what I want. Has anyone got a clue on what is the algorithm they used?
>
> All I could find after short Googling are flood-fill algorithms where
> you give the target color explicitly which I do not want to do,  
> because
> I don't know it and also it varies slightly across the border.
>
> Is there any implementation I might refer to other than downloading
> Gimp's source code and trying to make sense out of it?
>
> Thanks!
>
> -- 
> Sincerely yours,
> Yury V. Zaytsev
>
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig

From cannon.el at gmail.com  Fri Apr 16 17:47:55 2010
From: cannon.el at gmail.com (Edward Cannon)
Date: Fri, 16 Apr 2010 08:47:55 -0700
Subject: [Image-SIG] Flood fill with threshold
In-Reply-To: <1271429422.7122.62.camel@mypride>
References: <1271425243.7122.54.camel@mypride>
	<CAD40DEA-6703-4A11-A7B6-F00FF049E5CD@gmail.com>
	<1271429422.7122.62.camel@mypride>
Message-ID: <BF8558BE-2648-4F42-9947-D0F98DFC8A85@gmail.com>





On Apr 16, 2010, at 7:50 AM, "Yury V. Zaytsev" <yury at shurup.com> wrote:

> Hi!
>
> On Fri, 2010-04-16 at 07:42 -0700, Edward Cannon wrote:
>> What you need to do is pass the color to one of these algorithms at
>> run time. Getting the color is a UI problem--use tinker or the like.
>
> I can't to this, because I don't know it. I only know the seed point.
> Also, the border color is not constant, it varies a little bit. What I
> want to get is the analog of the Gimp thresholded flood fill tool.
If you have the point you can get the color there with the getpixel  
method.
> Right know I have found Eric Raymond's flood fill code in ImgDraw.py  
> and
> trying to adapt it to use a threshold, but it's not entirely clear how
> to define distance in terms of colors. Maybe just as the distance
> between vectors will do.
I have found that works pretty well.
> -- 
> Sincerely yours,
> Yury V. Zaytsev
>

From lukasz at langa.pl  Sun Apr 18 02:18:47 2010
From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=)
Date: Sun, 18 Apr 2010 02:18:47 +0200
Subject: [Image-SIG] AccessInit: hash collision: 3 for both 1 and 1
Message-ID: <FCF4EAA1-9440-48F2-A185-1C3822FCB6AB@langa.pl>

This is not a proper reply in terms of e-mail but I registered just a second ago just to write this post. So, here goes, replying to Frederik's message from Thu Apr 08 15:01:06 2010:
> Are you using some virtual env thing that might move modules around,
> btw?  I tried messing with the path to see if I could trick Python
> into importing the same thing twice on Windows, but failed under 2.6.
This is actually quite simple. When you easy_install PIL, you get the "pollute the global namespace" variant (e.g. import Image). Django on the other hand expects the "be pollite within your own namespace" variant (e.g. from PIL import Image). So if there's any .pth file or symbolic link that is supposed to cover for that, your going to have an error:

$ python
Python 2.6.5 (r265:79063, Mar 26 2010, 16:07:38) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import _imaging
>>> import PIL._imaging
AccessInit: hash collision: 3 for both 1 and 1

The problem is, the default easy_install distribution does not provide the PIL.* variant whereas no stable Django version is as of yet using the global namespace version (see http://code.djangoproject.com/ticket/6054). The fact is that they on multiple occasions refused to make that change, I wonder what made them change their decision. That way or the other, it's a setuptools PIL packaging issue. Maybe the easiest and most compatible solution would be to simply include a PIL.py file along the distro with contents of the like:

import _imaging
import Image
import ImageFile
...

I don't really have the experience to make any remarks here, let alone decisions. So, it's up to you :)

-- 
Best regards,
?ukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100418/21103753/attachment.html>

From yury at shurup.com  Sun Apr 18 23:27:58 2010
From: yury at shurup.com (Yury V. Zaytsev)
Date: Sun, 18 Apr 2010 23:27:58 +0200
Subject: [Image-SIG] indicate object with square
In-Reply-To: <i2sdd7e20151004140214g620f26e9hd06e294bcaf8a2@mail.gmail.com>
References: <i2sdd7e20151004140214g620f26e9hd06e294bcaf8a2@mail.gmail.com>
Message-ID: <1271626078.7218.16.camel@mypride>

On Wed, 2010-04-14 at 11:14 +0200, ioannis syntychakis wrote:
> i was thinking about that the user has a square on his mouse and can
> indicate the object. 

Not with bare PIL, but certainly doable with matplotlib (e.g. see
ginput function for an example).

-- 
Sincerely yours,
Yury V. Zaytsev


From fredrik at pythonware.com  Sun Apr 18 23:36:17 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sun, 18 Apr 2010 23:36:17 +0200
Subject: [Image-SIG] AccessInit: hash collision: 3 for both 1 and 1
In-Reply-To: <FCF4EAA1-9440-48F2-A185-1C3822FCB6AB@langa.pl>
References: <FCF4EAA1-9440-48F2-A185-1C3822FCB6AB@langa.pl>
Message-ID: <o2j368a5cd51004181436vdbf7ae33y3fca40a8f8d94925@mail.gmail.com>

2010/4/18 ?ukasz Langa <lukasz at langa.pl>:
> This is not a proper reply in terms of e-mail but I registered just a second
> ago just to write this post. So, here goes, replying to Frederik's message
> from?Thu Apr 08 15:01:06 2010:
>
> Are you using some virtual env thing that might move modules around,
> btw?  I tried messing with the path to see if I could trick Python
> into importing the same thing twice on Windows, but failed under 2.6.
>
> This is actually quite simple. When you easy_install PIL, you get the
> "pollute the global namespace" variant (e.g. import Image). Django on the
> other hand expects the "be pollite within your own namespace" variant (e.g.
> from PIL import Image). So if there's any .pth file or symbolic link that is
> supposed to cover for that, your going to have an error:
> $ python
> Python 2.6.5 (r265:79063, Mar 26 2010, 16:07:38)
> [GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import _imaging
>>>> import PIL._imaging
> AccessInit: hash collision: 3 for both 1 and 1

Interesting.  Can you repeat this with -v and report from where the
modules are loaded?

</F>

PS. For reference, here's the -v output for the above commands on a
2.6.5 stock install on Windows:

>>> import _imaging
# c:\python26\lib\encodings\cp850.pyc matches c:\python26\lib\encodings\cp850.py
import encodings.cp850 # precompiled from c:\python26\lib\encodings\cp850.pyc
import _imaging # dynamically loaded from
c:\python26\lib\site-packages\PIL\_imaging.pyd
>>> import PIL._imaging
import PIL # directory c:\python26\lib\site-packages\PIL
# c:\python26\lib\site-packages\PIL\__init__.pyc matches
c:\python26\lib\site-packages\PIL\__init__.py
import PIL # precompiled from c:\python26\lib\site-packages\PIL\__init__.pyc
import PIL._imaging # previously loaded
(c:\python26\lib\site-packages\PIL\_imaging.pyd)

Note the last line: python correctly figures out that both imports
refer to the same module.

> The problem is, the default easy_install distribution does not provide the
> PIL.* variant whereas no stable Django version is as of yet using the global
> namespace version (see?http://code.djangoproject.com/ticket/6054). The fact
> is that they on multiple occasions refused to make that change, I wonder
> what made them change their decision. That way or the other, it's a
> setuptools PIL packaging issue. Maybe the easiest and most compatible
> solution would be to simply include a PIL.py file along the distro with
> contents of the like:
> import _imaging
> import Image
> import ImageFile
> ...
> I don't really have the experience to make any remarks here, let alone
> decisions. So, it's up to you :)
> --
> Best regards,
> ?ukasz Langa
> tel. +48 791 080 144
> WWW http://lukasz.langa.pl/
>
> _______________________________________________
> Image-SIG maillist ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>
>

From songuke at gmail.com  Mon Apr 19 04:31:41 2010
From: songuke at gmail.com (Son Hua)
Date: Mon, 19 Apr 2010 10:31:41 +0800
Subject: [Image-SIG] Performance for image processing in Python
Message-ID: <4BCBC08D.50108@gmail.com>

Hi everyone,

I'm quite new Python here. Recently I wrote an image mosaicking 
application in Python (using Numpy library). It turns out that the 
performance is quite terrible. For example, a mosaic of 7 images, each 
800x600, the output size is about 8000x2000. Each output pixel is 
sampled from the source images using bilinear interpolation according to 
the inverse homography. The running time is nearly 1 hour.

State-of-the-art commercial mosaicking software (written in C) runs the 
above examples in less than 10 seconds!!!

I wonder how is other Python image processing applications' performance? 
Do we always need to implement slow functions in C? E.g., I suppose to 
reimplement the bilinear interpolation in C, as it is called million 
times in Python, which is slow.

Thank you.

From g.kloss at massey.ac.nz  Mon Apr 19 05:28:05 2010
From: g.kloss at massey.ac.nz (Guy K. Kloss)
Date: Mon, 19 Apr 2010 15:28:05 +1200
Subject: [Image-SIG] Performance for image processing in Python
In-Reply-To: <4BCBC08D.50108@gmail.com>
References: <4BCBC08D.50108@gmail.com>
Message-ID: <201004191528.06814.g.kloss@massey.ac.nz>

On Mon, 19 Apr 2010 14:31:41 Son Hua wrote:
> I'm quite new Python here. Recently I wrote an image mosaicking 
> application in Python (using Numpy library). It turns out that the 
> performance is quite terrible. [...]
> 
> State-of-the-art commercial mosaicking software (written in C) runs the 
> above examples in less than 10 seconds!!!
> 
> I wonder how is other Python image processing applications' performance? 
> Do we always need to implement slow functions in C? E.g., I suppose to 
> reimplement the bilinear interpolation in C, as it is called million 
> times in Python, which is slow.

Well, as you stated: You seem to be fairly new to Python. Just *using* NumPy 
does not guarantee good performance. The trick is to *use it right*. One 
example in C is for example also to use the right order of iterating over 
multi dimensional arrays to get the right performance. Otherwise you may be 
playing against the cache, which is fairly common on huge data structures.

So, one thing you ought to look for in your code is that you're for example 
*not* iterate over the elements of an array (pixelx), but use operations that 
are to be applied to the whole array at once. You can use these with most 
basic and more complex operations, e. g. multiply/divide/add/subtract a 
scalar, apply certain NumPy provided functions (g. g. sin() or log()), apply 
dot-product multiplication, etc.

Doing that, you can probably eliminate orders of magnitude of slowdown 
already.

HTH,

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
G.Kloss at massey.ac.nz http://www.massey.ac.nz/~gkloss
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100419/81f26f53/attachment.pgp>

From jcupitt at gmail.com  Mon Apr 19 12:13:39 2010
From: jcupitt at gmail.com (jcupitt at gmail.com)
Date: Mon, 19 Apr 2010 11:13:39 +0100
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <t2y85e6e6d41004120548iabfe9e5dwf781fd44323e9f7e@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com> 
	<y2ibc657ead1004120037ib572a302h26ec5f4ad0f3d92@mail.gmail.com> 
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com> 
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com> 
	<z2v85e6e6d41004120442j3205df6fj43cc66e3b466373b@mail.gmail.com> 
	<t2tbc657ead1004120534j22e1578eu2130a88cc74f536@mail.gmail.com> 
	<t2y85e6e6d41004120548iabfe9e5dwf781fd44323e9f7e@mail.gmail.com>
Message-ID: <w2g522c6461004190313i6cd86bf4k94ad4a17f37338f6@mail.gmail.com>

On 12 April 2010 13:48, Dan Blacker <dan.blacker at googlemail.com> 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

From yury at shurup.com  Mon Apr 19 16:07:46 2010
From: yury at shurup.com (Yury V. Zaytsev)
Date: Mon, 19 Apr 2010 16:07:46 +0200
Subject: [Image-SIG] Reversed X an Y when convering PIL images to NumPy
	arrays
Message-ID: <1271686066.7093.58.camel@mypride>

Hi!

Is it normal when I execute the following code I get the red dot at X =
200, Y = 100 on the plot?! I would have expected to be able to address
pixels in the resulting array in a usual p[X, Y] format.

I might be blind, but I haven't found anything in the documentation.
Actually I have found out about the possibility to interface with Numpy
itself at some blog: http://effbot.org/zone/pil-changes-116.htm .

import Image
import numpy as np
import pylab as pyl

if __name__ == "__main__":

    img_name = 'ch43_roi.tiff'
    img = Image.open(img_name)

    a = np.asarray(img)

    p = a.copy()
    p[100, 200] = (255, 0, 0)

    pyl.imshow(p)
    pyl.show()

 
-- 
Sincerely yours,
Yury V. Zaytsev


From Chris.Barker at noaa.gov  Mon Apr 19 19:00:55 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Mon, 19 Apr 2010 10:00:55 -0700
Subject: [Image-SIG] Reversed X an Y when convering PIL images to NumPy
 arrays
In-Reply-To: <1271686066.7093.58.camel@mypride>
References: <1271686066.7093.58.camel@mypride>
Message-ID: <4BCC8C47.30406@noaa.gov>

Yury V. Zaytsev wrote:
> Is it normal when I execute the following code I get the red dot at X =
> 200, Y = 100 on the plot?!

yes, I think it is.

> I would have expected to be able to address
> pixels in the resulting array in a usual p[X, Y] format.

IIRC, the standard data storage for PIL iamges results in a (h, w) 
array, rather than a (w, h) one -- using X,Y, rather than Y,X is just a 
convention.

In numpy -- the convention is to think of and display the indexing as 
(row, column), hence (y, x), and MPL displays it that way.

you can just use (y,x) , or you can transpose the array:

 >     p = a.T.copy()

Remember to transpose back if you want to make a PIL image again.

-Chris



> I might be blind, but I haven't found anything in the documentation.
> Actually I have found out about the possibility to interface with Numpy
> itself at some blog: http://effbot.org/zone/pil-changes-116.htm .
> 
> import Image
> import numpy as np
> import pylab as pyl
> 
> if __name__ == "__main__":
> 
>     img_name = 'ch43_roi.tiff'
>     img = Image.open(img_name)
> 
>     a = np.asarray(img)
> 
>     p = a.copy()
>     p[100, 200] = (255, 0, 0)
> 
>     pyl.imshow(p)
>     pyl.show()
> 
>  


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From Chris.Barker at noaa.gov  Mon Apr 19 19:08:18 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Mon, 19 Apr 2010 10:08:18 -0700
Subject: [Image-SIG] Performance for image processing in Python
In-Reply-To: <4BCBC08D.50108@gmail.com>
References: <4BCBC08D.50108@gmail.com>
Message-ID: <4BCC8E02.7060008@noaa.gov>

Son Hua wrote:
> I'm quite new Python here. Recently I wrote an image mosaicking 
> application in Python (using Numpy library). It turns out that the 
> performance is quite terrible. For example, a mosaic of 7 images, each 
> 800x600, the output size is about 8000x2000. Each output pixel is 
> sampled from the source images using bilinear interpolation according to 
> the inverse homography. The running time is nearly 1 hour.
> 
> State-of-the-art commercial mosaicking software (written in C) runs the 
> above examples in less than 10 seconds!!!

Note that "State-of-the-art" image processing software is likely not 
only written in C, but also highly optimized -- taking into account 
cache sizes, using special instructions, etc, so you've not going to get 
close with naively written code. Still a factor of ten or so maybe.

> I wonder how is other Python image processing applications' performance? 
> Do we always need to implement slow functions in C?

in a word, yes -- if you are looping trough pixels in python, it's going 
to be painfully slow - python simply is not designed for that kind of thing.

> E.g., I suppose to 
> reimplement the bilinear interpolation in C, as it is called million 
> times in Python, which is slow.

have you looked at the ndarray package? or PIL's interpolation for that 
matter? both are written in C.

If they don't have the algorithm you need, as a another poster pointed 
out, smart use of numpy will help a lot (essentially,l you are getting 
the inner loop in c via numpy)

If you have not idea how to do that, read up a bit on scipy.org, and 
then post a question to the numpy list.

Option 3 is Cython -- it lets you write C code in an almost-python 
syntax, and it understand numpy arrays, to it's really easy to re-write 
that inner loop in C.

-Chris





-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From edward at unicornschool.org  Mon Apr 19 19:08:25 2010
From: edward at unicornschool.org (Edward Cannon)
Date: Mon, 19 Apr 2010 10:08:25 -0700
Subject: [Image-SIG] indicate object with square
In-Reply-To: <1271626078.7218.16.camel@mypride>
References: <i2sdd7e20151004140214g620f26e9hd06e294bcaf8a2@mail.gmail.com>
	<1271626078.7218.16.camel@mypride>
Message-ID: <i2jb986b291004191008n9783c511o93586b16aa736faf@mail.gmail.com>

Tkinter is also a viable option for this sort of thing, it has a
relatively portable interface and plays well with PIL (as long as you
do import PIL.Image)

On Sun, Apr 18, 2010 at 2:27 PM, Yury V. Zaytsev <yury at shurup.com> wrote:
>
> On Wed, 2010-04-14 at 11:14 +0200, ioannis syntychakis wrote:
> > i was thinking about that the user has a square on his mouse and can
> > indicate the object.
>
> Not with bare PIL, but certainly doable with matplotlib (e.g. see
> ginput function for an example).
>
> --
> Sincerely yours,
> Yury V. Zaytsev
>
> _______________________________________________
> Image-SIG maillist ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig

From Chris.Barker at noaa.gov  Mon Apr 19 19:09:01 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Mon, 19 Apr 2010 10:09:01 -0700
Subject: [Image-SIG] indicate object with square
In-Reply-To: <1271626078.7218.16.camel@mypride>
References: <i2sdd7e20151004140214g620f26e9hd06e294bcaf8a2@mail.gmail.com>
	<1271626078.7218.16.camel@mypride>
Message-ID: <4BCC8E2D.1060703@noaa.gov>

Yury V. Zaytsev wrote:
> On Wed, 2010-04-14 at 11:14 +0200, ioannis syntychakis wrote:
>> i was thinking about that the user has a square on his mouse and can
>> indicate the object. 
> 
> Not with bare PIL, but certainly doable with matplotlib (e.g. see
> ginput function for an example).

or any of the GUI toolkits: Tk, GTK, wxPython, QT ...

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From yury at shurup.com  Mon Apr 19 23:04:57 2010
From: yury at shurup.com (Yury V. Zaytsev)
Date: Mon, 19 Apr 2010 23:04:57 +0200
Subject: [Image-SIG] Reversed X an Y when convering PIL images to
	NumPy	arrays
In-Reply-To: <4BCC8C47.30406@noaa.gov>
References: <1271686066.7093.58.camel@mypride>  <4BCC8C47.30406@noaa.gov>
Message-ID: <1271711097.7223.22.camel@mypride>

Hi Christopher!

Thank you very much for the elucidations; now I know that this is a
feature (also, the initial array seems to be mapped directly to the
image representation in memory, which implies that it is visible as read
only from NumPy unless you make a full copy of it). 

Your suggested solution works well for me.
 
-- 
Sincerely yours,
Yury V. Zaytsev



From yury at shurup.com  Tue Apr 20 10:59:51 2010
From: yury at shurup.com (Yury V. Zaytsev)
Date: Tue, 20 Apr 2010 10:59:51 +0200
Subject: [Image-SIG] Reversed X an Y when convering PIL images to
	NumPy	arrays
In-Reply-To: <4BCC8C47.30406@noaa.gov>
References: <1271686066.7093.58.camel@mypride>  <4BCC8C47.30406@noaa.gov>
Message-ID: <1271753991.7089.21.camel@mypride>

On Mon, 2010-04-19 at 10:00 -0700, Christopher Barker wrote:

> you can just use (y,x) , or you can transpose the array:
> 
>  >     p = a.T.copy()

FYI, this will not work for anything that is not grayscale arrays. 
You need to use p = a.copy().transpose((1, 0, 2)).

Thanks again,
 
-- 
Sincerely yours,
Yury V. Zaytsev


From yury at shurup.com  Tue Apr 20 18:00:23 2010
From: yury at shurup.com (Yury V. Zaytsev)
Date: Tue, 20 Apr 2010 18:00:23 +0200
Subject: [Image-SIG] Flood fill with threshold
In-Reply-To: <BF8558BE-2648-4F42-9947-D0F98DFC8A85@gmail.com>
References: <1271425243.7122.54.camel@mypride>
	<CAD40DEA-6703-4A11-A7B6-F00FF049E5CD@gmail.com>
	<1271429422.7122.62.camel@mypride>
	<BF8558BE-2648-4F42-9947-D0F98DFC8A85@gmail.com>
Message-ID: <1271779223.7089.37.camel@mypride>

On Fri, 2010-04-16 at 08:47 -0700, Edward Cannon wrote:

> > Right know I have found Eric Raymond's flood fill code in ImgDraw.py  
> > trying to adapt it to use a threshold, but it's not entirely clear how
> > to define distance in terms of colors. Maybe just as the distance
> > between vectors will do.
> I have found that works pretty well.

FYI, I have finished to code so that it actually works. I want to send
the solution I came up with to the list so that the others can benefit.

Interestingly enough I have found that COMPOSITE and HUE distances work
best for me depending on the circumstances. Enjoy!

import numpy as np
import colorsys as cs

def pixel_difference(col1, col2, threshold, select_criterion = "CRITERION_COMPOSITE"):
    """
    Direct reimplementation of gimp-2.6.8/app/core/gimpimage-contiguous-region.c.
    GIMP software is licensed under GPL.
    """

    if select_criterion == "CRITERION_COMPOSITE":
        max = np.max(np.abs(col1 - col2))
    elif select_criterion == "CRITERION_R":
        max = np.max(np.abs(col1[0] - col2[0]))
    elif select_criterion == "CRITERION_G":
        max = np.max(np.abs(col1[1] - col2[1]))
    elif select_criterion == "CRITERION_B":
        max = np.max(np.abs(col1[2] - col2[2]))
    elif select_criterion in ("CRITERION_H", "CRITERION_S", "CRITERION_V"):
        av0, av1, av2 = cs.rgb_to_hsv( *col1 )
        bv0, bv1, bv2 = cs.rgb_to_hsv( *col2 )
        if select_criterion == "CRITERION_H":
            dist1 = np.abs(av0 - bv0)
            dist2 = np.abs(av0 - 360 - bv0)
            dist3 = np.abs(av0 - bv0 + 360)
            max = np.min( (dist1, dist2) )
            if (max > dist3):
                max = dist3
        elif select_criterion == "CRITERION_S":
            max = np.abs(av1 - bv1)
        elif select_criterion == "CRITERION_V":
            max = np.abs(av2 - bv2)
    else:
        raise ValueError("Invalid select_criterion supplied!")

    if (max < threshold):
        return True
    else:
        return False

def floodfill(pixels, seed, value, threshold, criterion = "CRITERION_COMPOSITE", bitness = 8, return_region = False):
    """
    Fill bounded region, based on an implementation by Eric S. Raymond:
    http://mail.python.org/pipermail/image-sig/2005-September/003559.html

    Licence unspecified, might count as public domain.
    """

    max_color = np.power(2, bitness) - 1
    threshold *= 1. / max_color
    x, y = seed

    # Color normalization, so that the colors are in the range [0, 1]
    def normalize (color):
        return [value * 1. / max_color for value in color]
    
    # Get and normalize the color of the seed point
    seed_normalized = normalize(pixels[x, y])
    pixels[x, y] = value

    if return_region:
        roi = [ (x, y) ]
    
    edge = [ (x, y) ]
    while edge:
        newedge = []
        for (x, y) in edge:
            for (s, t) in ((x + 1, y), (x - 1, y), (x, y + 1), (x, y - 1)):
                try:
                    item = pixels[s, t]
                except IndexError:
                    pass
                else:
                    if pixel_difference(seed_normalized, normalize(item), threshold, criterion) and \
                            not np.alltrue(item == value):
                        pixels[s, t] = value
                        newedge.append((s, t))
                        if return_region and not (s, t) in roi:
                            roi.append( (s, t) )
        edge = newedge
    
    if return_region:
        return roi

 
-- 
Sincerely yours,
Yury V. Zaytsev


From zac256 at gmail.com  Tue Apr 20 23:07:16 2010
From: zac256 at gmail.com (Zac Burns)
Date: Tue, 20 Apr 2010 14:07:16 -0700
Subject: [Image-SIG] paul gibson
Message-ID: <i2r333edbe81004201407v2618b540y16d8661e151bd108@mail.gmail.com>

http://essana.fr/home.php

-- 
Zachary Burns
(407)590-4814
Aim - Zac256FL
Production Engineer
Zindagi Games

From lukasz at langa.pl  Mon Apr 19 00:08:56 2010
From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=)
Date: Mon, 19 Apr 2010 00:08:56 +0200
Subject: [Image-SIG] AccessInit: hash collision: 3 for both 1 and 1
In-Reply-To: <o2j368a5cd51004181436vdbf7ae33y3fca40a8f8d94925@mail.gmail.com>
References: <FCF4EAA1-9440-48F2-A185-1C3822FCB6AB@langa.pl>
	<o2j368a5cd51004181436vdbf7ae33y3fca40a8f8d94925@mail.gmail.com>
Message-ID: <03B265D9-49D9-4066-A2F2-220296D02EA1@langa.pl>


Wiadomo?? napisana przez Fredrik Lundh w dniu 2010-04-18, o godz. 23:36:

> 2010/4/18 ?ukasz Langa <lukasz at langa.pl>:
>> $ python
>> Python 2.6.5 (r265:79063, Mar 26 2010, 16:07:38)
>> [GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import _imaging
>>>>> import PIL._imaging
>> AccessInit: hash collision: 3 for both 1 and 1
> 
> Interesting.  Can you repeat this with -v and report from where the
> modules are loaded?

Sure. It's probably Mac specific so I present you the whole process that produces the bug:

Approach 1: easy_install
a) installing PIL: http://bpaste.net/show/FogXFJtGNzAfvgaAPxEX/
b) using PIL: http://bpaste.net/show/5638/

Approach 2: pip
a) installing PIL: http://bpaste.net/show/5639/
b) using PIL: http://bpaste.net/show/5640/

So, it's not easy_install specific and it's triggerred by symlinks as well as by .pth files.


-- 
Best regards,
?ukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100419/2efeddcf/attachment.html>

From edward at unicornschool.org  Mon Apr 19 19:02:19 2010
From: edward at unicornschool.org (Edward Cannon)
Date: Mon, 19 Apr 2010 10:02:19 -0700
Subject: [Image-SIG] DPI
In-Reply-To: <000401cadd63$25d30e50$71792af0$@com>
References: <000401cadd63$25d30e50$71792af0$@com>
Message-ID: <h2jb986b291004191002lc310bc5ai18ba804807eb8c3d@mail.gmail.com>

I find that the info object often does not have the exact key you are
looking for, many different encoders use slightly different variants, or
don't include it at all. My best advice is to print out the info for several
of your files and look for patterns. Also there are some tools for working
more directly with EXIF data, these might also be useful. Unfortunately this
area is not really standard, so every solution is likely to break down
sometimes.
Edward Cannon

On Fri, Apr 16, 2010 at 5:48 AM, Samuel Moore <blindlemonsam at gmail.com>wrote:

>  I am trying to determine DPI from images. Can anyone help?
>
> I tried:
>
>
>
> img = Image.open(?Hamerkop.jpg?)
>
> img.info[?dpi?]
>
>
>
> but it doesn?t work for all jpegs.
>
>
>
> Python 2.5.1
>
> PIL 1.1.7
>
>
>
> Regards,
>
> Sam
>
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100419/110265d7/attachment.html>

From greeley_00 at yahoo.com  Tue Apr 20 06:55:29 2010
From: greeley_00 at yahoo.com (mark greeley)
Date: Mon, 19 Apr 2010 21:55:29 -0700 (PDT)
Subject: [Image-SIG] problem with PIL 1.1.7 on OSX10.4
Message-ID: <844361.62547.qm@web112514.mail.gq1.yahoo.com>

hi, im trying to get PIL on my mac. i have osx10.4, python 2.6.5, and PIL 1.1.7

I get the error

gcc-4.0 -arch ppc -arch i386 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -DWORDS_BIGENDIAN -IlibImaging -I/Library/Frameworks/Python.framework/Versions/2.6/include -I/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c _imaging.c -o build/temp.macosx-10.3-fat-2.6/_imaging.o
unable to execute gcc-4.0: No such file or directory
error: command 'gcc-4.0' failed with exit status 1

when i run "python setup.py install"

Any suggestions?
thanks
mark


      


From fredrik at pythonware.com  Thu Apr 22 15:14:31 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 22 Apr 2010 15:14:31 +0200
Subject: [Image-SIG] problem with PIL 1.1.7 on OSX10.4
In-Reply-To: <844361.62547.qm@web112514.mail.gq1.yahoo.com>
References: <844361.62547.qm@web112514.mail.gq1.yahoo.com>
Message-ID: <m2s368a5cd51004220614qdff8d3c9m7a7fc86b6a29a33b@mail.gmail.com>

Just guessing, but have you installed Xcode?

</F>

On Tue, Apr 20, 2010 at 6:55 AM, mark greeley <greeley_00 at yahoo.com> wrote:
> hi, im trying to get PIL on my mac. i have osx10.4, python 2.6.5, and PIL 1.1.7
>
> I get the error
>
> gcc-4.0 -arch ppc -arch i386 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -DWORDS_BIGENDIAN -IlibImaging -I/Library/Frameworks/Python.framework/Versions/2.6/include -I/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c _imaging.c -o build/temp.macosx-10.3-fat-2.6/_imaging.o
> unable to execute gcc-4.0: No such file or directory
> error: command 'gcc-4.0' failed with exit status 1
>
> when i run "python setup.py install"
>
> Any suggestions?
> thanks
> mark
>
>
>
>
> _______________________________________________
> Image-SIG maillist ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>

From fredrik at pythonware.com  Thu Apr 22 20:15:59 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 22 Apr 2010 20:15:59 +0200
Subject: [Image-SIG] DPI
In-Reply-To: <000401cadd63$25d30e50$71792af0$@com>
References: <AcrdYyI5fctaAKSPRR26feTupvIPYQ==>
	<000401cadd63$25d30e50$71792af0$@com>
Message-ID: <s2n368a5cd51004221115jb081e4edsaea0eda2c724a4ca@mail.gmail.com>

Resolution info is optional in JPEG files (it's a part of the JFIF
standard, not JPEG itself) and even if present, it may not be
expressed in dots per inch.  PIL only sets the "dpi" field if the
information is there, leaving it to your code to provide a suitable
default value (or behaviour) for your application.  You can do e.g.

    dpi = im.info.get("dpi", (72, 72))

If the JFIF header is present, but the resolution isn't specified as
DPI, you can check if the "jfif_unit" and "jfif_density" fields
contain information useful for your application; their contents are
described here:

http://en.wikipedia.org/wiki/JPEG_File_Interchange_Format#JFIF_segment_format

</F>

On Fri, Apr 16, 2010 at 2:48 PM, Samuel Moore <blindlemonsam at gmail.com> wrote:
> I am trying to determine DPI from images. Can anyone help?
>
> I tried:
>
>
>
> img = Image.open(?Hamerkop.jpg?)
>
> img.info[?dpi?]
>
>
>
> but it doesn?t work for all jpegs.
>
>
>
> Python 2.5.1
>
> PIL 1.1.7
>
>
>
> Regards,
>
> Sam
>
> _______________________________________________
> Image-SIG maillist ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>
>

From smv260985 at gmail.com  Thu Apr 22 19:30:15 2010
From: smv260985 at gmail.com (Subodhini)
Date: Thu, 22 Apr 2010 12:30:15 -0500
Subject: [Image-SIG] [Chicago] An open source AI research project
In-Reply-To: <j2w587457861004170101j384bf1e9g8fdb0b72ad76e88b@mail.gmail.com>
References: <j2w587457861004170101j384bf1e9g8fdb0b72ad76e88b@mail.gmail.com>
Message-ID: <q2uf6e761d71004221030p8dff0a61z690b28025b5abb42@mail.gmail.com>

Hi David,

I am interested in this project. Could you please write in detail about this
project.

I would highly appreciate it.


Regards,
Subodhini
On Sat, Apr 17, 2010 at 3:01 AM, David Zhang <david290 at gmail.com> wrote:

> Hello!
>
> I have started an open source project to develop human-level
> Artificial Intelligence, using Python and Java as programming
> language, OpenCog and OpenWonderland as basement. If you are
> interested in this,or want to know more, please feel free to give me a
> reply.
>
> Thanks!
>
> David Zhang
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago
>



-- 
Subodhini Chopde
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100422/bc963127/attachment.html>

From fredrik at pythonware.com  Thu Apr 22 22:56:51 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 22 Apr 2010 22:56:51 +0200
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <i2s85e6e6d41004130152l8628c15eq92d31841c802ced4@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com> 
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com> 
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com> 
	<201004131216.08289.g.kloss@massey.ac.nz>
	<u2xbc657ead1004130009q57b416dfi6f9f02cea323c985@mail.gmail.com>
	<i2s85e6e6d41004130152l8628c15eq92d31841c802ced4@mail.gmail.com>
Message-ID: <u2h368a5cd51004221356h13035860rfa5e22774e8b076d@mail.gmail.com>

On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
<dan.blacker at googlemail.com> 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>

From fredrik at pythonware.com  Thu Apr 22 22:57:33 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 22 Apr 2010 22:57:33 +0200
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <u2h368a5cd51004221356h13035860rfa5e22774e8b076d@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com> 
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com> 
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com> 
	<201004131216.08289.g.kloss@massey.ac.nz>
	<u2xbc657ead1004130009q57b416dfi6f9f02cea323c985@mail.gmail.com>
	<i2s85e6e6d41004130152l8628c15eq92d31841c802ced4@mail.gmail.com> 
	<u2h368a5cd51004221356h13035860rfa5e22774e8b076d@mail.gmail.com>
Message-ID: <z2x368a5cd51004221357y3926d98bo248cdf5334922673@mail.gmail.com>

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 <fredrik at pythonware.com> wrote:
> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
> <dan.blacker at googlemail.com> 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>
>

From fredrik at pythonware.com  Sun Apr 25 12:59:53 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sun, 25 Apr 2010 12:59:53 +0200
Subject: [Image-SIG] bug in PIL 1.1.7 Image.split()
In-Reply-To: <368a5cd50912101455x1cc47b93k56808c6e587986d2@mail.gmail.com>
References: <ca1c15da0912051156k2807717eqfbbd05b78928691a@mail.gmail.com> 
	<ca1c15da0912051547j6933966do16d1471098d0d4a3@mail.gmail.com> 
	<4B1D4D4F.4040504@noaa.gov> <78824.1260470888@parc.com>
	<368a5cd50912101455x1cc47b93k56808c6e587986d2@mail.gmail.com>
Message-ID: <r2h368a5cd51004250359zd341987eq945227d59bf2c5f@mail.gmail.com>

A patch for this can be found here:

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

</F>

On Fri, Dec 11, 2009 at 12:55 AM, Fredrik Lundh <fredrik at pythonware.com> wrote:
> Good catch. The breakage is caused by a 1.1.7 fix that treats
> single-band images as a special case; unfortunately, the fix checks
> that attribute before actually loading the image... ?I'll provide a
> patch later, but you can of course work around it by adding an
> explicit load to your code.
>
> Thanks /F
>
> On Thu, Dec 10, 2009 at 10:48 AM, Bill Janssen <janssen at parc.com> wrote:
>> Just stumbled over this bug. ?Shouldn't split() do a load() first? ?This
>> used to work in 1.1.6.
>>
>> Bill
>>
>> % python
>> Python 2.5.1 (r251:54863, Feb ?6 2009, 19:02:12)
>> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import Image
>>>>> Image.VERSION
>> '1.1.7'
>>>>> im = Image.open("/u/extensions/vCardParser/vcardimage.png")
>>>>> im.mode
>> 'RGBA'
>>>>> im.size
>> (200, 138)
>>>>> im.split()
>> Traceback (most recent call last):
>> ?File "<stdin>", line 1, in <module>
>> ?File "/Library/Python/2.5/site-packages/PIL/Image.py", line 1497, in split
>> ? ?if self.im.bands == 1:
>> AttributeError: 'NoneType' object has no attribute 'bands'
>>>>>
>> _______________________________________________
>> Image-SIG maillist ?- ?Image-SIG at python.org
>> http://mail.python.org/mailman/listinfo/image-sig
>>
>

From fredrik at pythonware.com  Sun Apr 25 13:07:05 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sun, 25 Apr 2010 13:07:05 +0200
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <z2x368a5cd51004221357y3926d98bo248cdf5334922673@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com> 
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com> 
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com> 
	<201004131216.08289.g.kloss@massey.ac.nz>
	<u2xbc657ead1004130009q57b416dfi6f9f02cea323c985@mail.gmail.com>
	<i2s85e6e6d41004130152l8628c15eq92d31841c802ced4@mail.gmail.com> 
	<u2h368a5cd51004221356h13035860rfa5e22774e8b076d@mail.gmail.com> 
	<z2x368a5cd51004221357y3926d98bo248cdf5334922673@mail.gmail.com>
Message-ID: <i2q368a5cd51004250407g3b32d332kcd8281e57246d1f3@mail.gmail.com>

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 <fredrik at pythonware.com> 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 <fredrik at pythonware.com> wrote:
>> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
>> <dan.blacker at googlemail.com> 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>
>>
>

From fredrik at pythonware.com  Sun Apr 25 14:48:34 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sun, 25 Apr 2010 14:48:34 +0200
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <i2q368a5cd51004250407g3b32d332kcd8281e57246d1f3@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com> 
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com> 
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com> 
	<201004131216.08289.g.kloss@massey.ac.nz>
	<u2xbc657ead1004130009q57b416dfi6f9f02cea323c985@mail.gmail.com>
	<i2s85e6e6d41004130152l8628c15eq92d31841c802ced4@mail.gmail.com> 
	<u2h368a5cd51004221356h13035860rfa5e22774e8b076d@mail.gmail.com> 
	<z2x368a5cd51004221357y3926d98bo248cdf5334922673@mail.gmail.com> 
	<i2q368a5cd51004250407g3b32d332kcd8281e57246d1f3@mail.gmail.com>
Message-ID: <y2w368a5cd51004250548ue7333bc8g666edcf4aa381e03@mail.gmail.com>

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 <fredrik at pythonware.com> 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 <fredrik at pythonware.com> 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 <fredrik at pythonware.com> wrote:
>>> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
>>> <dan.blacker at googlemail.com> 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>
>>>
>>
>

From fredrik at pythonware.com  Sun Apr 25 15:06:45 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sun, 25 Apr 2010 15:06:45 +0200
Subject: [Image-SIG] Radius bug with GaussianBlur
In-Reply-To: <2078a7ad1003011249n1026bbap24f4dd2988b711e5@mail.gmail.com>
References: <b53becb31002220738t5dc3d2f2p6359499f0d7251d8@mail.gmail.com> 
	<2078a7ad1003011249n1026bbap24f4dd2988b711e5@mail.gmail.com>
Message-ID: <u2v368a5cd51004250606sed920a4dm9c4f58b706e05250@mail.gmail.com>

On Mon, Mar 1, 2010 at 10:49 PM, Stani <spe.stani.be at gmail.com> wrote:
> Strange indeed. The same is true for UnsharpMask:

More silly than strange, I'd say -- looks like a
cut-and-paste-propagated typo that weren't caught by the (rather
shallow) filter tests.  Trivial patch here:

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

Thanks /F

> class UnsharpMask(Filter):
> ? ?name = "UnsharpMask"
>
> ? ?def __init__(self, radius=2, percent=150, threshold=3):
> ? ? ? ?self.radius = 2
> ? ? ? ?self.percent = percent
> ? ? ? ?self.threshold = threshold
> ? ?def filter(self, image):
> ? ? ? ?return image.unsharp_mask(self.radius, self.percent, self.threshold)
>
> http://svn.effbot.org/public/tags/pil-1.1.7a1-20090317/PIL/ImageFilter.py
>
> On Mon, Feb 22, 2010 at 4:38 PM, Tiberio Uricchio <uricchio at gmail.com> wrote:
>> Hi,
>> i just wanted to report a simple bug in ImageFilter.GaussianBlur:
>>
>> class GaussianBlur(Filter):
>> ? ?name = "GaussianBlur"
>>
>> ? ?def __init__(self, radius=2):
>> ? ? ? ?self.radius = 2
>>
>> ? ?def filter(self, image):
>> ? ? ? ?return image.gaussian_blur(self.radius)
>>
>> As you can see, radius is always fixed at value 2 instead of using the
>> argument value.
>>
>> Tiberio
>> _______________________________________________
>> Image-SIG maillist ?- ?Image-SIG at python.org
>> http://mail.python.org/mailman/listinfo/image-sig
>>
>
>
>
> --
> Phatch Photo Batch Processor - http://photobatch.stani.be
> SPE Python IDE - http://pythonide.stani.be
> _______________________________________________
> Image-SIG maillist ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>

From justin at justinzane.com  Fri Apr 23 08:19:16 2010
From: justin at justinzane.com (Justin Chudgar)
Date: Thu, 22 Apr 2010 23:19:16 -0700
Subject: [Image-SIG] PIL and NumPy
Message-ID: <201004222319.17311.justin@justinzane.com>

I'm trying to find some documentation about the methods used to convert Image 
objects to arrays and back. The following methods seem to work

im = Image.open('monkey.jpg')
ar = numpy.asarray(im)
...
outim = Image.fromarray(outar)
outim.save('redmonkey.jpg')

however, I get gibberish for an output image even if I attempt to write my 
original arrays back. Can someone kindly point me to the appropriate 
documentation on this so I can RTFM. 

Thanks.
-- 


Justin Chudgar

http://www.justinzane.com/ 
5040 Saddlehorn Rd, Weed, CA 96094
530-938-9692



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100422/56688925/attachment-0001.html>

From yury at shurup.com  Sun Apr 25 16:57:19 2010
From: yury at shurup.com (Yury V. Zaytsev)
Date: Sun, 25 Apr 2010 16:57:19 +0200
Subject: [Image-SIG] PIL and NumPy
In-Reply-To: <201004222319.17311.justin@justinzane.com>
References: <201004222319.17311.justin@justinzane.com>
Message-ID: <1272207439.7432.14.camel@mypride>

On Thu, 2010-04-22 at 23:19 -0700, Justin Chudgar wrote:

> however, I get gibberish for an output image even if I attempt to
> write my original arrays back. Can someone kindly point me to the
> appropriate documentation on this so I can RTFM. 

What do you mean by gibberish? Maybe you need to transpose X and Y, if
so this is might be a PIL bug.
 
-- 
Sincerely yours,
Yury V. Zaytsev


From dan.blacker at googlemail.com  Sun Apr 25 17:53:22 2010
From: dan.blacker at googlemail.com (Dan Blacker)
Date: Sun, 25 Apr 2010 16:53:22 +0100
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <y2w368a5cd51004250548ue7333bc8g666edcf4aa381e03@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com>
	<k2t85e6e6d41004120133z88a6f15fn999ce893d8bb8cc6@mail.gmail.com>
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com>
	<201004131216.08289.g.kloss@massey.ac.nz>
	<u2xbc657ead1004130009q57b416dfi6f9f02cea323c985@mail.gmail.com>
	<i2s85e6e6d41004130152l8628c15eq92d31841c802ced4@mail.gmail.com>
	<u2h368a5cd51004221356h13035860rfa5e22774e8b076d@mail.gmail.com>
	<z2x368a5cd51004221357y3926d98bo248cdf5334922673@mail.gmail.com>
	<i2q368a5cd51004250407g3b32d332kcd8281e57246d1f3@mail.gmail.com>
	<y2w368a5cd51004250548ue7333bc8g666edcf4aa381e03@mail.gmail.com>
Message-ID: <w2n85e6e6d41004250853oac455625hdefc118f434971b8@mail.gmail.com>

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 <fredrik at pythonware.com> 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 <fredrik at pythonware.com>
> 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 <fredrik at pythonware.com>
> 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 <fredrik at pythonware.com>
> wrote:
> >>> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
> >>> <dan.blacker at googlemail.com> 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>
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100425/1b34be94/attachment.html>

From fredrik at pythonware.com  Sun Apr 25 20:04:07 2010
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sun, 25 Apr 2010 20:04:07 +0200
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <w2n85e6e6d41004250853oac455625hdefc118f434971b8@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com> 
	<u2sbc657ead1004120432xb11a0ce6g6fe0784d0d96c27c@mail.gmail.com> 
	<201004131216.08289.g.kloss@massey.ac.nz>
	<u2xbc657ead1004130009q57b416dfi6f9f02cea323c985@mail.gmail.com>
	<i2s85e6e6d41004130152l8628c15eq92d31841c802ced4@mail.gmail.com> 
	<u2h368a5cd51004221356h13035860rfa5e22774e8b076d@mail.gmail.com> 
	<z2x368a5cd51004221357y3926d98bo248cdf5334922673@mail.gmail.com> 
	<i2q368a5cd51004250407g3b32d332kcd8281e57246d1f3@mail.gmail.com> 
	<y2w368a5cd51004250548ue7333bc8g666edcf4aa381e03@mail.gmail.com> 
	<w2n85e6e6d41004250853oac455625hdefc118f434971b8@mail.gmail.com>
Message-ID: <g2t368a5cd51004251104u78cb0a72yfeb9d64726c5a355@mail.gmail.com>

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 <dan.blacker at googlemail.com>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 <fredrik at pythonware.com> 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 <fredrik at pythonware.com>
>> 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 <fredrik at pythonware.com>
>> 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 <
>> fredrik at pythonware.com> wrote:
>> >>> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
>> >>> <dan.blacker at googlemail.com> 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>
>> >>>
>> >>
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100425/a7c77949/attachment-0001.html>

From dan.blacker at googlemail.com  Mon Apr 26 10:41:55 2010
From: dan.blacker at googlemail.com (Dan Blacker)
Date: Mon, 26 Apr 2010 09:41:55 +0100
Subject: [Image-SIG] python PIL 16-bit tiff files
In-Reply-To: <g2t368a5cd51004251104u78cb0a72yfeb9d64726c5a355@mail.gmail.com>
References: <n2p85e6e6d41004100908ubf4e86a4w5ed3adf4d08c1af5@mail.gmail.com>
	<201004131216.08289.g.kloss@massey.ac.nz>
	<u2xbc657ead1004130009q57b416dfi6f9f02cea323c985@mail.gmail.com>
	<i2s85e6e6d41004130152l8628c15eq92d31841c802ced4@mail.gmail.com>
	<u2h368a5cd51004221356h13035860rfa5e22774e8b076d@mail.gmail.com>
	<z2x368a5cd51004221357y3926d98bo248cdf5334922673@mail.gmail.com>
	<i2q368a5cd51004250407g3b32d332kcd8281e57246d1f3@mail.gmail.com>
	<y2w368a5cd51004250548ue7333bc8g666edcf4aa381e03@mail.gmail.com>
	<w2n85e6e6d41004250853oac455625hdefc118f434971b8@mail.gmail.com>
	<g2t368a5cd51004251104u78cb0a72yfeb9d64726c5a355@mail.gmail.com>
Message-ID: <s2n85e6e6d41004260141r5d738a3cqa36290efb1927987@mail.gmail.com>

I'm a bit unfamiliar with updating / installing things in Linux.

I downloaded the latest source for imaging (which I assume contains the
latest 'libImaging/Unpack.c') from here:

$ hg clone http://hg.effbot.org/pil-2009-raclette

and ran the setup.py install over my existing version.

Have I done this correctly, or am I missing something to rebuild the imaging
module?

Thanks again




On 25 April 2010 19:04, Fredrik Lundh <fredrik at pythonware.com> wrote:

> 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 <dan.blacker at googlemail.com>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 <fredrik at pythonware.com> 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 <fredrik at pythonware.com>
>>> 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 <
>>> fredrik at pythonware.com> 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 <
>>> fredrik at pythonware.com> wrote:
>>> >>> On Tue, Apr 13, 2010 at 10:52 AM, Dan Blacker
>>> >>> <dan.blacker at googlemail.com> 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>
>>> >>>
>>> >>
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20100426/966b7f52/attachment.html>

From pyprog05 at gmail.com  Wed Apr 28 23:59:47 2010
From: pyprog05 at gmail.com (PyProg PyProg)
Date: Wed, 28 Apr 2010 23:59:47 +0200
Subject: [Image-SIG] Image perspective with PIL
Message-ID: <k2ob763fa191004281459t3706e2bdkabb7a4fbb583ce6e@mail.gmail.com>

Hello,

I would like to apply an image perspective.

The syntax of PIL in this regard seems to be:

im.transform (self, size, PERSPECTIVE, data = None, resample = 0, fill = 1)

I want to know exactly what to include in data.

Can you give me an example ?.

Thank you in advance.

a +

-- 
http://ekd.tuxfamily.org
http://ekdm.wordpress.com
http://lprod.org/wiki/doku.php/video:encodage:avchd_converter