Re: Another MC-Rev anomaly: "text of image" property

[Wilhelm Sanke]

On Tue, 07 Nov 2006, Chipp Walters wrote:

Hi Wilhelm,

Then, if I am correct, setting the global paintcompression to RLE then 
'touching' a PNG image (getting and setting both the imageData and 
alphaData) will now set the image to RLE instead of the original PNG. Is 
this your understanding as well?


Yes.

===

Another interesting difference between imagedata and text of image:

As we know, getting and setting the imagedata will result in a new 
formattedwidth and - height defined by the size of the current rect of 
the image, meaning at least two things:


- if you change the size of the rect after you have retrieved the 
imagedata, then when you set the resized image to the retrieved 
imagedata you will get a distorted image at best,


- if you get and set the imagedata without changing the rect, this image 
size is now defined as having the optimal quality, i.e. when you now 
change the rect you will loose quality when you enlarge the image.


This is apparently not the case with text-of-image. The retrieved 
text-of-image data will fit into any rect without loss of quality, 
unless of course you expand the image beyond its original size 
("original" at the time the image was imported).


Regards,

Wilhelm Sanke


___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[Chipp Walters]

For those of you interested, here's a test stack which I've created which should demonstrate the anomally I previously mentioned regarding PNG gamma and the other formats.go URL "
http://www.gadgetplugins.com/chippstuff/testGamma.rev"I haven't tested it on a Mac yet, but the PNG image should be a different color than the JPG and GIF images on Macs. On PC's they should all look alike.
Let me know if this isn't the case.thanks,Chipp
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[Chipp Walters]

On 11/7/06, Tereza Snyder <[EMAIL PROTECTED]> wrote:
BUT colors in images fail to match the backcolors of objects that they did match on the Mac.)Exactly the problem. The images, while the same colors when created, do not translate to the same colors on the  'other' platform. The GIF and JPG images, AFAIK, have no gamma setting and thus are not 'corrected' by Rev for the platform. The PNG's on the other hand, are corrected. This subtle effect can (and has) caused havok for me in interface design, where one would like to be able to mix PNG, JPG and GIF.

___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[Tereza Snyder]

On Nov 7, 2006, at 2:11 PM, Chipp Walters wrote:Even though Fireworks can create images in native Window Gamma, does it really pass the test I outlined above? I would be very surprised if it did.I assume this is the test you propose:Import them all into Rev on a PC. They all look the same. Then view the same stack on a Mac. The PNG image looks considerably lighter. This continues to be a problem when designing interfaces between the 2 platforms. I develop on a Mac, and that might affect what I see. My images look the same on both platforms, (i.e. just as light/dark on Windows as on the Mac) BUT colors in images fail to match the backcolors of objects that they did match on the Mac.)-- Tereza Snyder   Califex Software, Inc.   www.califexsoftware.com ___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[Chipp Walters]

Tereza,Even though Fireworks can create images in native Window Gamma, does it really pass the test I outlined above? I would be very surprised if it did.best,Chipp
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[Chipp Walters]

Hi Wilhelm,Then, if I am correct, setting the global paintcompression to RLE then 'touching' a PNG image (getting and setting both the imageData and alphaData) will now set the image to RLE instead of the original PNG. Is this your understanding as well?
I suppose I could just test this. If it does work, I will need to create a 'touchImage' plugin :-)Thanks for your hard work on this issue.best,Chipp
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[Wilhelm Sanke]

Other details about imagedata, text of image, and paintcompression:

Saving the imagedata will not save the paintcompression format at the 
same time. Resetting the image from the saved imagedata will change the 
paintcompression of the image to the default global paintcompression.


Contrariwise, saving the imagetext ("text of image") *will* indeed save 
the paintcompression format. No matter which global paintcompression 
format is set afterwards, when the image is restored from its saved 
imagetext, it will possess its original paintcompression.


Unfortunately, the text-of-image data cannot be manipulated in any 
consistent way like the imagedata. At least, I did not find a way to do 
that.
This means that the only possible use of  text-of-image could be storing 
and restoring images (when RLE is *not* set as the paintcompression).-


As I already reported, when the paintcompression is set to "RLE" and you 
save the imagetext and then restore the image from the imagetext two 
things happen:


1. The alphadata are set to 0; the image becomes invisible

2. The image is still there, but its imagedata colors are reduced to one 
monochrome color, which you can see when you change the alphadata back 
to 255 - opaque.


I tested this also using a MC/Rev-scripted histogram function.

Maybe this feature - getting an invisible monochrome image when 
imagetext is saved and reset with "RLE" - should be reported as a bug?.-


It would also constitute a valuable contribution to our discussion, when 
someone from the Rev team would enlighten us, why they have chosen PNG 
paintcompression as the default format for the Rev IDE and Rev 
standalones - especially in the light of the fact that all imagedata 
manipulation is slowed down considerably with the PNG format.


Regards,

Wilhelm Sanke



___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[Wilhelm Sanke]

Chipp Walters wrote;


(snip)

Perhaps if I tweak the imageData on the PNG with paintCompression set 
to RLE, it will keep it from showing the gamma change? 



and Tereza Snyder wrote:


For me, using PNG images has a positive consequenceetc.



The global default setting of the paintcompression can be different from 
the paintcompression of an image. An image has the paintcompression of 
the image format that it possessed when it was imported, i.e. fully 
imported (like with "put URL "binfile:filename" into img x), whereas a 
referenced image will have he default paintcompression setting.


This is probably what the docs want to state: "If the image was created 
with the import command, its paintcompression is set to the format of 
the imported picture file."


So you can have all he advantages of the PNG format, although the global 
paintcompression should be set to RLE.


However, the moment you change the imagedata of that image, the 
paintcompression will be the global one.


And, you can reset the global paintcompression any time you wish, for 
example via MSG.


Best regards,

Wilhelm Sanke

___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[Tereza Snyder]

On Nov 5, 2006, at 8:14 PM, Chipp Walters wrote:I'm wondering if paintCompression should be set to RLE in Rev as well? The reason I ask is because JPG, RLE and GIF do not have gamma settings, but PNG does. In other words, a PNG graphic will look different on Mac than on PC's. Try this easy test: create a gray 128,128,128 square image in Photoshop.Save it as JPG, GIF and PNGImport them all into Rev on a PC. They all look the same. Then view the same stack on a Mac. The PNG image looks considerably lighter. This continues to be a problem when designing interfaces between the 2 platforms. For me, using PNG images has a positive consequence. I use Fireworks on the Mac to design my interfaces, which are typically covered head-to-toe with graphics.  If I import calibrated-by-eye, perfectly contrasted pngs into MC/Rev they appear much darker - even on the Mac -  which is a rude awakening if I've been concentrating so much on design that I've forgotten about gamma! I can set the Fireworks window next to the Rev window on my Mac desktop and see the difference. Either Fireworks is setting the PNG metadata so that Rev displays it with Windows gamma, or Rev is using Windows gamma despite Fireworks' setting. Either way, I'm getting Windows gamma on the Mac in my user interface which means that its appearance is the same on both platforms. And that's all I care about!"But wait"! you say, "How can you design in one gamma for display in the other?" No problem.  Fireworks has a "View Windows Gamma" menu item that lets me design on the Mac while seeing Windows gamma. It seems that in the past the situation was different - I used to struggle with the disparity in gamma as Chip describes. But in the last while (a year or two?) though a couple of version upgrades of both Rev and Fireworks, the Windows gamma situation has worked in my favor and I pray it never changes!t -- Tereza Snyder   Califex Software, Inc.   www.califexsoftware.com ___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[Richard Gaskin]

Chipp Walters wrote:

Very interesting thread.

I'm wondering if paintCompression should be set to RLE in Rev as well?


It is, in the sense that the engine uses RLE by default.

The IDE has a number of areas where its designers choose to conceal 
engine behaviors from their users, causing much confusion among users 
who see differences in their standalones.


If they feel PNG should be the default, so they feel this way strongly 
enough to change the engine default?  If not, is it really the wisest 
choice for the IDE?


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[Chipp Walters]

Very interesting thread.I'm wondering if paintCompression should be set to RLE in Rev as well? The reason I ask is because JPG, RLE and GIF do not have gamma settings, but PNG does. In other words, a PNG graphic will look different on Mac than on PC's. Try this easy test:
create a gray 128,128,128 square image in Photoshop.Save it as JPG, GIF and PNGImport them all into Rev on a PC. They all look the same. Then view the same stack on a Mac. The PNG image looks considerably lighter. This continues to be a problem when designing interfaces between the 2 platforms. Perhaps if I tweak the imageData on the PNG with paintCompression set to RLE, it will keep it from showing the gamma change?

___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[Wilhelm Sanke]

On Wed, 01 Nov 2006, J. Landman Gay wrote:


(snip)
I take back what I said about the paintcompression being in revCommon. 
It isn't, it is in the library the IDE loads. It's got to be somewhere 
else in standalones, since that's what is obviously happening.


--
Jacqueline Landman Gay   




Once we know what to look for it is easier to locate. I made a search 
with my "revbrowser" which contains a fast script browser.


In Rev 2.7.4 the paintcompression is set from stack "revlibrary" in 
folder "toolset" in the script of group "revlibraries" and its handler 
"revLoadLibraries":


"on revLoadLibraries
 global gRevSmallAppIcon,gRevAppIcon
 local tBtn,tLine
 set the paintCompression to "png" -- match the engine
 ...
 ..."

This handler is also added to each standalone.

Best,

Wilhelm Sanke



___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[J. Landman Gay]

Richard Gaskin wrote:

J. Landman Gay wrote:
It is the default compression in the engine, and if no other 
compression is set, you will get RLE by default. I just did a search 
and found that Rev does set the paintcompression to PNG in the 
revGeneral library.


How did this affect standalones?


It's the only library that Rev always adds to standalones. As Kevin 
explained, it contains all the "rev-" language additions, so is 
required for most Rev users. And to keep standalones in parity with 
the IDE, it sets the paintcompression as well.


(And I can never remember if it is called "revCommon" or "revGeneral" 
but its the one that handles all the basic rev language extensions.)


It's been a while since I dove into revCommon or revGeneral, but IIRC 
they only contained handlers that had to be called explicitedly (the 
"rev"-prefixed ones).


What system messages are trapped in those scripts?



Kevin answered this before. Only mousedoubleup, which gets redirected if 
the target isn't a rev-embedded stack.


I take back what I said about the paintcompression being in revCommon. 
It isn't, it is in the library the IDE loads. It's got to be somewhere 
else in standalones, since that's what is obviously happening.


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[Richard Gaskin]

J. Landman Gay wrote:
It is the default compression in the engine, and if no other 
compression is set, you will get RLE by default. I just did a search 
and found that Rev does set the paintcompression to PNG in the 
revGeneral library.


How did this affect standalones?


It's the only library that Rev always adds to standalones. As Kevin 
explained, it contains all the "rev-" language additions, so is required 
for most Rev users. And to keep standalones in parity with the IDE, it 
sets the paintcompression as well.


(And I can never remember if it is called "revCommon" or "revGeneral" 
but its the one that handles all the basic rev language extensions.)


It's been a while since I dove into revCommon or revGeneral, but IIRC 
they only contained handlers that had to be called explicitedly (the 
"rev"-prefixed ones).


What system messages are trapped in those scripts?

--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[J. Landman Gay]

Richard Gaskin wrote:

J. Landman Gay wrote:

Wilhelm Sanke wrote:


For my imagedata-handling stacks "Seamless Tiles" and "Imagedata 
Toolkit" I added an open-stack handler with "set the paintcompression 
to RLE". The described and discussed speed differences between MC and 
Rev are no longer there.


Wow, you solved it! That was some interesting results you posted.

At least one question remains, where is the default paintcompression 
set? I made a script search in the MC home and tools stacks and did 
not find "paintcompression"?? -


It is the default compression in the engine, and if no other 
compression is set, you will get RLE by default. I just did a search 
and found that Rev does set the paintcompression to PNG in the 
revGeneral library.


How did this affect standalones?




It's the only library that Rev always adds to standalones. As Kevin 
explained, it contains all the "rev-" language additions, so is required 
for most Rev users. And to keep standalones in parity with the IDE, it 
sets the paintcompression as well.


(And I can never remember if it is called "revCommon" or "revGeneral" 
but its the one that handles all the basic rev language extensions.)


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[Richard Gaskin]

J. Landman Gay wrote:

Wilhelm Sanke wrote:


For my imagedata-handling stacks "Seamless Tiles" and "Imagedata 
Toolkit" I added an open-stack handler with "set the paintcompression 
to RLE". The described and discussed speed differences between MC and 
Rev are no longer there.


Wow, you solved it! That was some interesting results you posted.

At least one question remains, where is the default paintcompression 
set? I made a script search in the MC home and tools stacks and did 
not find "paintcompression"?? -


It is the default compression in the engine, and if no other compression 
is set, you will get RLE by default. I just did a search and found that 
Rev does set the paintcompression to PNG in the revGeneral library.


How did this affect standalones?


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[J. Landman Gay]

Wilhelm Sanke wrote:


For my imagedata-handling stacks "Seamless Tiles" and "Imagedata 
Toolkit" I added an open-stack handler with "set the paintcompression to 
RLE". The described and discussed speed differences between MC and Rev 
are no longer there.


Wow, you solved it! That was some interesting results you posted.

At least one question remains, where is the default paintcompression 
set? I made a script search in the MC home and tools stacks and did not 
find "paintcompression"?? -


It is the default compression in the engine, and if no other compression 
is set, you will get RLE by default. I just did a search and found that 
Rev does set the paintcompression to PNG in the revGeneral library.




I have added a comment to my Bugzilla entry 3938 stating that the issue 
has been resolved.


I'm impressed with your detective work. Very helpful, thanks.

--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[Wilhelm Sanke]

On Tue, 31 Oct 2006, J. Landman Gay wrote:


Wilhelm Sanke wrote:


For the above points there are no differences between Rev and MC, but
- The format of the "text of image" property is different in Rev 
and MC - tested both in stacks and standalones.


Rev sets the default paintCompression to PNG and MC sets it to RLE. I 
suspect this is done in the RevCommon library, but I haven't actually 
looked. To test equivalencies, it would be good if you set the the 
paintCompression to PNG in MC too.




Thanks, Jacqueline, this was the most important hint for me in the last 
weeks, because it also solves the mystery of the slow imagedata handling 
in Rev, which we dicussed at length in thread "MC-Rev speed differences.."


A related problem and also involving "paintcompression" had been 
dicussed between Dar Scott and Wouter in January 2004.---



The format of paintcompression affects both properties "text of image" 
and "imagedata".


How the properties are affected seems to be a can of worms and the Rev 
docs are incomplete/ambiguous here and even wrong for some details:


Rev docs: "By default, the global paintcompression property is set to 
"rle" in standalones and "png" in the development environment."


This is not true: By default, in Rev paintcompression is set to PNG in 
the environment *and*  standalones. If this would not be the case then 
we would not get the speed differences in imagedata handling between 
Metacard and Revolution.


Rev docs:  "If the image was created with the import command, its 
paintcompression is set to the format of the imported picture file."


This is only true if the image was fully imported. For a "referenced" 
image the paintcompression format is that of the environment, PNG for 
Rev and RLE ("Windows run-length encoded") for Metacard, and - a 
referenced image does not contain any "text of image" data, but contains 
"imagedata". A referenced image will acquire "text of image" data only 
after you have edited it.


Rev docs: "To change an image's compression format, first set the 
paintcompression to the desired value, then paint in the image. Then 
either go to another card and return, or close and re-open the stack."


This is only partially true: Besides painting in the image you can apply 
other possibilities of editing like changing the imagedata with filters 
etc. Also it is not necessary to go to another card and return.


The short entry 707 of the Metacard docs is more precise here:

"This property sets the compression format used when an image is 
recompressed after it has been edited."---


When you get the "text of image" data while paintcompression if set to 
RLE (and the image had been edited), resetting the image to its own 
"text of image" data will make it totally transparent as all chars of 
its alphadata are set to 0. I suppose this is a bug, as I cannot see a 
sound reason for this transparency.
Resetting the alphadata of the transparent image to 255 will not reset 
the image, but produce a monochrome rectangle.


The "text of image" data can be retrieved and reset with the other 
paintcompression formats PNG, JPEG, and GIF.


If the paintcompression is set to GIF (and the image had been edited) 
and you restore an image with "imagedata" retrieved with 
paintcompression set to RLE or PNG the resulting image may be distorted 
or incomplete.


For my imagedata-handling stacks "Seamless Tiles" and "Imagedata 
Toolkit" I added an open-stack handler with "set the paintcompression to 
RLE". The described and discussed speed differences between MC and Rev 
are no longer there.


At least one question remains, where is the default paintcompression 
set? I made a script search in the MC home and tools stacks and did not 
find "paintcompression"?? -


I have added a comment to my Bugzilla entry 3938 stating that the issue 
has been resolved.


Best regards,

Wilhelm Sanke



___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Re: Another MC-Rev anomaly: "text of image" property

[J. Landman Gay]

Wilhelm Sanke wrote:


For the above points there are no differences between Rev and MC, but

- The format of the "text of image" property is different in Rev and MC 
- tested both in stacks and standalones.


Rev sets the default paintCompression to PNG and MC sets it to RLE. I 
suspect this is done in the RevCommon library, but I haven't actually 
looked. To test equivalencies, it would be good if you set the the 
paintCompression to PNG in MC too.




Resetting an image to its previously stored text in MC and the MC IDE 
results in a blank image (unless the text was stored using Rev and the 
stack after that opened in MC).


This means that you cannot use the text property to store and retrieve 
images in MC.


Even though you are using the same engine, are you saving the stacks 
with the same stackFileFormat?




The different format of the text of image property in Rev can be seen 
when you put the retrieved text into a field:


The first line of the image text in Rev always contains "‰PNG", which is 
missing in MC.--


The big question - similar to the one about imagedata, but this time to 
the disadvantage of MC - is (as both IDEs and standalones use the same 
engine) what is being added to the Rev standalone that allows proper 
handling of the "text of an image"?


As far as I know (which may not be enough) it's just the difference in 
the paintcompression property.


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard

Another MC-Rev anomaly: "text of image" property

[Wilhelm Sanke]

First: The imagedata speed problem has been added to Bugzilla as bug 3938.--



I took a look at the "text of image" property to see what is different 
from imagedata (tested for Windows XP).


Results:

- The number of chars of the text of an image is about 50% smaller than 
for imagedata, meaning that storing the "text of an image" needs less space.


- Other than with imagedata, restoring an image with the stored text of 
the image shows no speed differences between Rev and MC.
Resetting the text of a larger image is about 10 milliseconds slower 
(180 vs 190 for an image 1600X1200) for both Rev and MC 2.7.4 compared 
to MC 2.6.6 and Rev 2.6.1.


- For referenced images no "text of image" data are available, the 
retrieved imagetext is then empty (imagedata are *not* empty in this case).
You have either to import the image (or take a snapshot) or first to 
manipulate the imagedata to get any "text of the image"


- Manipulating the "text of an image" apparently is not possible like 
with imagedata. If you reset an image to its changed text, you will get 
a blank image.


Has anybody succeeded or tried to change the "text of an image"?

For the above points there are no differences between Rev and MC, but

- The format of the "text of image" property is different in Rev and MC 
- tested both in stacks and standalones.


Resetting an image to its previously stored text in MC and the MC IDE 
results in a blank image (unless the text was stored using Rev and the 
stack after that opened in MC).


This means that you cannot use the text property to store and retrieve 
images in MC.


The different format of the text of image property in Rev can be seen 
when you put the retrieved text into a field:


The first line of the image text in Rev always contains "‰PNG", which is 
missing in MC.--


The big question - similar to the one about imagedata, but this time to 
the disadvantage of MC - is (as both IDEs and standalones use the same 
engine) what is being added to the Rev standalone that allows proper 
handling of the "text of an image"?


Regards,

Wilhelm Sanke




___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard