Pixel/image search from bottom to the top or from right to left

[apolonas]

Sometimes ur image usually appears at the bottom left or right of your searching area . To avoid false positives and also speed up the prosses ahk should allow the user to search from buttom to the top or from right to left.

example code this works

Code: Select all

ImageSearch(&ix, &iy, A_screenwidth/4, 0, (A_screenwidth- A_screenwidth/4), A_screenheight/2, "*" varient " " A_ScriptDir "\img.png")

this is not allowed

Code: Select all

ImageSearch(&ix, &iy,  A_screenwidth/4 , A_screenheight/2, (A_screenwidth- A_screenwidth/4),0,"*" varient " " A_ScriptDir "\img.png")

image.png (33.48 KiB) Viewed 1133 times

[apolonas]

After a lot of searching I find something It's not perfect but it does the job.
https://github.com/Spawnova/ShinsImageScanClass
Check out what this dude did it's very good.




This function

Code: Select all

#ImageRegion..............Find an image in a specified region; Returns 1 on success and updates returnX and returnY variables; 0 otherwise
ImageRegion(image, x1, y1, w, h, variance=0, ByRef returnX=0, ByRef returnY=0, centerResults=0, scanDir:=0)

is on point I think something like this sould be implemented in ahk.

Code: Select all

	;####################################################################################################################################################################################################################################
	;ImageRegion
	;
	;image				:				Path to image file
	;x1					:				Top left starting x position
	;y1					:				Top left starting y position
	;w					:				Width of pixels to search, starting from x1
	;h					:				Height of pixels to search, starting from y1
	;variance			:				Value between 0-255, determines how close/far pixels must be to match the target color
	;&returnX			:				Variable to store the x result into
	;&returnY			:				Variable to store the y result into
	;centerResults		:				Return the results centered on the image
	;scanDir			:				Scanning direction, default = LRTB (scan left to right, from top to bottom)
	;
	;return				;				Returns 1 if the image was found in the specified region; 0 otherwise
	
	ImageRegion(image,x1,y1,w,h,variance:=0,&returnX:=0,&returnY:=0,centerResults:=0,scanDir:=0) {
		if (!this.CacheImage(image))
			return 0
		if (this.AutoUpdate)
			this.Update(x1,y1,w,h)
		data := DllCall(this._ScanImageRegion,"Ptr",this.dataPtr,"Ptr",this.imageCache[image],"int",(this.autoUpdate?0:x1),"int",(this.autoUpdate?0:y1),"int",w,"int",h,"uchar",variance,"uchar",centerResults,"int",this.scanTypes[scanDir],"int")
		if (data >= 0) {
			this.MapCoords(data,&returnX,&returnY)
			return 1
		}
		return 0
	}

I just found the creator of this script on this forum @Spawnova goodjob!

[lexikos]

PixelSearch already allows this.

The search order depends on the order of the parameters. In other words, if X1 is greater than X2, the search will be conducted from right to left, starting at column X1. Similarly, if Y1 is greater than Y2, the search will be conducted from bottom to top.

For reasons described below, I am unlikely to make any changes to ImageSearch itself. However, if someone submits a pull request implementing something like the above, I may merge it (the chances are better if it includes automated tests demonstrating that there are no unwanted changes to behaviour).

ImageSearch Optimizations

Some optimizations to the algorithm used by ImageSearch were developed in collaboration with Rseding91 in 2012. The new algorithm also supported variable transparency in the "needle" image, and an option to control search direction (which PixelSearch now handles by changing the order of the X/Y parameters). I lost motivation to complete the project because of the need for testing to ensure all changes in result are acceptable, combined with the fact that I don't actually use ImageSearch.

Another issue is that systems with the Desktop Window Manager enabled became the norm, and that creates a massive bottleneck for ImageSearch. When it retrieves image data from the screen, the DWM has to basically render a composite image from all of the visible window surfaces. Retrieving image data from a window is faster and has the side benefit that it can usually retrieve data that is visually obscured by other windows.

At some point I want to implement a new interface for image searching and integrate the optimized algorithm. The new interface might support creating bitmaps from a window, a portion of the screen, a file, or a GDI bitmap, and then searching for one bitmap within another bitmap, or searching for a pixel within a bitmap. It may also support calculating a hash of the bitmap data, such as for detecting when a portion of the screen is updated. A mask or alpha channel could be applied to bitmap data in order to detect changes in irregular portions of the screen.

However, as I have many ideas that are more widely beneficial, and I don't use ImageSearch, I probably won't work on this in the near future.

Source: Thoughts for v2.0

I am willing to share the 2012 code if someone wants to take over.

Alternatively, if someone wants to make up a script and some image files to automate testing and benchmarks (covering ImageSearch's current behaviour and capabilities), I might work on this sooner. Full automation is preferred, with a pass/fail report for each test. I think my past method of testing was just opening images and manually placing them on the screen, or taking arbitrary cuts out of screenshots.