Setting Post-Processing options using C# wrapper

[Suzanne-Peerdeman]

---

Required Info
Camera Model	D400
Firmware Version	05.12.03.00
Operating System & Version	Windows 10
Kernel Version (Linux Only)	N/A
Platform	PC
SDK Version	2}
Language	C#
Segment	Other

Issue Description

Hello!

I have recently started working with the C# wrapper for the librealsense library, and have encountered an issue that I have not yet found an answer to in your resource material.

When using the post processing functions, the only way that I have found to set the filter options is to write to the Value property directly. This is obviously not a safe way to do it, and although it does the trick in some cases, it can certainly cause critical errors.

The problem in particular is with the decimation filter. When writing to the filter magnitude option, the resulting stream will be corrupted, and occasionally an access violation exception will be thrown.

Is there anyone who can point me in the right direction as to how to resolve this?

[MartyG-RealSense]

There was a previous case of a C# user who had an error when writing to Values when setting up decimation post-processing.

https://forums.intel.com/s/question/0D50P00004D2MSBSA3/depth-postprocessing-in-%D1%81?language=en_US

@dorodnic the RealSense SDK Manager offered up this alternative example in a different case, where the value is provided directly (e.g '3.0F') instead of being substituted in via an Int variable:

var dec = new DecimationFilter();
dec.Options[Option.FilterMagnitude].Value = 3.0F;

#2809 (comment)

[Suzanne-Peerdeman]

There was a previous case of a C# user who had an error when writing to Values when setting up decimation post-processing.

https://forums.intel.com/s/question/0D50P00004D2MSBSA3/depth-postprocessing-in-%D1%81?language=en_US

@dorodnic the RealSense SDK Manager offered up this alternative example in a different case, where the value is provided directly (e.g '3.0F') instead of being substituted in via an Int variable:

var dec = new DecimationFilter();
dec.Options[Option.FilterMagnitude].Value = 3.0F;

#2809 (comment)

Thank you for the swift reply. As far as I can tell the issue does not lie with the datatype used, I have tried to be mindful of that.

The issue might be coming from the align filter, which I apply after the decimation filter. Could that be the issue?

[MartyG-RealSense]

Applying the align after post-processing is the correct way to do it. Otherwise, applying align before post-processing can cause a jagged-line distortion called Aliasing.

[Suzanne-Peerdeman]

Applying align after post processing does seem to be the cause of the issue, as it does not occur otherwise. In some cases, but not all, it will throw an access violation exception.

Can these operations not be called concurrently in the same processing block?

[MartyG-RealSense]

There is a C# example program in the SDK that can use processing blocks to do post-processing and align. It may be worth looking through if you have not seen it already.

https://github.com/IntelRealSense/librealsense/blob/master/wrappers/csharp/cs-tutorial-3-processing/Window.xaml.cs

[Suzanne-Peerdeman]

Yes I have looked at this example, and I go about it in a similar way. The exception being that in the processing block I apply the decimation filter before the others.

When the magnitude option of the decimation filter is changed dynamically, the problem occurs, often throwing an accessviolationexception from the call to Align.

[MartyG-RealSense]

I did further research on this subject. As far as I know though, doing Align and post-processing together in C# can be an inherently awkward process compared to C++. Whilst aligning after post-processing is the ideal, if the program works stably for you when aligning before post-processing and does not noticeably impact image quality, it may be worth going with that and seeing if it remains stable.

[ogoshen]

Hi Suzanne,

Setting the decimation filter magnitude should be thread safe.
But this data corruption does sound like a concurrency issue, like there is a profile\data mismatch in the frame...

Does this still happen if the magnitude is changed from the CustomProcessingBlock callback instead of from the UI?

[MartyG-RealSense]

Case closed due to no further comments received.