Fast picture masking

What is the fastest way to create the mask of picture?

Here's the code I wrote:

Code:

---

Public Function Mask(Color As Long) As Boolean
    Dim i As Long
    Dim j As Long
   
    Mask=false

    If bValidSprite Then
        For i = 0 To lSpriteWidth - 1
            For j = 0 To lSpriteHeight - 1
                If GetPixel(DCSprite, i, j) = Color Then
                    Call SetPixel(DCMask, i, j, vbWhite)
                Else
                    Call SetPixel(DCMask, i, j, vbBlack)
                End If
            Next j
        Next i
        bValidMask = True
        Mask=true

    End If

End Function

---

Thanks Xmas.

change the i and j longs to integers.
change 'next i' and 'next j' to only 'next'
and use setpixelv instead of setpixel...
if you are using a picturebox, use ScaleMode 3

if you're using a picturebox with scalemode = 3, use scalewidth and scaleheight instead of width and height...

Quote:

---

Originally posted by cyborg
change the i and j longs to integers. slower
change 'next i' and 'next j' to only 'next' bad coding practice
and use setpixelv instead of setpixel... good
if you are using a picturebox, use ScaleMode 3 irrelevant

---

For best performance, use Get/SetDIBits.

hmm.... i've heard that integer is the fastest variable type...

if scalemode are set to 1 - twips, there are about 15 times more pixels to check...or did i get it wrong?

Ok for setpixelv... I'm using DCs into memory. How better performance with Get/SetDIBits ?

Integers don't have to be the fastest variable type. We had this discussion a couple a weeks ago.

http://www.vbforums.com/showthread.p...hreadid=211533

Here it is, it's very complex code, so I'll walk through it with you:

VB Code:

Public Function Morph2D(X As Long, Y As Long, NumRow As Long) As Long
    Morph2D = (Y - 1) * NumRow + X
End Function
Public Function Mask(Color As Long) As Boolean
Dim Co As mLong
 
Dim sBitmap As Long
Dim sBMP As BITMAP
Dim sPic() As mRGB
Dim sMem As BITMAPINFO
Dim mBitmap As Long
Dim mBMP As BITMAP
Dim mPic() As mRGB
Dim mMem As BITMAPINFO
 
Dim i As Long
Dim j As Long
 
    sBitmap = GetCurrentObject(DCSprite, OBJ_BITMAP)
    GetObjectAPI sBitmap, Len(sBMP), sBMP
    With sMem.bmiHeader
        .biBitCount = 32
        .biCompression = BI_RGB
        .biPlanes = 1
        .biSize = Len(sMem.bmiHeader)
        .biWidth = sBMP.bmWidth
        .biHeight = sBMP.bmHeight
        ReDim Preserve sPic(0 To (.biWidth * .biHeight) - 1) As mRGB
    End With
    GetDIBits DCSprite, sBitmap, 0, sBMP.bmHeight, sPic(0), sMem, DIB_RGB_COLORS
 
    mBitmap = GetCurrentObject(DCMask, OBJ_BITMAP)
    GetObjectAPI mBitmap, Len(mBMP), mBMP
    With mMem.bmiHeader
        .biBitCount = 32
        .biCompression = BI_RGB
        .biPlanes = 1
        .biSize = Len(mMem.bmiHeader)
        .biWidth = mBMP.bmWidth
        .biHeight = mBMP.bmHeight
        ReDim Preserve mPic(0 To (.biWidth * .biHeight) - 1) As mRGB
    End With
    GetDIBits DCMask, mBitmap, 0, mBMP.bmHeight, mPic(0), mMem, DIB_RGB_COLORS
    
    Mask=false
 
    If bValidSprite Then
        For j = 0 To lSpriteHeight - 1
            For i = 0 To lSpriteWidth - 1
                LSet Co = sPic(Morph2D(i, lSpriteHeight - j, lSpriteWidth)) 
                If Co.L = Color Then
                    Co.L = 0
                Else
                    Co.L = RGB(255, 255, 255)
                End If
                LSet mPic(Morph2D(i, lSpriteHeight - j, lSpriteWidth)) = Co
            Next i
        Next j
        bValidMask = True
        Mask=true
        
    SetDIBits DCMask, mBitmap, 0, mBMP.bmHeight, mPic(0), mMem, DIB_RGB_COLORS
 
    End If
 
End Function

I'm still not sure how to do the cleanup in this code, but I'm sure it would be deleting the bitmaps and BMPs, etc. Here are the declarations:

VB Code:

Public Const BI_RGB = 0&
Public Const DIB_RGB_COLORS = 0
Public Type mLong
    L As Long
End Type
Public Type mRGB
    R As Byte
    G As Byte
    B As Byte
    A As Byte
End Type
Public Type BITMAP
    bmType As Long
    bmWidth As Long
    bmHeight As Long
    bmWidthBytes As Long
    bmPlanes As Integer
    bmBitsPixel As Integer
    bmBits As Long
End Type
Private Type BITMAPINFOHEADER '40 bytes
    biSize As Long
    biWidth As Long
    biHeight As Long
    biPlanes As Integer
    biBitCount As Integer
    biCompression As Long
    biSizeImage As Long
    biXPelsPerMeter As Long
    biYPelsPerMeter As Long
    biClrUsed As Long
    biClrImportant As Long
End Type
Public Type BITMAPINFO
    bmiHeader As BITMAPINFOHEADER
    bmiColors As mRGB
End Type
Public Declare Function GetDIBits Lib "gdi32" (ByVal aHDC As Long, ByVal hBitmap As Long, ByVal nStartScan As Long, ByVal nNumScans As Long, lpBits As Any, lpBI As BITMAPINFO, ByVal wUsage As Long) As Long
Public Declare Function SetDIBits Lib "gdi32" (ByVal hdc As Long, ByVal hBitmap As Long, ByVal nStartScan As Long, ByVal nNumScans As Long, lpBits As Any, lpBI As BITMAPINFO, ByVal wUsage As Long) As Long
Public Declare Function GetCurrentObject Lib "gdi32" (ByVal hdc As Long, ByVal uObjectType As Long) As Long
Public Declare Function GetObjectAPI Lib "gdi32" Alias "GetObjectA" (ByVal hObject As Long, ByVal nCount As Long, lpObject As Any) As Long

This is what the code does, step by step. First, it get's the hDC's bitmap pointer. Then, it takes this and, from it, gets the actual bitmap's info. After this, it fills in the values for a normal bitmap in the header, since from a DC this is one of the two things we don't get back (if you sent it a picture, you'd be able to get it all back, but we'd have to modify the code heavily). The other thing it doesn't get back is the actual bitmap data (sBMP/mBMP.bmBits), so we get this with GetDIBits. Now we have a one-dimensional array holding all of our bytes.

Now, you see all these Morph2D calls in there. They get the one-dimensional index from a two-dimensional one (one-dimensional arrays are faster so that's why they are used). And, GetDIBits returns the bitmap upside-down, so we always use Height - J to get the real Y value.

The LSet value puts any value into any other value (like putting a type with two bytes in it into an integer). In this case, we're assigning two long values to a 4-byte type, and since long is 4 bytes, it fills up the type nicely with the R, G, B data we want.

After this, we use SetDIBits to put the bits back to the DC from whence they came. I think that's it, but I haven't tested the code yet, so if there are any errors (and probably stupid ones), let me know.

Quote:

---

Originally posted by cyborg
if you're using a picturebox with scalemode = 3, use scalewidth and scaleheight instead of width and height...

---

ScaleWidth and ScaleHeight should be used regardless of the ScaleMode. No matter what mode you're in, if the border's still there, Width and Height are going to give you inproper values.

yep

NoteMe, i tried your variable test program...
it showed me that integer was the fastest!

Long = 0,9574 ms
Integer = 0,9092 ms

How many times did you try it? Did you try to switch the order of the two tests? Those who have most often got the result of the integer test using nearly twice the time of long.

But Sastraxi posted a better way to time the test. I used his code (I hope he doesn't mind me using it) to developed a test for both variable types. Try this.

Ops...forgot the attachment...

Thanks, NoteMe, I don't mind at all, I love it when others use my code :)

So, long came up 7.3 s and integer was 9 s (with Winamp running). A second test, using integer first, came up with 7.7 for integer and 7.3 for long. So, in both tests, longs were faster ;) And I'm about to make changes to some code, as it's wrong...

Quote:

---

Originally posted by NoteMe
How many times did you try it? Did you try to switch the order of the two tests? Those who have most often got the result of the integer test using nearly twice the time of long.

But Sastraxi posted a better way to time the test. I used his code (I hope he doesn't mind me using it) to developed a test for both variable types. Try this.

---

All the times I've tested it, the differences were always in milliseconds, not nearly twice as long.

The Hobo: Did you try the new test. I think you would get a more precise test result using

Quote:

---

Originally posted by NoteMe
The Hobo: Did you try the new test. I think you would get a more precise test result using

---

"The New Test?" I didn't know time comparisons came with updates...

I didn't know you where a comedian HOBO. But don't try to make any money on it. You wouldn't get rich. But seriously you should try the OTHER TEST.....

Quote:

---

Originally posted by NoteMe
I didn't know you where a comedian HOBO. But don't try to make any money on it. You wouldn't get rich. But seriously you should try the OTHER TEST.....

---

Dude. Seriously. I don't know what you're talkinga bout? What's 'the other test?' In that matter, what do you refer to as the 'old test?'

He posted a link to a thread, and then a few posts later made a post with an EXE. These were the two tests if I'm not mistaken... a simple miscommunication guys; NoteMe thought that you (Hobo) were talking about his first test in your post "all the times i've tested it....", and it all went downhill from there.

Oh. I didn't even see his post or his attachment.

NoteMe: I wasn't trying to be an ass our anything. In the first post, yes I was joking around, but I didn't mean for it to be offensive or anything. I was interested in seeing what you meant.

long should be the faster datatype, according to MS, long is the 32 bit native datatype, so the compiler has less work to do, but if those tests say otherwise, i can't exactly argue.

It is true, and is even more noticable in the IDE (usually). On mine (my celeron has the worst fricken' FPU), they are very close. But it may have nothing to do with the FPU... it probably doesn't.... why am I posting th--

I just went cross-eyed... :D

Ok guys... Just stop discussing on longs and integers... The best method of improving performance is to improve algorithms, and not changing longs to bytes or boolean or whatever... Sure data alignment is important for fast data transfer. But if I have to do an array of colors, if I use bytes or longs is the same thing. I can read up to 4 bytes at time and put them on a long (I don't think vb can do this, but C sure can). If I really want to speed up things without optimizing algorithms I MUST program in assemby... Or at least in C... But windows programming in C isn't easy, a LOT of costants and a LOT of API calls... You just enter into Windows specifics... And it is so hard to make a simple "hello world" application from scratch (and without the template ;)), think about making a game!!! VB is the most productive programming language, you can do everything (almost) in a short time...

Sastraxi:

Thanks for code... At first look I can understand nothing... Maybe I'll get more in feel with it looking, and looking, and overlooking at it :D

Cyborg:
Thanks for SetPixelV, but I want accurate colors :(

Thx Xmas

xmas79:
accurate colors?
dont they get accurate with setpixelv?

from MSDN:

Quote:

---

The SetPixelV function sets the pixel at the specified coordinates to the closest approximation of the specified color. SetPixelV is faster than SetPixel because it does not need to return the color value of the point actually painted.

---

Maybe the approximation is not noticeable, I think it depends from the type of device you write to... About the speed, the difference with SetPixel is an assignment at the end of the "job"... In assembly means:

Code:

---

' Assuming that the eax register is modified,
'Maybe I can pop the color from the stack:
...
Pop eax
Ret

'Or if the eax register is not modified at all, simply:
...
Ret

---

These are a one cycle clock instructions (from Pentium I to ....), so I don't think the speed gain is noticeable... Maybe anyone has tested it ???
Tomorrow I'll do the test and post code (if anybody else do)...

Good night,
Xmas.