Imagedata row order

Rob Cozens rcozens at pon.net
Tue Jul 25 14:35:49 EDT 2006


Jeanne:

>At 8:03 AM -0700 7/25/2006, Rob Cozens wrote:
>>* Rev. Dictionary:  "Revolution supports GIF, JPEG, PNG, PICT, BMP, 
>>PBM/PGM/PPM, and XBM/XPM/XWD formats, as well as its own internal 
>>format".  My presumption is (untested)  the "internal format", 
>>designated as "rle" in the image's paintCompression property, is 
>>the format used for imageData  [4 bytes per pixel:  null, red, 
>>green, blue].
>
>No. It's run-length-encoded. Just as well, since the text property 
>is what's stored on disk, and a 32-bit image with no compression 
>whatever would take up a ton of room. Take a look at the length of 
>the text versus the length of the imageData of a typical image 
>object.

The text property is stored on disk?  Isn't that only if the image is 
referenced instead of imported?

>
>(Why would you assume that these are the same?)

Here's my thinking:

1.  I create a string of characters, 4 bytes per pixel  in imageData format .

2.  I set the imageData of an image to my string

3.  In what format is the image's text, if not rle?  GIF, JPEG, PNG, 
PICT, BMP, PBM/PGM/PPM, or XBM/XPM/XWD?  Perhaps rle compresses the 
data to 3 bytes per pixel by stripping the nulls?

4.  What happens if I "put" my imageData-formatted string into an 
image?  Will the image not display correctly?  Does it throw an 
error?  Is the string reformatted before being placed in the text 
property?


>>*  Rev Dictionary: "Because most picture formats include 
>>compression, the content of an image is normally smaller than its 
>>imageData property."  My presumption is (untested) that if an image 
>>has never been resized since created in rle format, the image's 
>>text & imageData properties will be identical. [ I would also note 
>>the Dictionary is likely to be incorrect  if the image is displayed 
>>at less than full size.]
>
>This is never the case. There is no situation in which the text and 
>imageData properties are the same; they're in completely different 
>formats.

Once again, question 4 above.  Other than saving and reusing the text 
of a rle-formatted image, how would one put an rle-formatted string 
into an image?

>
>>*  Rev Dictionary: "To manipulate each pixel (for example, to 
>>brighten the image or remove the red channel), to examine the 
>>actual screen appearance of the image, or to work with the picture 
>>data in a format-independent way, use the imageData property."  I 
>>think this should read "use the rle format" instead of "use the 
>>imageData property."  [Though one could reference the imageData 
>>property to convert images in other formats to rle.]
>
>No. It is possible to manipulate data by starting with the formatted 
>text property of the image, of course - but the easiest way to do 
>this is to write a routine that expands that text property so that 
>each channel of each pixel is represented by a separate byte, and 
>place that data in a variable to be worked with. Since what I've 
>just described is the imageData property of the image, it seems 
>considerably easier to use that instead of spending time 
>reconverting the text picture data into that format.

>If I had meant "use the text property of an image in RLE format" 
>instead of "use the imageData property", that's what I would have 
>written.

Perhaps we are approaching "use" from different viewpoints; but then 
again it may all boil down to my misconception of what happens if I 
set the text of an image to an imageData-formatted string.  If you 
use "use" in the sense of "take the imageData as a starting point for 
your modifications", you'll get no argument from me.  And if setting 
the text of an image to an imageData-formatted string throws an 
error, I'm flat out wrong.  But if it doesn't throw an error, what 
does happen?


-- 

Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)


More information about the use-livecode mailing list