dump newbie image questiosn

[Jon]

J. Landman Gay wrote:

> On 6/5/05 4:33 PM, Jon wrote:
>
>> My first learning project was to replicate my Windows image 
>> viewer/manipulator in Rev.  That ended with some finality when it 
>> turned out that Rev runs so slowly that it cannot possibly process 
>> all of the pixels in a real image in the time a reasonable user would 
>> sit still.  Sigh.
>
>
> You should be able to do this easily, and I know of several image 
> viewers that others have done. It is a trivial task in Revolution, and 
> very fast. There are so many image commands and features that you 
> should never need to manipulate individual pixel data except in the 
> most unusual cases. For a standard image viewer project, never.


My viewer is not a standard viewer.  I've implemented a variety of 
useful features that require that I manage each pixel individually 
(basically doing custom and complex brightness and contrast 
stretching).  Rev is way too slow to do anything like that. 

>
> This is an excellent first-time project. It should be possible to 
> write a simple image viewer in a handful of lines. You can display an 
> image from disk in a single line of Transcript. You can set its size 
> in one more line. What did you need to do exactly? Maybe we can help 
> you finish this.


You can download my Windows image viewer if you root around in 
www.jonbondy.com a bit if you want to see the features I've 
implemented.  Image sizing is a very difficult thing in Rev: the default 
seems to be either 1:1 display (which often is too large to fit in the 
allocated space) or horrible distortion when the image is forced into 
the limits of the enclosure.  I can write software to fix all of this, 
but I decided to move on to another project (the audio/video player)

>
>>
>> I'm now working on a special music/video player, again "porting" it 
>> from a Windows implementation.  It's almost finished (in the sense 
>> that all of the features seem to work at least once!), but needs a 
>> lot of cosmetic work and then lots of testing.   I am displaying 
>> guitar tablature in an image along the bottom of the screen.  I want 
>> the image to "squeeze" into the given box, but NOT be distorted (a 
>> fairly obvious need in my opinion).  So, I need to write (or steal!) 
>> the logic that figures out which dimension needs to be adjusted, and 
>> then adjust it, and then use the LockLoc (what a strange and 
>> unintuitive name!) to let it expand to fill the properly proportioned 
>> image container.
>
>
> LockLoc is short for "lock location" and can also be written 
> "locklocation". ;) It overcomes the default behavior of images, which 
> is to automatically expand to fit their image contents.


This is not locking a location; it is altering the image expansion 
behavior.  I find some of this nomenclature to be very bizarre.

>
> When you put an image from disk into an image object, it will 
> automatically resize to fit the image content. If you do not want this 
> behavior, you lock the location (that is, you prevent resizing) by 
> setting the lockLoc to true. When an image is locked this way, its 
> contents will *scale* to fit the image object, rather than the object 
> scaling to fit the image content.


True, but it will scale in both directions, distorting it horribly.  
This is not useful behavior, unless you want to fill a large space with 
a small speck of blue.   It's ok for backrgounds, not for actual images.

>
>>
>> A snippet of code would suffice, although I've written this code 
>> enough times that I'm sure I could figure it out again.  I am more 
>> annoyed that I even have to than anything else.
>
>
> I have it somewhere but I'd have to go search for it. It isn't too 
> hard though. You just get the width of the available space and the 
> height of the available space, then compare them to see which is 
> larger. Use the largest one to calculate a ratio. Multiply that ratio 
> times the formattedwidth of the image to get the new width; multiply 
> it times the formattedheight of the image to get the new height.
>
> If you can't figure it out, post again and I will go look for it. I 
> can't remember which project I put it in. ;)


Yeah: the logic is straightforward if you work it out.  I just feel as 
if this should be an intrinsic part of images.  And I ran into some huge 
bugs when I accidentally mixed an image with Geometry with an On Resize 
handler.

>
>>
>> The Geometry facility is interesting (and novel to me), but I don't 
>> know that it will work at all with the kinds of things I want to do.  
>> Because I don't want to distort any images, I will end up altering 
>> the shape of the Image object each time an image is loaded.
>
>
> As per above, if you leave the lockloc of the image object set to 
> false, the image will automatically resize to the native dimensions.


As per above, the image will be impossible to see, since it will be so 
distorted

>
>>  Eventually, it will be easy to lose track of the original shape/size 
>> of the "container" into which I was trying to stuff the images.  
>> There is a concept missing here, I think: we need THREE image sizes 
>> (pixel size on disk, size of largest space available on the screen, 
>> and actual space used on the screen) rather than the two (first and 
>> last, above) that is currently available.  I'm spoiled: all of this 
>> was available in a single mode property in my previous IDE.
>
>
> I'm not sure what you are after exactly, but these can all be retrieved.
>
> Pixel size on disk: formattedwidth and formattedheight of the image.
>
> Space available on screen: you'll have to calculate that, or if it is 
> always the same, store it as a constant, a property or a variable, etc.
>
> Actual space used on screen: you can get either the rect of the image, 
> or you can get the width and the height of the image. This represents 
> the actual current size of the image object.
>

Maybe this is better left as a phone conversation <grin>

Jon