bitmap lockbits/unlockbits - C# Discussion Boards

how do you mean?

The application (.exe file) is created after recompiling your source code. Simply changing your code won't automatically recompile the app. So make sure you rebuild (recompile) before running the app. If this doesn't make sense, see this[^] link.

/ravi

My new year resolution: 2048 x 1536
Home | Articles | My .NET bits | Freeware
ravib(at)ravib(dot)com

I have found that doing a clean then a build sometimes helps. I have had to restart VS to get some things to happen. Not sure what problem VS has but it sure seems quirky to me. In the worst cases I have had to manually clean the obj and bin folders. Although that can cause other flaky things.

Jack of all trades, master of none, though often times better than master of one.

I see questions/comments like this quite often here, and yet I have never seen this problem first hand. I don't find VS quirky at all, I find it a very resilient application (even the Express versions).

I think it depends what you are doing.
I didn't find the WPF in 2008 at all robust, and try playing with abstract base UserControls in WinForms and you are heading for a world of pain in any version of VS post 2005! Laugh | :laugh:

Even in 2010 there are some flaky moments when the editor refuses to display any changes - though it applies them to the file just to be annoying...reboot VS fixes it.
It's a complex program, and I guess if you use the flaky bits you get a flaky product - it you use the stable bits you get a stable product! Wink | ;)

Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)

There's a fatal thing in Visual Studio. Normally when a build fails as a result of hitting F5 a little dialog pops up telling you its failed and asking if you want to run the previous version. NEVER select 'don't show this again' as it can be less that obvious that your build has failed and your running an out of date .exe.

If you've done this, that will be why and you need to trawl through the endless settings to undo it.

Regards,
Rob Philpott.

It's sheer brilliance that one can hide that dialog for ever Big Grin | :-D

Bastard Programmer from Hell Suspicious | :suss:

If you can't read my code, try converting it here[^]

I have a small prototype that allows a user to highlight a rectangle on an image. The program will analyze this highlighted portion and change the pixels properties of the pixels. Above a certain treshold it will set it to white, below the treshold the pixel is set to orange.

This stuff works using the SetPixel/GetPixel method, but I read that performance is better with the LockBits/UnlockBits method.
So I tried the following:

C#

System.Drawing.Imaging.BitmapData bmpdata = tmpbmp.LockBits(tmprect, System.Drawing.Imaging.ImageLockMode.ReadWrite, tmpbmp.PixelFormat);
IntPtr pointer = bmpdata.Scan0;
//int nrofbytes = Math.Abs(bmpdata.Stride) * bmpdata.Height;  //stride = scan width
int nrofbytes = bmpdata.Width * bmpdata.Height;  //stride = scan width
byte [] bytes = new byte[nrofbytes];
	
System.Runtime.InteropServices.Marshal.Copy(pointer, bytes, 0, nrofbytes);
System.Drawing.Color color_white = System.Drawing.Color.White;
System.Drawing.Color color_orange = System.Drawing.Color.Orange;
long count = 0;
for(int i = 0; i < bytes.Length-3; i+=3){
	if(bytes[i] > 235 && bytes[i+1] > 235 && bytes[i+2] > 235){
		bytes[i] = color_white.R;
		bytes[i+1] = color_white.G;
		bytes[i+2] = color_white.B;
	}											//end if
	else{
		count++;
		bytes[i] = color_orange.R;
		bytes[i+1] = color_orange.G;
		bytes[i+2] = color_orange.B;
	}											//end else
}												//end for
System.Runtime.InteropServices.Marshal.Copy(bytes, 0, pointer, nrofbytes);
tmpbmp.UnlockBits(bmpdata);

This doesn't work in the sense that the highlighted part is:
1. not white/orange, but rather white/gray
2. it changes entire rows of the image instead of the rectangle portion I passed.

for 1. it might be some sort of index offset, I guess.
I'm pretty sure the culprit for 2. is this line:

C#

System.Runtime.InteropServices.Marshal.Copy(bytes, 0, pointer, nrofbytes);

but I'm not sure why or how to solve it.
Anyone have any experience with this?

Many thanks.

V.

(MQOTD rules and previous solutions)

Hmm. Tricky, it sounds like things have got out of alignment.

As I recall, stride may not be exactly the width of a line as I think word alignment comes into it. (Not 100% on that). Also nrofbytes = stride * height * bits per pixel / 8. I don't think you array is large enough, multiply by 3 at least.

Also there seems to be some implicit assumption that you have one byte per RGB channel - is this guaranteed? Often you have an alpha channel as well which is nice as it makes each pixel a pleasing 32 bits. That might explain the greys you are seeing.

And I think:

for(int i = 0; i < bytes.Length-3; i+=3

should be:

for(int i = 0; i < bytes.Length; i+=3)

Regards,
Rob Philpott.

Tricky answer Smile | :)

.

PixelFormat is set to Format24bppRgb so it "should" be just RGB.
I modified the array size to:

C#

int nrofbytes = bmpdata.Width * bmpdata.Height * 3;

in debug I noticed that height and width are pixels and Stride is Bytes so you indeed need to use stride or multiply the Height Width with 3.

The result remains the same though, the image changes the complete rows. (this time in black and white)
I'll keep on looking.

thanks for the tips!

V.

(MQOTD rules and previous solutions)

With 24 bbp your shoudl compute number of bytes like this:

C#

nrofbytes = Math.Abs(bmpdata.Stride) * tmpbmp.Height;

And the order of RGB in the array is
0 - B
1 - G
2 - R

I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)

Sorry to bother you again, but I changed the algorithm so the entire image is "converted". It doesn't do what I want, yet, but it does what I expect it to do. Except for one thing: The image appears to be converted to grayscale somehow. Debug shows the bytes are set to (0,128,0) which is green, but the result is always gray. I tried with gray and lightgray instead of green and this works. (or seems to work, there is a clear difference in the gray scale).
I set it to BGR instead of RGB and I also tried to add the alpha component (setting pixelformat to 32 in that case).

I'm confused because the original image is a jpg with bit dept 24 and is read in as a bmp with PixelFormat = Format24bppRgb.
The Set/Get pixel method does allow colors.

Google didn't give me any results on this.

thanks.

V.

(MQOTD rules and previous solutions)

If you do not touch the color values at all (comment out the bytes[i] lines) it is still grayed out?

I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)

Nope, it doesn't change a thing to the image.

V.

(MQOTD rules and previous solutions)

I can't be sure, but it seems that something is wrong with the indexing of your buffer, I mean you write at the wrong positions...Review you calculations...
(If you got nowhere I have no objection that mail me with your project and a simple image too, I will do my best to see into it ASAP)

I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)

Just tried with a real color image and that turned green entirely Wink | ;-)

.
Could it be that the jpg has some sort of "grayscale" flag that is copied to the bitmap properties?

I'll try to not bug you too much with this, it's my job to figure it out, I was just hoping to get a lead.
(And you were great help so far, so thanks for that)

(the goal is that I open a scanned image and highlight features on it for surface calculation. The image "looks" grayscale since they are pencil drawings of sunspots[^].)

V.

(MQOTD rules and previous solutions)

It can be that your image is indexed with some color table. In that case every color will be converted to the closest entry in that table...
You may create an new - non indexed - image of the proper size, than copy (http://msdn.microsoft.com/en-us/library/aa457087.aspx[^]) the original over it...In this way you will get the same image as a non indexed...

I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)

And it turns green ! Smile | :)

I added the following function:

C#

private System.Drawing.Bitmap CreateNonIndexedImage(System.Drawing.Bitmap bmp){
	System.Drawing.Bitmap newbmp = new System.Drawing.Bitmap(bmp.Width, bmp.Height, System.Drawing.Imaging.PixelFormat.Format32bppRgb);
	System.Drawing.Graphics g = System.Drawing.Graphics.FromImage(newbmp);
	g.DrawImage(bmp, 0, 0);
	return newbmp;			
}

but I overlooked the fact I reload a temp image when performing the lockbits part D'Oh! | :doh:

.

thanks for the help, I really appreciate it!
Now to just highlight the rectangle insteacd of the entire image Roll eyes | :rolleyes:

V.

(MQOTD rules and previous solutions)

I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)

I think you problem is that stride and width are not the same. Width is the actual width of the image in pixels but stride is the number of bytes a single image line takes, rounded up to multiplies of 4...
You also have to see into Pixel format, it may be different from simple RGB and in that case your loop writes wrong positions and/or wrong colors...

I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)

Actually width and height in the bitmapdata object is equal to the rectangle I passed in which is just a part of the image, but not the image itself. I'm wondering if this can even work as we copy the array back into the image, only providing the start address. My guess is it will just start at that address and copy the array sequentially back into that image?

should I rather read in the entire image and only replace the pixels when I reach the index inside the rectangle?

pixelformat is set to 24 bpp.
In code I do something like this :

C#

bmp = bmp.Clone(new System.Drawing.Rectangle(0,0, bmp.Width, bmp.Height),System.Drawing.Imaging.PixelFormat.Format24bppRgb/*Format32bppArgb*/);

Since I never know what format the jpg/bmp file is.

Many thanks for your help (I'm new at this so I'm figuring it out as I go)

V.

(MQOTD rules and previous solutions)

It may be hard to explain, as no images allowed here, but I will give a try...
When you are copy only the part of an bitmap image the byte array that you holds only the part you asked for - that obvious I think and expected too...
But! That also mean that you have to compute the stride for that part only, as the lock method will provide you with scans (lines) padded to stride and not of length of width!
You can compute the stride like this:

C#

int bitsPerPixel = ((int)format & 0xff00) >> 8;
int bytesPerPixel = (bitsPerPixel + 7) / 8;
int stride = 4 * ((width * bytesPerPixel + 3) / 4);

You may consider one of these options too:
1. Lock all the bitmap and use x,y,width,height as an index inside it (no extra computations of stride as BitmapInfo already have it)
2. Create a new bitmap out of the wanted portion and go back to 1

I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)

I think you just verified what I was thinking Smile | :)

thanks!

V.

(MQOTD rules and previous solutions)

Anyone please explain c# classes in detail with examples.

Nobody's going to take the time to explain that to you. You'll have to take the trouble to get your head around it yourself. Here's a start: Object-Oriented Programming Principles[^] (video).

/ravi

My new year resolution: 2048 x 1536
Home | Articles | My .NET bits | Freeware
ravib(at)ravib(dot)com