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