Extracting RGB channels

[rogene]

Geez! What am I missing here? Why aren't I able to seperate out the rgb channels?

Thanks!

-R


// Lock & Scan
BitmapData^ imageData = bitmap->LockBits(rect, ImageLockMode::ReadOnly,bitmap->PixelFormat);
Ipp8u* ippImage = (Ipp8u*) ((imageData->Scan0).ToPointer());
int stride = imageData->Stride;

// check rgb values
int y = 0;
for (int i = 0; i < height; i++) {
for (int j = 0; j < stride; j++) {
int pixel = *(ippImage + y);
if (j < width) {
int r = (pixel & 0xff0000) << 16;
int g = (pixel & 0x00ff00) << 8;
int b = (pixel & 0x0000ff);
Console::WriteLine(r + " " + g + " " + b);
}
y++;
}
}

[matthieu_darbois]

Quoting - rogene

Geez! What am I missing here? Why aren't I able to seperate out the rgb channels?

Thanks!

-R


// Lock & Scan
BitmapData^ imageData = bitmap->LockBits(rect, ImageLockMode::ReadOnly,bitmap->PixelFormat);
Ipp8u* ippImage = (Ipp8u*) ((imageData->Scan0).ToPointer());
int stride = imageData->Stride;

// check rgb values
int y = 0;
for (int i = 0; i < height; i++) {
for (int j = 0; j < stride; j++) {
int pixel = *(ippImage + y);
if (j < width) {
int r = (pixel & 0xff0000) << 16;
int g = (pixel & 0x00ff00) << 8;
int b = (pixel & 0x0000ff);
Console::WriteLine(r + " " + g + " " + b);
}
y++;
}
}

Hello,
first of all, your topic is not related to IPP at all.
Never the less, I'll try to answer :

// check rgb values
Ipp8u *pSrc = ippImage;
int y = 0;
for (int i = 0; i < height; i++) {
for (int j = 0; j < 3*width; j+=3) {
Ipp8u *pixel = pSrc + j;

int r = pixel[2];
int g = pixel[1];
int b = pixel[0];
Console::WriteLine(r + " " + g + " " + b);
}
pSrc += stride;
}

By the way, you can use ippiCopy_8u_C3P3R to copy your RGB image in 3 seperate planes. Look at ippi documentation.

Regards,
Matthieu

PS : not sure of RGB order (I think it's BGR in memory)

[rogene]

Quoting - matthieu.darbois

Hello,
first of all, your topic is not related to IPP at all.
Never the less, I'll try to answer :

// check rgb values
Ipp8u *pSrc = ippImage;
int y = 0;
for (int i = 0; i < height; i++) {
for (int j = 0; j < 3*width; j+=3) {
Ipp8u *pixel = pSrc + j;

int r = pixel[2];
int g = pixel[1];
int b = pixel[0];
Console::WriteLine(r + " " + g + " " + b);
}
pSrc += stride;
}

By the way, you can use ippiCopy_8u_C3P3R to copy your RGB image in 3 seperate planes. Look at ippi documentation.

Regards,
Matthieu

PS : not sure of RGB order (I think it's BGR in memory)

Huh? Where should I be posting questions like this?Thequestionwas specific to accessing information in a Ipp8u image.

Thanks for your help.

[rogene]

Your code worked beautifully. I get it now! The byte ordering is starting to make sense. Thanks for the help!

(btw, the rgb order was correct as written.)

[elhefe38]

Quoting - rogene

Huh? Where should I be posting questions like this?Thequestionwas specific to accessing information in a Ipp8u image.

Thanks for your help.

An "Ipp8u image" is (usually) allocated by ippiMalloc_8u_C1/C3, no by using windows gdi functions ! :)

regards

[pvonkaenel]

Quoting - elhefe38

An "Ipp8u image" is (usually) allocated by ippiMalloc_8u_C1/C3, no by using windows gdi functions ! :)

regards

Quite true, however there should be no problems using memory allocated with other routines ... correct? I tend to use VirtualAlloc so that I have the option of locking the memory to the non-paged pool using VirtualLock. Is there some way to lock down memory allocated with ippiMalloc_8u_C1() ?

Thanks,
Peter

[matthieu_darbois]

Quoting - elhefe38

An "Ipp8u image" is (usually) allocated by ippiMalloc_8u_C1/C3, no by using windows gdi functions ! :)

regards

I'd say that an Ipp8u image doesn't really exist (typedef unsigned char Ipp8u).
It's just a memory buffer. Who allocated the buffer doesn't really matter (except for speed because ippiMalloc_* aligns start of line on a 32 byte boundary).

So, to the question "Huh? Where should I be posting questions like this? The question was specific to accessing information in a Ipp8u image. ", the answer would be on any forum dealing with C/C++ image processing. IPP forum should be used to address concerns on IPP and IPP samples...

Regards,
Matthieu

[elhefe38]

Quoting - pvonkaenel

Quite true, however there should be no problems using memory allocated with other routines ... correct? I tend to use VirtualAlloc so that I have the option of locking the memory to the non-paged pool using VirtualLock. Is there some way to lock down memory allocated with ippiMalloc_8u_C1() ?

I have used many IPP functions on both buffers allocated through ippMalloc and plain malloc/new. No problem so far (provided you supply the correct step)... and also on gdi+ bitmaps buffers.
However, according to Valdimir, using IPP functions on malloc'd buffers can impact performance.

regards

[rogene]

elhefe38:

Would you pleaseshare the "correct" way of importing Bitmaps for use with the IPP Library, rather than just telling me that it is "wrong" to import using the Windows gdi functions. I am not finding much in the manual on this topic.

Matthieu:

It is not friendly to tell people who are evaluating the adoption and purchase of a technology to go elsewhere to get their questions answered.

Cheers!

[elhefe38]

Quoting - rogene

elhefe38:

Would you pleaseshare the "correct" way of importing Bitmaps for use with the IPP Library, rather than just telling me that it is "wrong" to import using the Windows gdi functions. I am not finding much in the manual on this topic.

Matthieu:

It is not friendly to tell people who are evaluating the adoption and purchase of a technology to go elsewhere to get their questions answered.

Cheers!

I did not say your way of processing gdi bitmaps was "wrong", but it has, as Mathieu said, nothing to do with IPP itself (although undertanding the layout of a gdi bitmap will be helpful if you intend to process it later through IPP). Your code example could have been posted on a windows/gdi specific NG (there are quite a few).
Anyway, I guess your issue is resolved now ?

regards

[rogene]

Quoting - elhefe38

I did not say your way of processing gdi bitmaps was "wrong", but it has, as Mathieu said, nothing to do with IPP itself (although undertanding the layout of a gdi bitmap will be helpful if you intend to process it later through IPP). Your code example could have been posted on a windows/gdi specific NG (there are quite a few).
Anyway, I guess your issue is resolved now ?

regards

Yes, it is resolved now.

I suppose after I have worked with image processing for several years, then I, too, will have a good sense of whether a question falls into a general knowledge category or a product specific category. But today, I find myself on a image processing project which is both outside of my field andon a tight deadline, so I'd appreciate you cutting me some slack.