Jump to content
Sign in to follow this  
nullschritt

Getting image pixel data.

Recommended Posts

nullschritt

So you know the data will be retreived in memory.
 
I'm trying to get the color of every pixel in an image for comparison.
 
I have a script that work but it takes 25 seconds for a 1000x1000 image, which seems way too high, as i can compare said data in just 100ms. I suspect that _GDIPlus_BitmapGetPixel is a slow function. Is there an alternative?

#include <_PixelGetColor.au3>
#include <GDIPlus.au3>

;~ ToolTip(1)

$hDll = DllOpen("gdi32.dll")
;$vDC = _PixelGetColor_CreateDC($hDll)

;~ ToolTip(2)

;~ $a = TimerInit()
;~ CaptureNative($testMaxX, $testMaxY)
;~ $a1 = TimerDiff($a)

;~ ToolTip(3)
_GDIPlus_Startup()
$file = FileOpenDialog("Select an image", @ScriptDir, "All Files(*.*)")
$b = TimerInit()
$ret = CapturePixels(Binary(FileRead($file)))
$b1 = TimerDiff($b)
;~ ToolTip(4)
;_PixelGetColor_ReleaseDC($vDC, $hDll)
;~ DllClose($hDll)

;~ ToolTip(5)

ConsoleWrite("Time   : " & $b1 & @CRLF)


Func CapturePixels($data)
    $ret = ""
    $HBITMAP2 = _GDIPlus_BitmapCreateFromMemory($data)
    $y=_GDIPlus_ImageGetWidth($HBITMAP2)
    $x=_GDIPlus_ImageGetHeight($HBITMAP2)

    For $iY = 0 To $y
        For $iX = 0 To $x
            $ret &= _GDIPlus_BitmapGetPixel($hBitmap2, $iX, $iY) ;get current pixel color
        Next
    Next

       ;For $x = 0 To _GDIPlus_ImageGetWidth($HBITMAP2)
       ;  For $y = 0 To _GDIPlus_ImageGetHeight($HBITMAP2)
       ;      $ret &= _PixelGetColor_GetPixel($vDC, $x, $y, $hDll)
      ;   Next
     ;Next
    _WinAPI_DeleteObject($HBITMAP2)
    Return $ret
EndFunc   ;==>Capturepixels
Edited by nullschritt

Share this post


Link to post
Share on other sites
FireFox

Hi,

If you're looking for speed, autoit is not a good choice.

The GDIPlus functions are not related to autoit but are from an external DLL, so the efficiency will be the same for any language calling the library.

Br, FireFox.


 

OS : Win XP SP2 (32 bits) / Win 7 SP1 (64 bits) / Win 8 (64 bits) | Autoit version: latest stable / beta.
Hardware : Intel(R) Core(TM) i5-2400 CPU @ 3.10Ghz / 8 GiB RAM DDR3.

My UDFs : Skype UDF | TrayIconEx UDF | GUI Panel UDF | Excel XML UDF | Is_Pressed_UDF

My Projects : YouTube Multi-downloader | FTP Easy-UP | Lock'n | WinKill | AVICapture | Skype TM | Tap Maker | ShellNew | Scriptner | Const Replacer | FT_Pocket | Chrome theme maker

My Examples : Capture toolIP Camera | Crosshair | Draw Captured Region | Picture Screensaver | Jscreenfix | Drivetemp | Picture viewer

My Snippets : Basic TCP | Systray_GetIconIndex | Intercept End task | Winpcap various | Advanced HotKeySet | Transparent Edit control

 

Share this post


Link to post
Share on other sites
nullschritt

I meant is there some other way than gdi to get the pixels of the image? There has to be a faster way of doing this.

Share this post


Link to post
Share on other sites
Myicq

nullschritt: I have been over the same, although not for comparison reasons. What format is your input picture, and do you have it as a file or in a screenshot ?

You could look at the file as a string of bytes, depending on the format (color depth) you would need 1/8, 1, 2, 4 bytes per pixel.

Could you get some more details.


I am just a hobby programmer, and nothing great to publish right now.

Share this post


Link to post
Share on other sites
nullschritt

nullschritt: I have been over the same, although not for comparison reasons. What format is your input picture, and do you have it as a file or in a screenshot ?

You could look at the file as a string of bytes, depending on the format (color depth) you would need 1/8, 1, 2, 4 bytes per pixel.

Could you get some more details.

 

It's not relevant where the image comes from. It's purpose is to compare any two images, and find their difference, I don't see how the source of the images is relevant.

Also I dont understand your meaning about looking at the string as bytes, wouldnt that require a conversion anyways? (basically what my tonum function is doing)

Edit: Logcally there must be a faster way, it doesnt take 60-120 seconds for said image to be displayed on an image control, so I guess, how does the image control convert the bitmap data into their respective colors so quickly? Is there a way to mimic this process?

Edited by nullschritt

Share this post


Link to post
Share on other sites
junkew

within the findbmp thread

see

; Load the bitmap to search in
    getImage($BMP1, $BMP1Data, $BMP1Width, $BMP1Height, $BMP1LineWidth, $imgBytes)
    $BMP1Data = BinaryToString($BMP1Data)

depending on the colordepth of your image you have 1,2,3,4 bytes per pixel of colordata

if its a 24 bit color image you have RGB (or BGR) colors which is 1 byte for red, 1 for Green and 1 for Blue

the bitmapgetpixelcolor gives back a 32 bit color in alpha, red, green, and blue (ARGB)

so in above small code example $BMP1Data is just a long list of colors of all pixels and to get 1 pixel color of x=1, y=1 you just look at the first 3/4 bytes

edit: see also '?do=embed' frameborder='0' data-embedContent>>

Edited by junkew

Share this post


Link to post
Share on other sites
nullschritt

within the findbmp thread

see

; Load the bitmap to search in
    getImage($BMP1, $BMP1Data, $BMP1Width, $BMP1Height, $BMP1LineWidth, $imgBytes)
    $BMP1Data = BinaryToString($BMP1Data)

depending on the colordepth of your image you have 1,2,3,4 bytes per pixel of colordata

if its a 24 bit color image you have RGB (or BGR) colors which is 1 byte for red, 1 for Green and 1 for Blue

the bitmapgetpixelcolor gives back a 32 bit color in alpha, red, green, and blue (ARGB)

so in above small code example $BMP1Data is just a long list of colors of all pixels and to get 1 pixel color of x=1, y=1 you just look at the first 3/4 bytes

edit: see also '?do=embed' frameborder='0' data-embedContent>>

So each pixel would be how many bytes in length?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.