Lockbits in C#

  • Thread starter Thread starter bern11
  • Start date Start date
B

bern11

I have a linked-list of bitmaps drawn on a window - no problem. I want
to convert one of them to Black & White - problem! It just doesn't do
it. I dumbed the routine down to implementing the 'Lockbit' example
code, and no effect. Now, if I call bimap.FlipRotate() first, I can get
it to FlipRotate and go grayscale. the following is the lead-in code:

private void convertToGrayScaleToolStripMenuItem_Click(object
sender, EventArgs e)
{

//ActiveElement.bitmap.RotateFlip(RotateFlipType.Rotate90FlipXY);
// Lock the bitmap's bits.
Rectangle rect = new Rectangle(0, 0,
ActiveElement.bitmap.Width, ActiveElement.bitmap.Height);
BitmapData bmpData =
ActiveElement.bitmap.LockBits(rect,
ImageLockMode.ReadWrite,
PixelFormat.Format32bppArgb);
// Get the address of the first line.
IntPtr ptr = bmpData.Scan0;

int bytes = ActiveElement.bitmap.Width *
ActiveElement.bitmap.Height * 4;
byte[] rgbValues = new byte[bytes];

// Copy the RGB values into the array.
System.Runtime.InteropServices.Marshal.Copy(ptr, rgbValues,
0, bytes);

.... If I un-comment the FlipRotate statement, the function works and I
get a grayscale image (That has been flipped & rotated). If I don't
FlipRotate, no grayscale.
 
Hard to say for sure what the problem is, as there may be more than one.
First, you haven't given us any information about the PixelFormat of the
Bitmap. It looks like you're assuming Format32BppArgb. Assuming that is
correct, you don't seem to be taking "stride" in stride (liitle joke there).

The width of a Bitmap may or may not be width of the number of bytes in each
pixels multiplied by the number of pixels. Take a look at the following
excellent article on Bob Powell's GDI+ FAQ:

http://www.bobpowell.net/lockingbits.htm

--
HTH,

Kevin Spencer
Microsoft MVP
Bit Player
http://unclechutney.blogspot.com

Where there's a Will, there's a William.
 
It isn't a problem with pixel format. I'm using 32 bpp. What I do not
understand is that it works perfectly fine if I do a flip-rotate (I get
a fliped-rotated grayscale image), but does not work if I comment out
the flip-rotate. What I think is happening is:

1) Windows makes a copy of the bitmap in the desired format when I
lock-bits
2) I edit the bits
3) Windows DOES NOT update the master when I unlock bits.

The disk-format is 24 bpp. I just tried an explicit conversion to 32
bpp (clone) before locking. No effect. It is like windows does not
recognize a change in the copied data unless a flip-rotate is called,
then it knows to do step 3.
 
This gets even more fun: If I call the routine twice in a row, the
second time it gets called, the data is grayscaled. I don't understand
why fliprotate makes it work. My bitmap is in a linked-list. I make a
reference to an entry, lock bits on the reference, modify the bits, then
unlock. It doesn't work unless I throw in an extra flip-rotate on the
reference before locking the bits (I haven't tried after...). I could
always flip-rotate twice, but that seems so idiotic....
 
It works like a champ if I create a new LinkedList element with a new
bitmap (new Bitmap(node.value.bitmap)), modify the new bitmap, add it to
the linked list, then delete the old node. Kindof kludgy, but better
than flip-rotate x 2.

It has something to do with references, but I'm not sure what. I've
actually had the same problem in vc++ dot-net, ie. never quite sure if a
reference is to original data or a copy.
 
Like I said, I don't know what is going on internally when you flip it, but
Bob's techniques work perfectly. I have been using them for years.

--
HTH,

Kevin Spencer
Microsoft MVP
Bit Player
http://unclechutney.blogspot.com

In case of Minimalism, break Philip Glass.
 
I just figured it out: A bad install. My test program compiles &
works fine on another PC.
 
Back
Top