From: John H. <jdh...@ac...> - 2005-01-31 15:34:50
|
>>>>> "John" == John Hunter <jdh...@ac...> writes: John> * The only explanation I can think of for why the colors John> are wrong is that qt has a different byte order for images John> than you are getting from agg (is could it be bgra instead John> of rgba, or that something is wrong with the endianess...) John> If you need a different byte ordering /pixel format, I can John> provide the required method in the agg backend. I note that John> the saved figures *do* have the right color scheme, which John> supports this idea. Another clue that endianess is playing a role here is that the colors are dramatically different on OSX (which I tested yesterday) ans linux which I tested today. But I think it's more than an endian problem, because the colors are wrong on both platforms. On linux, it looks like the endianess is right, but it's an rgb versus bgr thing, since the colors are backwards on from pylab import * subplot(211) plot([1,2,3], color='red') subplot(212) plot([1,2,3], color='blue') show() On OSX, it looks like the endianess is wrong because the colors are really off... Also, I took a quick at the qimage class docs at http://doc.trolltech.com/3.3/qimage.html and saw It is one of the two classes Qt provides for dealing with images, the other being QPixmap. QImage is designed and optimized for I/O and for direct pixel access/manipulation. QPixmap is designed and optimized for drawing. There are (slow) functions to convert between QImage and QPixmap: QPixmap::convertToImage() and QPixmap::convertFromImage(). Does this suggest that QPixmap might be more appropriate / faster since you don't need to do the individual pixel manipulation provided by QImage (spoken as a total qt newbie, so please forgive any stupidities on my part...) An unrelated observation regarding event handling: the qt backend is not connecting to mouse motion unless a pan/zoom button is pressed and released, eg coords_demo.py does not work properly. Cheers! JDH |