[Python-Dev] Fixes for imageop module

[Sjoerd Mullender]

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 "Py_UInt32 *" 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>