5 Replies Latest reply on Oct 12, 2017 7:07 AM by MartyG

    [C API] processing blocks




      since I can't use the C++ API to implement the RealSense D435 into the framework of our company, I'm currently trying to figure out the C API.

      One of the last things I'm struggeling with are processing blocks. Even after reading the C API docs and how the C++ API makes use of the C API in this case, I still don't quite understand how to make it work.


      I'm currently reimplementing the 'Capture'-example with the C API. So I need to create a colorize processing block to transform the depth frame to a color frame to display it.

      So at the start of the programm I create a colorize block and a framequeue:


      rs2_processing_block* color_map = rs2_create_colorizer(&e);

      rs2_frame_queue* queue = rs2_create_frame_queue(1, &e);


      Then I am supposed to call rs2_start_processing with a callback to queue up the processed frame.

      However I can not find anything about rs2_frame_callback in the C API. The C++ API contains a struct with said name, but I don't think that's what I'm looking for.


      rs2_start_processing(color_map, ???, &e);


      In the callback I then will have to enqueue the processed frame:


      rs2_enqueue_frame(frame, queue);


      When getting a depth frame:


      rs2_process_frame(color_map, frame, &e);


      And finally wait for the queue to have a processed frame ready for me:


      rs2_frame* colorized_depth = rs2_wait_for_frame(queue, 500, &e);


      Am I correct with my assumptions so far?

      And how do I implement the missing part about the rs2_frame_callback with the C API?


      Thank you for any kind of advice

        • 1. Re: [C API] processing blocks

          I have only recently started investigating D-camera programming so I may be of limited help in this case, but I will try to offer some insights from my own experience.


          I do have some experience that is relevant to your problem, since I am currently working on an interface to connect the Unity game engine's C# scripting to the C++ DLL library file of RealSense SDK 2.0 (the file named Realsense2.dll, located in the bin folder of SDK 2.0).  Getting C# code to talk to the C++ library is not easy, and currently I have got as far as printing out the contents of some of the DLL's variables in Unity's debug console.


          I think your boot-up routine for SDK 2.0 is generally in the right order (create pipeline, start pipeline, wait for frames, process frame).


          If you open up the realsense2.lib file in the Lib folder of SDK 2.0 in a text editing program then you can see a list of supported functions.  Going through the library list, the closest to rs2_frame_callback may be rs2_start_pipeline_with_callback


          Someone else recently was trying to convert the Colorize function from C++ to Python.  In that post, I suggested using the frameset instruction instead of frame.


          Pyrealsense2: Colorizer not working / no implmentation of Align

          • 2. Re: [C API] processing blocks

            Our projects indeed seem to be similar. I am working on integrating the D435 into our camera abstraction framework that is also written in C#.

            I had troubles wirting a plugin in managed C++ for the framework because of a mutex being used somewhere in the C++ API (wouldn't compile). There seems to be a way to make it work indirecting the C++ API via something called PIMPL. But I thought I could just as well use  the C API here.


            Sadly I don't think the answer is of any help. Or maybe I just don't understand exactly what you're suggesting.

            • 3. Re: [C API] processing blocks

              I would suggest trying rs2_start_pipeline_with_callback in your program instead of rs2_frame_callback.  I don't have firm knowledge that this is correct - it is simply the function in the SDK 2.0 library that seems to be closest in purpose to the frame_callback instruction you were previously using.


              During my dissection of the DLL in a text editor, I noted that it included the Extern "C" instruction, which is designed to prevent "name mangling" errors when trying to get a C# system to read C++ format names.  So the SDK 2.0 DLL ought to be able to talk to a C# program.

              • 4. Re: [C API] processing blocks

                I don't see any symbol named rs2_start_pipeline_with_callback in the C API headers. There is only rs2_pipeline_start and rs2_pipeline_start_with_config. I already ported to and am using the latest version of the SDK made today.


                As soon as I include the C++ API header into the manged C++ project I get '<mutex> is not supported when compiling with /clr or /clr:pure.'

                • 5. Re: [C API] processing blocks

                  I think I know what the problem is.  My experience is in communicating with the SDK DLL file directly instead of using the SDK 2.0 Librealsense interface as a go-between.  Librealsense seems to give some instructions different names to those inside the DLL file.  I apologize for causing confusion.