Thoughts and facts about "text of image", "imagedata", and "paintcompression"
sanke at hrz.uni-kassel.de
Thu Jul 1 08:08:22 EDT 2010
J. Landman Gay and Scott Rossi - in the recent thread "snapshot and
background problems" - have discussed and informed us about the
usefulness of the "text of image" property, the retaining of all binary
data and the easy scalability.
About "imagedata" Jacqueline writes:
The imagedata is
basically just a screen shot and if you set the imagedata of an image
object, what you end up with is just a bitmap. All other binary info is
lost, including channel data. If you set the imagedata of an image
object that isn't exactly the same size as the original screen shot, the
image will corrupt and become unrecognizable.
While most of the above is correct, some clarifications are in order here:
If you *change* the imagedata of an image that has transparency (an
alphamask) this can be done in a way where the transparent parts of the
image are *not* affected! This is the idea behind the structure to have
separate imagedata and alphadata - and for that matter maskdata.
Moreover the "imagedata" are much more than just a "screenshot", but a
very important part of an image that can be creatively modified by all
sorts of filters or generally "manipulating" various aspects of images
(hues, saturation, exchanging colors, simplifying color maps, gamma
corrections, overlays, seamless tiles, structural changes like creating
patterns from selected parts of an image etc.etc.) similar to
image-processing features to be found in other specific image tools
(like Photoshop, Gimp; Lua color tools etc.).
Such manipulations are not possible with "text of image" data.
To conclude with one of the sentences of Jacqueline here: "They're
different properties for different purposes"--
Now there are situations where the three properties (text of image,
imagedata, paintcompression) may influence each other and can lead to
unexpected results - a fact you should bear in mind and observe when you
are developing image tools in Rev.
With "paintcompression" I here mean the "global" paintcompression which
is different from the paintcompression of an individual image. From the
"The paintCompression is one of the following: "png", "jpeg", "gif", or
"rle". By default, the *global* paintCompression property is set to
"rle" in standalones and "png" in the development environment."
Another clarification: The default global paintcompression of the common
Metacard/Revolution engine is set to RLE. The Rev IDE changes this to
PNG, and then back to RLE for standalones. The Metacard IDE leaves the
paintcompression setting of the engine untouched.
Let's take an example of mutual influence of these properties:
Image Tool X uses two images in its basic structure: One "display" image
that is of fixed size and another (hidden) "original" image of variable
Images are imported into image "original" where the imagedata are then
being manipulated by filters and other scripts. The original image and
its changed states are immediately reflected in the "display" image via
setting the text-of-image of the display image to that of the original
In a cooperative project we suddenly found that the "display" image
became empty when changing the imagedata of image "original". The cause
was that the global paintcompression had been set to RLE when this
occured, meaning: If the global paintcompression is set to RLE, after
manipulating the imagedata of an image it is not possible to tranfer the
text-of-image of the changed image to another image.
You have to pay attention to this when you develop in the Rev IDE. What
may work in the IDE will possibly not work in a standalone as the
paintcompression there is set back to RLE.
Changing the global paitcompression to JPEG or PNG solved the problem
and let the "display" image reappear.
Some other issue in this context I have repeatedly brought up during the
last years on this list and demonstrated in test stacks.
Global paintcompression substantially influences the speed of imagedata
processing and retrieval. RLE is fastest, JPEG somewhat slower, and PNG
on the average about 33% slower than RLE, the relative differences
measured with the same image and image-processing script. Size of image
and the complexity of the script are of course *additional* factors that
influence the speed - as is also the version of the engine: From my
tests I see that the fastest engine ever for image processing was Rev
engine 2.6.1 (identical to Metacard 2.6.6). Subsequent engines were 20
to 30% slower, the newer engines have again improved very much.
The speed difference caused by global paintcompression alone is
especially spectacular when retrieving the imagedata stored in a custom
property and resetting an image to these data: With paintcompression set
to PNG this can be up to 12 (twelve) times slower than with RLE.
If you embed C- or Lua-externals for imagedata processing they are of
course surprisingly faster, but the basic relative speed difference
caused by paintcompression remains, as the imagedata manipulated by the
external must after that be reset in the Revscript part.--
Generally, imagedata processing in Revolution compared to most image
tools is rather slow, as it was not developed with a focus on image
Maybe in the medium future improvements for image processing in
Revolution could be achieved, given the present urgent need to work on
other areas (including fixing bugs) on the backgound of the budget and
personal resources of the Rev team.
A lot could be achieved by adding externals for image processing to Rev.
I had given this angle a thought in my post of March 9, 2010, to this list
"Language comparisons: "Lua" - simpler and faster than RevTalk?" .
More information about the Use-livecode