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: [EMAIL PROTECTED]
Cognitive Applications Ltd | Phone: +44 (0)1273-821600
http://www.cogapp.com | Fax : +44 (0)1273-728866
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
