Arducam DLL C# wrapper: ArduCamCfg_LoadCameraConfig CString parameter not marshallable

USB 3 Camera Dev Kits
1

Hi, I’m integrating my Arducam camera by calling the vendor DLL from a C# wrapper and I’ve hit a marshalling wall.

I need to call ArduCamCfg_LoadCameraConfig, but the second parameter is a CString:

ArduCamCfg_LoadCameraConfig( ArduCamCfgHandle &useHandle, CString csFilePath );

CString isn’t a marshallable type, so I can’t exchange it across the C# / C++ DLL boundary. Would it be possible to provide another function that takes a const TCHAR* instead? Something like:

Uint32 ArduCamCfg_Wrap_LoadCameraConfig(ArduCamCfgHandle& useHandle, const TCHAR* csFilePath)
{
     CString s(csFilePath);
     return ArduCamCfg_LoadCameraConfig(useHandle, s);
}

That would let me actually call it from C#. Has anyone run into this?

2

Hi, thanks for reaching out.

I can see in your snippet that you added an extra parameter, but we can’t quite figure out your purpose from the code alone — could you tell us what effect you’re trying to achieve with it?

Also, I noticed you mention a USB transfer timeout error. To diagnose that we need to know what type of USB interface the camera is connected to — USB 2.0 or USB 3.0? The interface type can matter a lot here.

One more thing worth setting expectations on: this camera uses a raw sensor, so it cannot output JPG directly (there’s no on-camera/ISP JPEG encoding).

Could you confirm the USB interface type and clarify the purpose of the added parameter?

3

Thanks for the quick reply.

  1. On the CString issue — the connection is USB 3. And I actually think the USB error is linked to the marshalling problem. Here’s why: if I first initialize the camera with your USBTest program (connect the camera, load the file, open it, then quit), the USB transfer timeout error goes away in my own application. So it seems related.

  2. In USBTest, Bits = 8 works fine, but any other value gives me ‘Bad frame receive’. I’d really like to use 10 bits or more for better color precision.

  3. On raw format — yes, I’m fine using raw.

  4. The green photo question: when I use USBTest with the config file ArduCAM_108MP_MIPI_2Lane_RAW8_12000x9000_1.4fps.cfg, the photo comes out quite green. I asked about this earlier but haven’t gotten an answer — is there anything that can be done to get a properly colored photo?

I’ve attached a couple of screenshots showing the issue. Still also hoping for a const TCHAR* version of ArduCamCfg_LoadCameraConfig if that’s possible.

4

Got it, thanks for all the extra detail.

On the green tint — that’s actually expected here. This camera uses a raw sensor, which can only output a raw picture, and raw sensor output looks green (it’s RAW Bayer data). To turn that into a properly colored photo you’d need ISP (Image Signal Processing) to do the demosaicing and color correction.

At present, no ISP software has been developed for this camera, so it cannot produce a colored photo. So sorry that we are unable to provide help on this problem at this time.

5

That’s disappointing to hear, but thanks for explaining it clearly. Do you plan to develop this ISP software? If yes, when will it be available? I’d like to know whether it’s worth waiting for, or whether I should look at other options. At the moment using USBTest with ArduCAM_108MP_MIPI_2Lane_RAW8_12000x9000_1.4fps.cfg I just get green photos, and I have no way to get a well-colored image.

6

Understandable question. Yes, there is a plan to develop that ISP software, but I’m afraid I cannot give you an accurate answer on timing at the present time. :frowning:

We have too many development tasks right now and the team is stuck with them, and on top of that our R&D personnel contracted COVID-19 and most of them had to ask for leave.

So there’s an intention to build it, but I can’t commit to an availability date. Hope you can understand — I’ll update the thread if anything changes on this.