Calling C++ Image API from C#

[_Erik_]

econner wrote:

So, I do not have acces to fill the buffer with a byte[]. This should be happening from caling the method.

I understand that the buffers are filled by WScanSelectBuf, am I right? If so, maybe you have to allocate these buffers before calling the function, I mean, create the instances of byte[] array, pin them with GCHandle and assing the address to the pbuf field of the MY_IMAGE objects. Can you give us a link to the documentation for the C++ library you are using? I would like to know what the three parameters are for, and what the WScanSelectBuf function is supposed to do. I think we might be able to give you a better help with a little more information.

[econner]

This was an example of another library that I was using as reference. It was confusing so I removed it since it is not the code I am having issues with.

modified on Thursday, January 13, 2011 8:48 PM

[econner]

Correct, on the buffer. Here is an excert from the docs: //Scan to buffer. int WScanSelectBuf(void* image_down, void* image_up ,int select) (param) image_down [out] structure for forward direction scan. image_up [in] NULL (reserved) select [in] 0 : forward direction & single scan (use image_down) 1 : backward direction & single scan (use image_up) 2 : both direction & single scan (use image_down & image_up) 3 : forward direction & dual scan (use image_down) 4 : backward direction& dual scan (use image_up) 5: both direction & dual scan (use image_down& image_up) Return value - Success 0, Fail > 0

[Luc Pattyn]

Not sure what your question is here. I would comment on the code like this: 1. it does not seem complete. Where is the buffer allocated? 2. I guess, but am not sure, the Marshal attributes used are sufficient to get the buffer pinned for as long as the native method lasts, but no longer. 3. Constructing an image from native data is fine, however it requires the underlying data to remain available as long as the image object lives (see MSDN doc), and that is not very easy to implement correctly. It sure does not show in your code. :)

Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.

[_Erik_]

Have you allocated and pinned the byte[] arrays before calling the function?

[econner]

No, I have not. From the C++ example, they show setting the pbuf size, but with using IntPtr I was not sure how to accomplish the same thing.

[econner]

Ok, I have looked a little more at your article. The Marshalling and pinning of the memory is something that I dont work with much. However, it does make sense with the type of memory error that I am receiving. So, from the original code I posted, how would you maybe suggest I change the stuct, DllImport, and calling methods to be in line with the Marshalling, pinning, and GCHandle? Would the parameter types change?

[_Erik_]

Create a byte[] array with the same size you need in C++ for UCHAR. Use GCHandle class to pin this array, so the GC will not reallocate it in case of a garbage collection, and set its address to the pbuf field. Have a look at the documentation of GCHandle class.

[Luc Pattyn]

You now have published two code snippets, I don't know which one you're talking about right now. However this is what I would to: 1. on the former snippet, take my advice, i.e. apply the third method of passing an array (with GCHandle, without Marshal, without unsafe). I expect that to work perfectly right away. And it does not require any change on the native side. 2. on the latter snippet, if the former now works well and you see sufficient reason to modify the latter, modify it to better correspond to the former. :)

Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.

[econner]

Sorry for the latter code. Please ignore it. Maybe I can delete it.

[jschell]

econner wrote:

Any suggestions would be appreciated.

Don't embed it in in your C#/.Net code. Instead wrap it in a C++ executable with a communication (socket/file/stdio) API and run it from C# via Process and write C# code to talk to the communication API. The advantage is that it can't take down your C# app and you can test the parts independently. Note the first part as that can happen even if your code is perfect if there is a bug in the library itself.

[econner]

I have modified the code as per my understanding of GCHandle. I am still getting memory errors. I believe it has something to do with the IntPtr of the pbuf in the MY_IMAGE struct. Here is my code so far:

[StructLayout(LayoutKind.Sequential)]
public class MY_IMAGE
{
public int width;
public int height;
public int info;
public IntPtr pbuf; // image buffer
}

[DllImport("scandll.dll")]
private extern static int WScanSelectBuf(IntPtr image_down, IntPtr image_up, int select);

public static int ScanSelectBuf(MY_IMAGE image_down, MY_IMAGE image_up, int select)
{

GCHandle image\_downHandle = GCHandle.Alloc(image\_down, GCHandleType.Pinned);
GCHandle image\_upHandle = GCHandle.Alloc(image\_up, GCHandleType.Pinned);

int ret = WScanSelectBuf(image\_downHandle.AddrOfPinnedObject(),
                              image\_upHandle.AddrOfPinnedObject(), select);

//CRASHES HERE WITH ERROR:
//Attempted to read or write protected memory.
//This is often an indication that other memory is corrupt.

image\_downHandle.Free();
image\_upHandle.Free();

return ret;

}

MY_IMAGE img1 = new MY_IMAGE();
MY_IMAGE img2 = new MY_IMAGE();

int nWidth = 864;
int nHeight = 1000;

img1.width = nWidth;
img1.height = nHeight;
img1.info = 8; // 8bit
//img1.pbuf = new byte[2 *nWidth * nHeight];

img2.width = nWidth;
img2.height = nHeight;
img2.info = 8; // 8bit
//img2.pbuf = new byte[2 * nWidth * nHeight];

//HOW TO DEFINE BYTE[] AND PIN AND THEN ASSIGN TO BUFFER?????

ret = ScanSelectBuf(img1, img2, 0);

Anything I am missing ???

[_Erik_]

Yes, you are pinning the MY_IMAGE objects, but that is not what you have to pin. When you call a function using P/Invoke, the CLR automatically pinnes in the managed heap the references you pass, so there is no need to explicitly pin them as you have done. However, the pbuf field of each MY_IMAGE class is an IntPtr, what means that it only contains the memory address of the buffer allocated to receive de image pixels. As it is only an address, the CLR will not pin these buffers automatically, and that is why the programmer has to pin them manually before using the P/Invoke call. In this case you have not even allocated the buffers, so the values of the pbuf fields of the MY_IMAGE objects you are passing to the unmanaged function are IntPtr.Zero, I mean, the default value for IntPtr. This is what you have to do: Before you call the WScanSelectBuf you have to create the two MY_IMAGE objects and allocate the byte[] arrays where that function will place the image pixel:

MY_IMAGE img1 = new MY_IMAGE();
MY_IMAGE img2 = new MY_IMAGE();

// Initialize the other fields, I mean, width, height and info
// Then create the byte[] arrays
// with the size given by the documentation
byte[] buffer1 = new byte[2*img1.width*img1.height];
byte[] buffer2 = new byte{2*img2.width*img2.height];

// Pin these two arrays in the managed heap
GCHandle bufferHandle1 = GCHandle.Alloc(buffer1, GCHandleType.Pinned);
GCHandle bufferHandle2 = GCHandle.Alloc(buffer2, GCHandleType.Pinned);

// Set the address of the buffers to each pbuf field
img1.pbuf = bufferHandle1.AddrOfPinnedObject();
img2.pbuf = bufferHandle2.AddrOfPinnedObject();

// And now we can make the P/Invoke call
int ret = WScanSelectBuf(img1, img2, select);

// Do not forget to free the handles
bufferHandle1.Free();
bufferHandle2.Free();

// Here you should have the pixel information in the buffer1 and buffer2 arrays

Tell us if it works.

[econner]

I modified the code as per above. The img1.pbuf and img2.pbuf are now showing an address. However, the native API funtion of WScanSelectBuf(img1, img2, select) is still crashing. I have tried passing in:

WScanSelectBuf(img1, img2, select) (MY_IMAGE)
WScanSelectBuf(ref img1, ref img2, select) (ref of MY_IMAGE)
WScanSelectBuf(img1, img2, select) (IntPtr)

and changed the code in the DLLImport and wrapper method without any success. Is there anything I am missing with Marshaling, etc? I am coming to the conclusion that it could be an issue with the 3rd party's API libary and is doing something odd with the function. However, it does work in their C++ sample. I have contacted the vendor and they are not familar with .NET. However, they are reviewing this thread and for any suggestions.

[_Erik_]

Ok, it's pretty weird... I am not sure what is going on here. The correct way to import MY_IMAGE type and the function is as I told you before, there is no need of marshaling for any field. You might try a little change, using Marshal.UnsafeAddrOfPinnedArrayElement instead of AddrOfPinnedObject method of GCHandle class, I mean, you first pin the buffers with GCHandle and then set the address in pbuf fields this way:

img1.pbuf = Marshal.UnsafeAddrOfPinnedArrayElement(buffer1, 0);
img2.pbuf = Marshal.UnsafeAddrOfPinnedArrayElement(buffer2, 0);

If it still does not work, you might try allocating the buffers directly in the global heap, with Marshal.AllocHGlobal (remember to free this memory when you don't need it any more), instead of creating them in the managed heap as we did before when instantiated the buffers with new byte[size]. If this works you should then copy the buffers allocated in the global heap to the managed heap with the method Marshal.Copy.

[econner]

Ok, below are the changes I tried. However, I am receiving an error of: "Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

[DllImport("scandll.dll")]
private extern static int WScanSelectBuf(MY_IMAGE image_down, MY_IMAGE image_up, int select);

public static int ScanSelectBuf(MY_IMAGE image_down, MY_IMAGE image_up, int select)
{
return WScanSelectBuf(image_down, image_up, select);
}

int nWidth = 100;
int nHeight = 200;

img1.width = nWidth;
img1.height = nHeight;
img1.info = 8; // 8bit

img2.width = nWidth;
img2.height = nHeight;
img2.info = 8; // 8bit

byte[] buffer1 = new byte[2 * img1.width * img1.height];
byte[] buffer2 = new byte[2 * img2.width * img2.height];

// Pin these two arrays in the managed heap
GCHandle bufferHandle1 = GCHandle.Alloc(buffer1, GCHandleType.Pinned);
GCHandle bufferHandle2 = GCHandle.Alloc(buffer2, GCHandleType.Pinned);

// Set the address of the buffers to each pbuf field
//img1.pbuf = bufferHandle1.AddrOfPinnedObject();
//img2.pbuf = bufferHandle2.AddrOfPinnedObject();

img1.pbuf = Marshal.UnsafeAddrOfPinnedArrayElement(buffer1, 0);
img2.pbuf = Marshal.UnsafeAddrOfPinnedArrayElement(buffer2, 0);

// And now we can make the P/Invoke call
ret = ScanSelectBuf(img1, img2, 0);

// Do not forget to free the handles
bufferHandle1.Free();
bufferHandle2.Free();

[econner]

Erik - Thanks for your help. I have it working now. The reason it was failing after the last step was due to other settings that had to be set on the scanner. The vendor makes a single side and double side scanner. The sample in the documetation does not match the process. I dug around in the C++ sample and found other settings that I was able to specify before scanning the card.

[econner]

One of the functions was not in the documentation and the sample I was using. I found the function when reviewing the header file and the C++ test app code.

[econner]

Erik, I wanted to thank you again for the assistance. I was able to confirm that the code require the buffer and pinning/marshaling of the memory and it will not work correctly without the suggestions you provided. I also wanted to let you know what compounded the testing issue with the error was due to incomplete documentation. After getting the process to work, I was able to change certain settings and was able to cause the process to fail. Basically, the image class has to define the height and width to the MAXIMUM allowed image that the scanner can accept. Then the buffer size is set to the max height * max width * single/double scanner mode. Once the scanner returns the image, it adjusts the height and buffer values to be what are read in from the scanner. If the image sizes are specified incorrectly/too small, the API will cause a memory error. For example, the image of the scanned area may be 4" but the scanner's read head is capable of scanning a wider area. So the image width has to be pre-set the maximum width of the read head and not the width of the item that is being scanned. BTW, these maximum values are not specified in the documentation or samples. I actually had to dig thru a C++ sample application and the header files to find these settings. Thanks again.

[_Erik_]

You're welcome. I'm glad to know you finally solved it.