ImageSearch: Click center of found image

[AviationGuy]

Hi there,

Since I'm not a programmer, I don't know if there is a logical explanation for this, but I was wondering why the ImageSearch function returns the upper left coords of the found image and not the center?
Why would someone click the uppermost corner of an image? Let's suppose you want to click on a button with curved edges like the buttons above the text field on the AHK forum when writing a post. When you select the button, ImageSearch will find it and moves the mouse to the upper left corner. However, you are not able to click the button because the button has curved edges and the pointer is therefore not on the button.
Of course, you can select e.g. the text inside a button as an image or implement OutputVarX+=10
OutputVarY+=10 in your code but why not just return the center coords of the found image?
I genuinely can't think of an example when returning the center of a found image won't be useful.

The function could look like this.
ImageSearch, FoundX0, FoundY0, FoundX1, FoundY1, X1, Y1, X2, Y2, ImageFile
Or return only the center of the image although I don't think this will be very handy.
ImageSearch, FoundCenterX, FoundCenterY, X1, Y1, X2, Y2, ImageFile

I wouldn't be surprised if people have thought of this and didn't implement it for obvious reasons. If so, please do so
Also, I know there are scripts made by community members that let you click the center of an image after it finds it but I'm just interested in why this isn't the standard.

PS. If you guys think this post belongs more on the 'Ask for Help' forum you can, of course, move it.

[boiler]

Clicking on an image once it is found is only one use case of finding an image with ImageSearch. The most generic and useful information on the location of the image is its upper-left corner, especially since that is how the the coordinates of the screen and windows are laid out (with 0,0 being the upper-left most pixel). The center of an image is relatively arbitrary based on its size for most cases.

I can think of many more cases where finding the upper-left corner of the image is more useful than finding the middle of it. It corresponds to a known point on all images -- its corner. The center of an image won't even be a pair of integers for 75% of all images.

[nnnik]

In programming you usually take the least steps to get a specific result. Calculating an images center point is an additional step. Image search internally stores the upper right corners due to the way it searches.
With the information a user has they can easily get the centerpoint of the found image if necessary.

[AviationGuy]

Thanks for the reply's

@boiler, oke, but I assume an image size isn't rounded to 0 digits then? Or, why not just round off the found center coords? Has this to do with multiple unnecessary steps nnnik mentioned?
And why not just give the option as parameters that could be left out within the function?
ImageSearch, FoundX0, FoundY0, X1, Y1, X2, Y2, ImageFile [, FoundX1, FoundY1]-> not the greatest layout but just an example
Can you give an example of a case when finding the upper-left corner will be more useful then finding the center?

@nnnik,

In programming you usually take the least steps to get a specific result.

Oke, this is a clear explanation. Btw, don't you mean upper-left corner?

[swagfag]

which pixel designates this 4x4 image's center? is it the red one? is it the green one? is it the blue one? or perhaps the yellow?

maybe we should add yet another flag to ImageSearch so u can specify which pixel u want the image's center to be?
or maybe we could have it return the top-left pixel every time, not bloat the function with more params, and let the programmer decide which pixel the center is supposed to located at

[boiler]

Swag stated it well. Also, the size of the image isn’t what is rounded because it’s always an integer. It’s only the center of the image that often wouldn’t be an integer because you’re dividing by 2, and if the size is an odd number, then the center will have a 0.5. Rounding the result would be a terrible thing to do. Then we don’t even have the ability to determine its exact location because we’ve thrown away the precision, so even if we try to determine it, we will often be off by one pixel.

The unnecessary steps are in finding the center in the first place because AHK finds the location relative to the corner when it searches. Not only is the center usually not needed, then you are often causing the programmer to do yet another unnecessary step to find the corner.

Here’s just one example of the corner being much more important than the center: I want to find the corner of a text box because I am going to perform a screen capture of it. I want to know the location of where the box starts, and the corner is what defines where to start grabbing the image. This isn’t a rare example. The corner is typically more useful than the center.

[AviationGuy]

Oke, I understand. Thanks for the information!

Maybe we should add yet another flag to ImageSearch so u can specify which pixel u want the image's center to be?

I like this idea tho

[fkrause2]

Edit the "+" for --> "+ or -" +x/y Coor

EJ:
foundY:=foundX+50
foundY:=foundY-80

if your img is "100x100"
use:
foundY:=foundX+50 ; 50% of your IMG
foundY:=foundY+50 ; 50% of your IMG
= Center of img.

Code: Select all

ImageSearch, foundX, foundY, 0, 0, %A_ScreenWidth%, %A_ScreenHeight%, YourIMG.png
If(ErrorLevel == 0){
foundY:=foundX+300  ; <--- Edit for + or - Y Coor
foundX:=foundY+300  ; <--- Edit for + or - X Coor
Click, %foundX%, %foundY%
}

[AviationGuy]

@fkrause2, that would, indeed, be the way to go when you know the size of the image you are looking for (and the way I used).
However, my point was to click the center of an image you don't know the size of.

[guest3456]

However, my point was to click the center of an image you don't know the size of.

how would you not know the size of the image, if you are the one who is specifying the image file to search for

[nnnik]

I do agree that AutoHotkey should provide basic stuff like interaction with image files.
However it is also fairly simple to use GDIp to find the size of the image.
From then onwards its a rather simple math problem.

[AviationGuy]

Of course, you can check the image size when you've created it yourself. But when you are making a script that clicks lots of buttons, this feels a bit repetitive to do and AHK is just there to eliminate repetitions.
Next to this, it doesn't feel like that big of a deal to add it to the function (not saying that it needs to be done, just discussing it here )

And why not just give the option as parameters that could be left out within the function?
ImageSearch, FoundX0, FoundY0, X1, Y1, X2, Y2, ImageFile [, FoundX1, FoundY1]-> not the greatest layout but just an example

As I mentioned before, when you use parameters that could be left out, anyone that doesn't want to use them can leave 'm out.

But I think the topic can be closed, thanks for the responses!

[nnnik]

You can probably make a function that does that for you.

[william_ahk]

@Masonjar13 wrote a function for getting the image size
Example function:

Code: Select all

waitclick(img_path, btn := "", times := "", img_options := "") {
    CoordMode, Pixel, Screen
    CoordMode, Mouse, Screen
    loop {
        ImageSearch, found_x, found_y, 0, 0, % A_ScreenWidth, % A_ScreenHeight, % img_options ? img_options " " : "" . img_path
    } until (!errorlevel)
    splitPath,img_path,fN,fD
    
    oS:=comObjCreate("Shell.Application")
    oF:=oS.namespace(fD?fD:a_workingDir)
    oFn:=oF.parseName(fD?fN:img_path)
    size:=strSplit(oFn.extendedProperty("Dimensions"),"x"
        ," ?" . chr(8234) chr(8236))
    
    x := found_x + (size[1]/2)
    y := found_y + (size[2]/2)
    click %x%, %y%, %btn%, %times%
}
waitclick("button.png")