[Python-Dev] Fixes for imageop module (original) (raw)

Sjoerd Mullender sjoerd at acm.org
Sat Dec 27 13:12:50 EST 2003

Guido van Rossum wrote:

[Sjoerd]

I have some fixes for the imageop module to make it work on systems with a different byte-order than IRIX (e.g. Linux). Shall I check them in or is it not worth it for such an old module? Anything else that needs to be changed when I check this in? The fixes of course will result in different results on Linux than before, so that's the main reason for asking. Guido van Rossum wrote: I don't see imageop in the list of deprecated modules in PEP 4, and apparently you are still using it, so as long as you don't mind being potentially the sole maintainer and user, I don't mind these being in the distribution.

What do you mean by different results on Linux? Was this module previously doing something bogus there? [Sjoerd] The main difference is: *************** *** 570,577 **** r = (r<<5) | (r<<3) | (r>>1); g = (g<<5) | (g<<3) | (g>>1); b = (b<<6) | (b<<4) | (b<<2) | b;_ _! nvalue = r | (g<<8) | (b<<16);_ _! *ncp++ = nvalue;_ _}_ _return rv;_ _}_ _--- 560,569 ----_ _r = (r<<5) | (r<<3) | (r>>1); g = (g<<5) | (g<<3) | (g>>1); b = (b<<6) | (b<<4) | (b<<2) | b; ! *ncp++ = 0; ! *ncp++ = b; ! *ncp++ = g; ! *ncp++ = r; } return rv; } where the old ncp is an "PyUInt32 *" and the new ncp is an "unsigned char *". This results in different byte ordering on a little endian machine such as Intel. Hm. Anybody who uses the imageop module currently on Linux will find their programs broken. The strings manipulated by imageop all end up either being written to a file or handed to some drawing code, and changing the byte order would definitely break things!

That's why I asked.

So I don't think this is an acceptable change. I take it that for IRIX, the byte order implied by the old code is simply wrong? Maybe the module can be given a global (shrudder?) byte order setting that you can change but that defaults to the old setting?

The problem is, the documentation says: "This is the same format as used by gl.lrectwrite() and the imgfile module." This implies the byte order that you get on the SGI which is opposite of what you get on Intel. The code produced the correct results on the SGI, but not on Intel.

(By the way, I'm away from computers for a week starting tomorrow extremely early.)

-- Sjoerd Mullender <sjoerd at acm.org>

More information about the Python-Dev mailing list