lockLoc [was Re: Alpha Channel?]

[Frank Leahy]

Graham,

>>> Why on earth does RR do this?  It drives my students crazy.
>>> Why do you have to lock the size of an image to keep it the size
>>> you set it?  Is this a feature or a bug?
>>

Whenever you change an image (via fileName or import), the issue for 
RunRev is what to do about the image object's size (notice I said 
"image object" not "image").  Should it stay the height and width that 
it is currently on screen?  Or should it be resized to the formatted 
height and width of the new image that it's going to display?  lockLoc 
is the hint that tells RR what to do.

Personally I never use lockLoc, always resizing the images I need on 
the fly, and in your case it sounds like you need more control, and so 
you might not want to set lockLoc.  But imagine a stack of many cards, 
each with dozens of thumbnails, all pointing to different images on 
disk.  Without lockLoc, a programmer would have to resize each image on 
every openCard rather than having them stay the size they were set at.
>
> It drives me crazy too because it's not clear how you turn off the 
> 'revert
> to original' feature permanently, for example if you want to repurpose 
> the
> image entirely and completely lose the original size.

There are two types of image, ones you set via the fileName property, 
and ones you set via the import command.  They are similar, but subtly 
different.  For example, you can't use the clipping command on fileName 
images.

But one way they're the same is that both types of images retain their 
original or "formatted" height and width when you resize them.  When 
you set an image object's height and width, you're not resizing the 
original image (the one on disk), you're resizing the "RunRev image 
object" which happens to have a copy of your image's data in it.

If you want that new image height and width to be permanent, you will 
need to rewrite the image data to disk, and the way to do that is via 
the export command.

> I mean, if I'd
> altered the shape of an image in a graphics package, I wouldn't expect 
> the
> 'original size' to haunt me forever, would I?

Of course you would.  In Photoshop, until you hit Save, and save over 
the original file, you have access to the original image through undo, 
or the Revert to Saved menu item.   Right?  You'd be very very upset if 
Photoshop threw away your original data just because you resized the 
image.


> I don't see an original size
> as a 'natural' size; it's just what I started with, neither more nor 
> less.
> As I see it, a resized image is a new image, and the idea that the 
> system
> has a mysterious way of retaining its history is eccentric to say the
> least.

The original pixels are in the image object, and you can scale it up or 
down at any time.  Would you really want RunRev to throw away the 
original image data because you scaled the image down to 100,100?  What 
if you wanted to scale it up to 250,250, and then back down again, or 
wanted to animate it?  Do you want to have to reload the image from 
disk for each size change?

> What if I duplicated it seven times and make each of the dupes a
> different size, and then made each of the dupes part of a 
> shape-changing
> animation, moving between the new size of the dupe and some other size
> dictated by the animation (this is an extension of a real case)? The 
> way
> things are now, I'd have to use an external package to do all these
> transformations.

Each image object will have its own copy of the pixels and each image 
object can be resized to a different size without impacting the other 
objects.


>
> I'd like it so if I wanted the history, I could save it myself - 
> otherwise
> transformations should stay transformed.

They do stay transformed, until one of two things happens.  One, if you 
change the image object via the fileName or import commands, or two, if 
you leave the card and return.  When you return to a card, RR uses the 
lockLoc property as a hint about how to size the image object as it 
redraws the screen ("hmmm, do I use the image size, or do I use the 
image object size?").

> BTW I am not convinced that the
> lockLoc feature works completely in all situations - at least I've had 
> some
> problems with editing groups (by script) which contain resized images. 
> I
> admit that these were too obscure to chase down into proper Bugzilla 
> reports.
>

Sorry, I can't help you with that as I don't use the feature for images.

-- Frank