Fixes for imageop module

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. -- Sjoerd Mullender <sjoerd@acm.org>

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? --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
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 "Py_UInt32 *" and the new ncp is an "unsigned char *". This results in different byte ordering on a little endian machine such as Intel. -- Sjoerd Mullender <sjoerd@acm.org>

[Sjoerd]
[Sjoerd]
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! 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? --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
That's why I asked.
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@acm.org>

Your fix would be okay if until now it was *only* used on IRIX with gl.lrectwrite() and/or the imgfile module. But how can we prove that?
(By the way, I'm away from computers for a week starting tomorrow extremely early.)
It's okay to way a week before making a decision. --Guido van Rossum (home page: http://www.python.org/~guido/)

I suggest that you implement a way to change the endianness of the operations. A global flag in the module is fine. It should default to the historic behavior, and there should be a call to switch it to the behavior you want. --Guido van Rossum (home page: http://www.python.org/~guido/)

I submitted a patch (874358) to SourceForge.
Great, check it in! --Guido van Rossum (home page: http://www.python.org/~guido/)

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? --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
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 "Py_UInt32 *" and the new ncp is an "unsigned char *". This results in different byte ordering on a little endian machine such as Intel. -- Sjoerd Mullender <sjoerd@acm.org>

[Sjoerd]
[Sjoerd]
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! 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? --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
That's why I asked.
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@acm.org>

Your fix would be okay if until now it was *only* used on IRIX with gl.lrectwrite() and/or the imgfile module. But how can we prove that?
(By the way, I'm away from computers for a week starting tomorrow extremely early.)
It's okay to way a week before making a decision. --Guido van Rossum (home page: http://www.python.org/~guido/)

I suggest that you implement a way to change the endianness of the operations. A global flag in the module is fine. It should default to the historic behavior, and there should be a call to switch it to the behavior you want. --Guido van Rossum (home page: http://www.python.org/~guido/)

I submitted a patch (874358) to SourceForge.
Great, check it in! --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (2)
-
Guido van Rossum
-
Sjoerd Mullender