[Aequitas1]

I've recently saved off my pixel and palette information of my 8-bit bitmap like this:

	int dataSize = (width * height * (unsigned int)(bmih.biBitCount / 8.0));

	//calculate the number of available colours
	int numColours = 1 << bmih.biBitCount;

	colours = new RGBQUAD[numColours];
	fread(colours, sizeof(RGBQUAD), numColours, bitmap);

	data = new char[dataSize];

	//Return false if there is not enough memory.
	if (NULL == data) 
	{
		fclose(bitmap);
		return false;
	}

	fread(data, sizeof(char), dataSize, bitmap);

	fclose(bitmap);

However, I'm still a bit in the dark about how to loop through the pixels utilising x and y positions and retrieving their colours.

This post has been edited by Aequitas1: 03 June 2012 - 04:39 PM

[snoopy11]

Well Im not sure why you would want to do that, but...

There is the GetPixel function..

COLORREF clr;
BITMAP bm;
int nRow, nCol;

for (nRow = 0; nRow < bm.bmHeight; nRow++)
for (nCol = 0; nCol < bm.bmWidth; nCol++)
clr = GetPixel(hdcbmp, nCol, nRow);

it does require the bitmap is loaded into a dc though.

Can you explain exactly what you are trying to do ?


Snoopy.

[Aequitas1]

My app is a console app. Are there alternatives to using a dc? I'm attempting to crop an image to the border as soon as a colour change is picked up. I'm attempting to do this without using any external libraries so as to familiarise myself with the bitmap file format in depth.

[Aequitas1]

I've further made an RGB format from my prior information, all I need now is to crop it as stated before. Here is the format my pixel data is in now. This is where I'm mostly a bit vague. What would be the best way to detect a colour change?

	for (int i = 0; i < dataSize * RGB_BYTE_SIZE; i += 3) 
	{
		*(data + i) = colours[*(tempData + j)].rgbRed;
		*(data + i + 1) = colours[*(tempData + j)].rgbGreen;
		*(data + i + 2) = colours[*(tempData + j)].rgbBlue;

		j++;
	}

This post has been edited by Aequitas1: 04 June 2012 - 03:21 AM

[Skydiver]

<sarcasm>If one pixel's color doesn't equal an adjacent pixel's color, it sounds like a color change to me.</sarcasm>

Almost all image processing books have algorithms for "edge detection", I suggest cracking yours open and to see what it has to say.

Personally, I think that trying to find edges in RGB is hard. If I had to, I would look at converting to grayscale and then just having some epsilon value that if exceeded would denote a color change.

[Aequitas1]

Thanks Skydiver, that was very informative. I unfortunately don't have any books on image processing, so I don't have access to these algorithms.

[Aequitas1]

What would the technique be to compare an adjacent pixel's colour? I think I could achieve what I'm wanting to just by doing said comparison. How are the pixel positions laid out in the array?

[baavgai]

I really don't understand this:

for (int i = 0; i < dataSize * RGB_BYTE_SIZE; i += 3) 

You're really not giving enough to work with here, you know. But, hey, I like mysteries...

From RGBQUAD I'm going to assume Windows. That would make bmih of type BITMAPINFOHEADER, which has a biBitCount member, so I think I'm good.

I suppose I'd start here: http://msdn.microsof...v=vs.85%29.aspx

[Aequitas1]

You are correct in assuming it's windows. I had a look at the link, as I stated I'm already storing the bitmap data.

[snoopy11]

Aequitas1, on 04 June 2012 - 09:42 AM, said:

My app is a console app. Are there alternatives to using a dc? I'm attempting to crop an image to the border as soon as a colour change is picked up. I'm attempting to do this without using any external libraries so as to familiarise myself with the bitmap file format in depth.

You can just create a memory dc using

CreateCompatibleDC

CreateCompatibleDC

use it like this

HDC hdc, hdcMem;
hdc = GetDC(NULL);
hdcMem = CreateCompatibleDC(hdc);

after that it depends on what you have to work with either a BITMAP or a HBITMAP

Which is it any clues

I too love a mystery as much as the next baavgai

but this is getting ridiculous..


Snoopy.

This post has been edited by snoopy11: 04 June 2012 - 06:48 AM

[baavgai]

And once you have that hdc, use this: http://msdn.microsof...y/aa928105.aspx

The windows BITMAP is a complex data object and you should be doing everything you can to manipulate it with the functions offered to you. Don't assume the collection of bytes in memory behaves in any linear or logical way, because chances are it doesn't.

[snoopy11]

baavgai, on 04 June 2012 - 03:15 PM, said:

And once you have that hdc, use this: http://msdn.microsof...y/aa928105.aspx

The windows BITMAP is a complex data object and you should be doing everything you can to manipulate it with the functions offered to you. Don't assume the collection of bytes in memory behaves in any linear or logical way, because chances are it doesn't.

Yep,

When you are right...

you are right..

chances are it definitely wont

Snoopy.

[Skydiver]

Aequitas1, on 04 June 2012 - 04:54 AM, said:

What would the technique be to compare an adjacent pixel's colour? I think I could achieve what I'm wanting to just by doing said comparison. How are the pixel positions laid out in the array?

Your comparison can be as simple as:

bool colorChanged = (pixel 1 color != pixel 2 color);
where
    pixel i color is picked up from the bitmap using GetPixel() as suggest above.

Since you pass in the coordinates to GetPixel() you know exactly where the pixels are. If you start seeing a set of coordinates that are adjacent to each other, you must have found an edge.

[Skydiver]

baavgai, on 04 June 2012 - 06:28 AM, said:

I really don't understand this:

for (int i = 0; i < dataSize * RGB_BYTE_SIZE; i += 3) 

You're really not giving enough to work with here, you know. But, hey, I like mysteries...

From RGBQUAD I'm going to assume Windows. That would make bmih of type BITMAPINFOHEADER, which has a biBitCount member, so I think I'm good.

I suppose I'd start here: http://msdn.microsof...v=vs.85%29.aspx

And to add to the mystery, in the original post, his claim was that he was storing his bitmap as an 8-bit bitmap, but the code posted in post #4 seems to indicate that it is actually a 24-bit bitmap.

[baavgai]

Image formats are quirky. A GIF usually as a 256 color pallet, but the colors in that pallet are 24. Old bitmaps use run length encoding. Some later ones used odd local pallets. EGA had this really neat thing that involved interlaced scan lines. VGA used bit overlays.

Man, I just had a direct screen write flashback... Today, they often say bugger all, store the value, and just squish it with a standard compression algo.

Again, you use the functions given to you for the data object. It is NOT what you think it is.