Text of an image

[Ken Ray]

> The lockLoc of the second image must either be false OR the second
> image must be the exact same size as the first image. Otherwise the
> image/alphaData of the two images will not be the same.

Right. Here's a "cheat sheet" for those who care:  ;-)

the imageData of <imgObj>
-------------------------------------
    Holds the Red, Green, Blue, and Alpha pixel values (bits) of the visual
representation of the image object. The amount of imageData in an image
object is (Height * Width * 4), regardless of whether there's an actual
image in the image object. (You can test this by creating an image object,
sizing it to any size you like, and then execute "put length(the imageData
of <imageObjectDescriptor>)" in the Message Box.)


the text of <imgObj>
----------------------------
    Holds the actual binary data for the image *inside* the image object. If
the image object's 'alphaData' property contains any other value than 255
(opaque), the data is stored in PNG format in the image.


Setting ImageData/Binary vs. Visual Copies
---------------------------------------------------------
    NOTE: When you set the imageData of an object, you are telling Rev to
*create the binary data* to represent the imageData you're passing it. This
has the result of causing the "text" of the image object to be different
than the "text" of a source image, even if they *look* the same. So for the
purposes of the list below, I use these terms:

   "binary copy" - The text of two images are the same, but the imageData of
the two images are different.

    "visual copy" - The imageData of two images are the same, but the text
of the two images are different.

    "exact copy" - Both the text and imageData of two images are the same.

    "unique" - Both the text and imageData of two images are different.


Resizing/FormattedWidth/FormattedHeight
----------------------------------------------------------
When you resize an image, the visual representation (imageData) changes, but
its binary representation does not. This is why an image object will
automatically resize itself to match the full dimensions of the image when a
card is opened UNLESS the image object's "lockLocation" (lockLoc) is TRUE.

Note that even though you can resize the rect of the image object, the
original image data's width and height are still accessible through the use
of the "formattedWIdth" and "formattedHeight" properties of the image
object.
 

Embedding vs. Referencing
------------------------------------
When you embed an image (i.e. "Import as Control..."), the image object
created has both a visual representation (imageData) as well as a binary
representation (text).

When you reference an image (i.e. "New Referenced Control..."), the image
object created ONLY has a visual representation (imageData) and has no
binary representation at all (text is empty).


WORKING WITH TWO IMAGES
=========================

Source and Destination are Same Size
------------------------------------------------------------
put img "Src" into img "Dest"

    - Source is Embedded:
          img "Dest" has an EXACT COPY of img "Src"
    
    - Source is Referenced:
          img "Dest" is empty (or emptied out)


set the imageData of img "Dest" to the imageData of img "Src"

    - Source is Embedded OR Referenced:
          img "Dest" has an VISUAL COPY of img "Src"


Source and Destination are Different Sizes
------------------------------------------------------------
put img "Src" into img "Dest"

    - Source is Embedded, lockLoc of Dest is FALSE:
          img "Dest" is resized to match the width/height
          of img "Src", resulting in an EXACT COPY of img "Src"
 
    - Source is Embedded, lockLoc of Dest is TRUE:
          img "Dest" is not resized, but holds a skewed view
          of img "Src", just as if you'd resized img "Src" to the
          same dimensions as img "Dest", resulting in a
          BINARY COPY of img "Src"

    - Source is Referenced, lockLoc of Dest is TRUE or FALSE:
          img "Dest" is empty (or emptied out)
 
set the imageData of img "Dest" to the imageData of img "Src"

    Source is Embedded or Referenced, lockLoc is TRUE or FALSE:
        - img "Dest" contains visual garbage, and its
          size is unchanged, regardless of whether the lockLoc
          is TRUE or FALSE; img "Dest" is UNIQUE


TRICKS
======

Resetting an Image to its Original Size/State
----------------------------------------------------------
If an embedded image has had its rect changed so that it is no longer the
original size, you reset the image like this:

  set the lockLoc of img 1 to false
  put img 1 into img 1

This is possible because the binary data (text) of img 1 has not changed
since it was imported; only the visual representation (imageData) has
changed. So putting the binary data of the image back into the image forces
Rev to resize the image (assuming the lockLoc is false).


Creating Thumbnails/Reducing Size of Stored Images
-----------------------------------------------------------------------
If you want to show a reduced size (thumbnail) of an image, you can always
just change the rect of the image. This will change the visual
representation, but unfortunately will keep all the binary data for the full
size of the image. This is a pain because you have to manage the lockLoc of
the image objects (if you don't they can "spring" back to their original
size), and it also stores a lot of unneeded data in your stack.

To store a thumbnail, you can follow these steps:

1) Import the image onto the card, probably with lockScreen TRUE (unless you
want the user to see what's going on).

2) Resize the image object to the size you want for the thumbnail.

3) Set the imageData of the image object to the imageData of itself. Doing
this will force Rev to recreate the underlying binary and so you get the
same visual image, but with a LOT less binary data behind it.

Example:

on mouseUp
   answer file "Select an image to thumbnail:"
   if it <> "" then
      import paint from file it
      put the long id of last img into tImgObj
      -- Resize it to 25%; since just imported, don't need to use
      -- formattedWidth or formattedHeight, can simply use
      -- width/height
      set the width of tImgObj to round((the width of tImgObj) * .25)
      set the height of tImgObj to round((the height of tImgObj) * .25)
      set the imageData of tImgObj to the imageData of tImgObj
   end if
end mouseUp

When I did this with an 832 x 665 image, it reduced the size to 208 x 166
and cut the "weight" of the image from 225 K to 28 K.

HTH,

Ken Ray
Sons of Thunder Software, Inc.
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/