Thoughts and facts about "text of image", "imagedata", and "paintcompression"

[Wilhelm Sanke]

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 
docs:

"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 
size.

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 
image.

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 
processing.

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?" .

.
Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>