Re: 16-bit TIFF decoding and endianness problem

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

Re: 16-bit TIFF decoding and endianness problem

Andrew-269
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  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: 16-bit TIFF decoding and endianness problem

Sebastian Haase-3
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 <[hidden email]> 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  -  [hidden email]
> http://mail.python.org/mailman/listinfo/image-sig
>
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

AccessInit: hash collision: 3 for both 1 and 1

jalopyuser
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  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: AccessInit: hash collision: 3 for both 1 and 1

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

Re: AccessInit: hash collision: 3 for both 1 and 1

jalopyuser
Fredrik Lundh <[hidden email]> 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 <[hidden email]> 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  -  [hidden email]
> > http://mail.python.org/mailman/listinfo/image-sig
> >
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: AccessInit: hash collision: 3 for both 1 and 1

Fredrik Lundh
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 <[hidden email]> wrote:

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

Re: AccessInit: hash collision: 3 for both 1 and 1

Fredrik Lundh
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 <[hidden email]> 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 <[hidden email]> wrote:
>> Fredrik Lundh <[hidden email]> 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 <[hidden email]> 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  -  [hidden email]
>>> > http://mail.python.org/mailman/listinfo/image-sig
>>> >
>>
>
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: AccessInit: hash collision: 3 for both 1 and 1

jalopyuser
In reply to this post by Fredrik Lundh
Fredrik Lundh <[hidden email]> 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 <[hidden email]> wrote:
> > Fredrik Lundh <[hidden email]> 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 <[hidden email]> 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  -  [hidden email]
> >> > http://mail.python.org/mailman/listinfo/image-sig
> >> >
> >
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: AccessInit: hash collision: 3 for both 1 and 1

jalopyuser
In reply to this post by Fredrik Lundh
Fredrik Lundh <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
> >> Fredrik Lundh <[hidden email]> 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 <[hidden email]> 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  -  [hidden email]
> >>> > http://mail.python.org/mailman/listinfo/image-sig
> >>> >
> >>
> >
_______________________________________________
Image-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/image-sig
Reply | Threaded
Open this post in threaded view
|

Re: AccessInit: hash collision: 3 for both 1 and 1

Łukasz Langa-2
In reply to this post by jalopyuser
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


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

Re: AccessInit: hash collision: 3 for both 1 and 1

Fredrik Lundh
2010/4/18 Łukasz Langa <[hidden email]>:

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

Re: AccessInit: hash collision: 3 for both 1 and 1

Łukasz Langa-2

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

2010/4/18 Łukasz Langa <[hidden email]>:
$ 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

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

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


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