Imagedata row order

[Ben Rubinstein]

On 25/7/06 16:03, Rob Cozens wrote:
> Dar, Jacque, et al:
> 
> * 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].

As a point of information, RLE almost certainly stands for "Run Length 
Encoded", a very simple form of compression that works well for synthetic 
images in small colour spaces.  Essentially, rather than saying "white, white, 
white, black, white", RLE says "3 x white, 1 x black, 1x white".  (Fax 
transmissions are run-length encoded, because they are - or were - typically 
lots of white with small amounts of black).

My understanding is that the imageData of an image should bear no relation to 
the compression of the source file, nor to the internal format of the bitmap. 
  That is, Revolution reads an image in from files in various formats.  It 
stores the image in one way or another, represented by the paintCompression 
property.  When Rev needs to render the image, it expands it into a bitmap - 
or what the Mac toolbox knows as a pixmap - with, probably, four bytes for 
every pixel.

Regardless of any of the above, when you deal with imageData - either asking 
for it or setting it - the image is rendered into a pixmap with four bytes per 
pixel, and that's the data you get.

The text of the image, on the other hand, is I believe the internal format in 
which the image is stored - ie if the paintCompression of an image is 'gif', 
you should be able to decode the 'text' according to the gif standard.


> *  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.]

As above, I don't believe that this presumption is correct.  I don't think 
there's ever an example when the text and imageData are identical - by definition.

> *  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.]
> 
> *  Rev Dictionary, "To take advantage of the characteristics of a 
> particular format or to transfer picture data between objects, use the 
> image content."  [Emphasis mine.]
> 
> So Jacque notes that "set the imageData of image id 12345 to 
> my32x32RLEString" should be functionally equivalent to "set the text of 
> image id 12345 to my32x32RLEString", and Dar suggests people work with 
> imageData because it's easier to decipher and manipulate bit-by-bit than 
> other Rev image formats.
> 
> 1.  Setting the text of an image automatically resets image dimensions 
> (among other properties); setting the imageData of an image does NOT 
> adjust dimensions and WILL cause image distortion if the imageData does 
> not contain exactly the number of pixels needed to fill the screen space 
> occupied by the image.
> 
> 2.  Changing image content via resetting the imageData property ONLY 
> works for data in rle format:

I don't think that's correct: I believe you can set the imageData of any image 
(bearing in mind the caveat that Rev doesn't respond gracefully if it's the 
wrong length, ie not 4 * width * height) - regardless of whether the image was 
opened from a JPEG or a GIF, regardless of whether it's stored as PNG or RLE.

> 
>     get URL "binfile:/Disk/Folder/image.jpg"
>     set the imageData of image id 12345 to it
> 
> will not display(or load?) the image correctly.  So I feel it's bad form 
> to post solutions that change image content by changing the imageData; 
> since it only works for one of the eight image formats Rev supports and 
> does not update all the image properties that are touched by "set the 
> text of image id 12345 to it".

I agree the above code will not work; that's because the jpeg format is not 
the right format for imagedata.  There's only format for imageData, and it's 
not the one found in JPEG files (or gif files, PNG, BMP, PICT or any other...).

> 3.  None of this means one cannot create and manipulate images rle 
> format, it just means once one has created the image string, one should 
> set the text of the image to it or put it into the image, rather than 
> setting the imageData of the image to it.

It may well be possible to set an image using the text, but that's certainly 
not to say it's a bad idea to do it using the imageData.  In general I'd 
prefer the latter unless I'd obtained the image data already in PNG etc 
format.  As for Rev's RLE format, as far as I know there's no documentation of 
it, so I'd be nervous about using that.

Meanwhile on another point that's been brought up, I am concerned by the 
suggestion that the order of interpretation of the imageData is different on 
different platforms. I've certainly used it with invariant order in the past. 
If in fact the order is platform-dependant in 2.7that's contrary to the docs, 
and a bug.

   Ben Rubinstein               |  Email: benr_mc at cogapp.com
   Cognitive Applications Ltd   |  Phone: +44 (0)1273-821600
   http://www.cogapp.com        |  Fax  : +44 (0)1273-728866