NIT NSC1003 GiGE support

[VictorLamoine]

I have compiled aravis latest version from source and built the viewer:

sudo apt install -y intltool autogen libgstreamer-plugins-base1.0-dev libgtk-3-dev libnotify-dev
./autogen.sh --enable-viewer
./configure
make -j4
sudo make -j4 install

I'm using Kubuntu 18.04 in case it matters.

I can list my GiGE camera:

arv-tool-0.6 
New-Imaging-Technologies-NSC1003cGigE-NSC1003cGige006  (192.168.100.186)

Full log of arv-tool-0.6 genicam

If I open the camera with arv-viewer I end with with an error because of the pixel format:

Aravis-Message: 14:35:16.310: GStreamer cannot understand the camera pixel format: 0x0!

Full log with arv-viewer --debug=all:3

I have tested all the pixel formats and none work, I think this is because of the specific pixel format of this high dynamic range camera.

Camera information

• Website: http://new-imaging-technologies.com/en/wdr-sensor-ingaas/swir-camera-hdr/page-products-sans-features/-7393464-7393908-mc1003-pgc.html
• Resolution: 1280x1024
• Data pixel: 14 bits raw data, 24 bits RGB data

What should be done to make aravis compatible with this camera? I can provide more information if necessary and I'll send this issue link to NIT, they might be interested in helping.

[EmmanuelP]

After a quick look at the genicam data, the camera should be compatible with arv-viewer wrt the pixel format, as it seems to provide Mono8.

Could you try to run tests/arv-camera-test --debug all:3 and attach the output here, in order to check if at least data streaming works.

[VictorLamoine]

Here is the log: https://gist.githubusercontent.com/VictorLamoine/4a46053bdc0887c28305606eed119b47/raw/0c81005f7874baa6c1a8798fe2c7918b34caf183/arv-camera-test%2520--debug%2520all:3

[VictorLamoine]

I have modified Aravis like @tgroche did and it still does not work; here is a full log with the modified version: https://gist.githubusercontent.com/VictorLamoine/4a46053bdc0887c28305606eed119b47/raw/2b54ed2ac31da93e67adbb4468f122869a86fb8d/MODIFIED%2520ARAVIS%2520-%2520arv-camera-test%2520--debug%2520all:3

static gboolean
_use_legacy_endianess_mechanism (ArvGcPort *port, guint64 length)
{
    return 1;
    ArvDomDocument *document;
    ArvGcRegisterDescriptionNode *register_description;

    document = arv_dom_node_get_owner_document (ARV_DOM_NODE (port));
    register_description = ARV_GC_REGISTER_DESCRIPTION_NODE (arv_dom_document_get_document_element (document));

    return length == 4 && (arv_gc_register_description_node_compare_schema_version (register_description, 1, 1, 0) < 0);
}

Do you know what is wrong?

[abrock]

I tested the current aravis version with this camera and it works partially iff I use the modification where _use_legacy_endianess_mechanism always returns 1.

I can use the arv-viewer to see images of the camera and the automatic exposure time adjustment works, the images get a lot less noisy when I point the camera at a bright light source.

However, I cannot set the pixel format, the camera always complains about a malformed packet. Default pixel format is BayerGR8 and the camera reports the following formats:

Mono8, Mono14, Mono16, RGB8, BayerGR8, BayerRG8, BayerGB8, BayerBG8, BayerGR16, BayerRG16, BayerGB16, BayerBG16

Here's the genicam xml, a logfile from my program trying to set ArvPixelFormat without success and a wireshark capture: NIT-data.zip

Later I read the genicam xml and found that the pixel format is actually read-only and you need to set "OutputType" to one of the following:

Correction_Grey Correction_Bayer Correction_Color RAW RAW_Bayer

I wrote a program to set all those values and run arv_camera_get_pixel_format afterwards to find the corresponding ArvPixelFormat for each "OutputType":

0x01080001 video/x-raw, format=(string)GRAY8 fmt: ARV_PIXEL_FORMAT_MONO_8 0x01080008 video/x-bayer, format=(string)grbg fmt: ARV_PIXEL_FORMAT_BAYER_GR_8 0x02180014 video/x-raw, format=(string)RGB fmt: ARV_PIXEL_FORMAT_RGB_8_PACKED 0x01100025 video/x-raw, format=(string)GRAY16_LE fmt: ARV_PIXEL_FORMAT_MONO_14 0x0110002e BayerGR16

Then I set the OutputType to "RAW" and recorded some frames but something is wrong with them:

[VictorLamoine]

@abrock for your information NIT now (since a few months already) has a SDK for GiGE cameras on Linux (mut not ARM devices, not Ubuntu 20.04). It would be nice to have them working in aravis in any case!

[abrock]

I took a couple of images of a scene where (roughly) the left half is dark and the right half is very bright (white LED panel at a distance of 40cm) with different settings. I used the arv-viewer to set the exposure time and didn't touch it afterwards.

1. Correction_Grey (Correction_Bayer looks exactly the same), this looks as expected.

2. RAW (RAW_Bayer agains looks exactly the same), this is unexpected. The original result image looked very dark so I multiplied the values by 16 to make it look roughly like the 8bit image.

I saved a couple of images and they were equivalent except for a little noise wich is expected.

I also found that arv_camera_set_exposure_time and arv_camera_get_exposure_time do nothing for this camera but arv_camera_set_integer(cam, "ExposureTime", std::round(exp), nullptr); and arv_camera_get_integer(cam, "ExposureTime", nullptr); work as expected.

The white stripe at the bottom also is weird, looks like ~2% is the image is missing. I first suspected that the camera actually uses a packed format to encode 8x14 bit into 7x16bit but that would mean 12.5% less data, not 2%.

[abrock]

Does the example image help? Should I record other / more examples?

[abrock]

Hm, I got the library by NIT and installed it in a virtual machine since my Ubuntu is too new. I went on to write a small program to capture an image. Then I would capture and image and all packets using wireshark in order to provide an example how it should look like.

Plot twist: The official NIT library gives me the exact same weird stripes as Aravis. I'll contact the NIT support.

[abrock]

NIT support replied with the following suggestions:

• It might be a bandwidth issue, try a direct connection between camera and computer without switch / router. I was already doing that.
• The camera needs JumboFrames, and for that we need two things:
  1. Set the MTU of the network interface to 9014 sudo ip link set dev $INTERFACE mtu 9014
  2. Let the camera know about it by setting "GevSCPSPacketSize" to 8000. Using the library provided by NIT: dev->setParamValueOf("GevSCPSPacketSize", 8000, false);. Using aravis: arv_camera_set_integer(cam, "GevSCPSPacketSize", 8000, nullptr);

If I'm not mistaken the only thing left to do to get full support for the camera in Aravis is to get _use_legacy_endianness_mechanism return 1 for this camera. Is there any information I can provide to help with that?

[VictorLamoine]

Also make sure you use a Gigabit Ethernet cable + port and check the intermediate switches if any. Check that the Ethernet connection is indeed configured in gigabit (software side). I use 8000 MTU (this reduces bandwidth by sending bigger packets) but default values works too for me.

If you set a very low FPS (5 ~ 8 FPS) it should also work on a non gigabit ethernet link.

[EmmanuelP]

Hi @abrock ,

If I'm not mistaken the only thing left to do to get full support for the camera in Aravis is to get _use_legacy_endianness_mechanism return 1 for this camera. Is there any information I can provide to help with that?

Could you attach the beginning of the output of arv-camera-test -d all with the device informations, especially write mem support ?

The Genicam schema specified is 1.1. Genicam standard says in this case the device should support writemem if possible.

It seems this camera does not follow the 1.1 schema, but 1.0. It would help if you could contact NIT about that.

[EmmanuelP]

Could you attach the beginning of the output of arv-camera-test -d all with the device informations, especially write mem support ?

Please use aravis master, which will also show device mode endianness.

[abrock]

I used bed99fecc322f96a8d62b849b8e4aca704f6c0c1 and recorded the output nit-master.txt. Then I changed the _use_legacy_endianness_mechanism function to always return 1 and recorded the output nit-hack.txt.

[EmmanuelP]

Thanks @abrock for the informations.

So the device is big endian and claims genicam schema 1.1, but does seem to like readmem/writemem for register access.

I'm trying to contact New Imaging Technologies and see if we can discuss about this issue.