lockLoc [was Re: Alpha Channel?]
frank at backtalk.com
Thu Jun 10 09:34:01 CDT 2004
>>> 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
> to original' feature permanently, for example if you want to repurpose
> 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
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
> '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
> I don't see an original size
> as a 'natural' size; it's just what I started with, neither more nor
> As I see it, a resized image is a new image, and the idea that the
> has a mysterious way of retaining its history is eccentric to say the
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
> 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
> things are now, I'd have to use an external package to do all these
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
> I'd like it so if I wanted the history, I could save it myself -
> 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
> problems with editing groups (by script) which contain resized images.
> admit that these were too obscure to chase down into proper Bugzilla
Sorry, I can't help you with that as I don't use the feature for images.
More information about the use-livecode