putting the width of a image into a variable

[d.m.holdawayGA2553]

hello,

i can put the width of an image into a variable but i want to ignore the opaque pxls

can this done?

any advice or a kick in the right direction is welcome.

[Mark]

Hi,

I have absolutely no clue what "ignore the opaque pixels" means. You can get the width of an image object with

Code: Select all

get the width of img "Your Image"

and you can get the image of the actual picture in that image object with

Code: Select all

get the formattedHeight of img "Your Image"

Kind regards,

Mark

[bn]

Hi dm,

if you mean the visible part of an image that is not transparent, i.e. it is visible then this is a bit tricky since Livecode knows only the overall width of an image.
To get at the width of just the visible part of an image you have to roll your own and look at the alphaData of an image. That can be quite confusing at first.

Here is a little stack that analyzes the alphaData of an image and determines the rect of the visible part of an image, ignoring the translucent part.

Bildschirmfoto 2012-04-13 um 10.23.29.png (63.38 KiB) Viewed 4854 times

getVisibleRectOfPNG.livecode.zip

(98.84 KiB) Downloaded 201 times

Kind regards

Bernd

[d.m.holdawayGA2553]

excellent that was just what i was looking for.

[sturgis]

you could also use intersect for this. have 2 lines 1 vertical, 1 horizontal.

place the vertical line at the left edge of the image and move it right a pixel at a time while checking intersect(image "theImage",grc "theline","opaque pixels") and see if there is an intersect. If not there are no opaque pixels along the path of the line. Move it in till you hit an opaque, subtract 1 from the line position and you have the left side of the graphic marked. Do the same from the right, then top then bottom.

I doubt its as fast as the alphadata method but it is an easily understandable method which can be a plus.

[bn]

Hi Mike,

I like your idea of testing for intersect. Somehow I never thought of using the relatively new threshold property of intersect with images. Only for polyonal graphics.

It gave me the idea of using "intersect" instead of "within". "Intersect" needs a rect and has the threshold property. "Within" uses a point and has no threshold property. Often I would like to determine if a point is within the visible part of a graphic or an alpha masked image.
To get my modified "Within" I used a rectangle graphic of 2 by 2 pixel (can be invisible) set the loc of the graphic to the loc of interest (tested with the mouseLoc in a loop) and get the "intersect" which is actually the point.
nice. Gives me the same results as when I use the alphaData, given the same threshold.

Thank you

Kind regards

Bernd

[sturgis]

Very cool, and as mentioned earlier is very much easier to program and grok than dealing with the image data.
I haven't speed tested either method, ok I didn't even test the intersect idea at all just posted the thought. Is interesect fast enough to be usable to find visible rect in this manner? For a point I know it should be fine. Ok, guess I should go do some testing to satisfy my curiosity!

EDIT: Just occurred to me that if the size of the areas being checked for intersect matters (IE the length of the line being tested against the image) it would be possible to get some speed increases by eliminating previously tested areas. Meaning if you didn't hit an opaque pixel until pixel 15 when moving in from the left side and pixel 15 in from the right side you've just eliminated 30 pixels you need to test for each line of the pixels from top to bottom. Don't know if you do this with your alphadata example but the same rule should apply.

[bn]

I tried Sturgis suggestion to let two graphics each 1 pixel wide go into an image with alpha mask and test for intersect. It is 50 percent slower then the "alphaData way" but I find this amazingly fast.

for the image above which is 518 px wide and 389 px tall using the "alphaData way" is about 40 milliseconds and the "intersect way" is about 60 milliseconds to determine the "visible" rect.

Kind regards

Bernd

[sturgis]

Hmm yep, thats fast enough! I'm surprised, I thought intersect would be harder hit than that. Thx for running the test, much appreciated!