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

[Jerry Daniels]

Wilhelm, very VERY nicely done! 

(My grandpa's Christian name was same as yours. He was from Ulm.) 

Best,

Jerry Daniels

Join the Rodeo discussion:
http://rodeoapps.com/rodeo-discuss-among-yourselves

On Jul 1, 2010, at 7:08 AM, Wilhelm Sanke <sanke at hrz.uni-kassel.de> wrote:

> 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>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution