Interesting discussion. Couple of things: The text of an image is not the imageData of an image. I believe it IS the binary data for the image as imported. I assume this is because compressed images (JPG,PNG,GIF) when imported, do not bloat a stack, and only become uncompressed when viewed on a card.
To test just import an image then put into msg: put the imagedata of img 1 = the text of img 1 and you will see 'false' returned. Next, the big endian, little endian problem was apparent a few versions ago. In fact, in ButtonGadget I have code which reads: if the platform is "MacOS" or version()>"2.4.2" then repeat for timagedatalength times put tPos + 4 into tPos put binaryEncode("CCCC",0,R,G,B) after newImageData end repeat else repeat for timagedatalength times put tPos + 4 into tPos put binaryEncode("CCCC",B,G,R,0) after newImageData end repeat end if which leads me to the assumption the Rev engine changed the big endian, little endian byte order sway after engine version 2.4.2. HTH, Chipp _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution