D430 representation for invalid disparity in context of post processing whitepaper

• MartyG

  • November 29, 2020 22:57

  Hi Henry. I would echo the opinion of RealSense team member ev-mp in the linked discussion.  A primary reason for accessing raw frames via the low-level API would be to get the frames before they have processing such as rectification applied to them.  If you do not need to do that, the SDK's high-level API is efficient enough that you may not get a significant speed advantage from creating a disparity map at low-level instead of the existing functions that the SDK provides to generate it.  The link below may be helpful in that regard.

  https://github.com/IntelRealSense/librealsense/issues/3740 

  I was not certain what you meant when you said about implementing the filter chain in the SDK.  The filters are fully accessible by programming code so you do not need to write your own filter, though you do have to activate and configure the filters when writing your own script.  There are no filters enabled by default in RealSense users' own applications, unlike the RealSense Viewer that has a list of post-processing filters enabled by default.

  0

  Comment actions Permalink
• Henry

  • November 30, 2020 00:27

  Thanks for the quick reply Marty!  Firstly, when 

  depth2disparity.process(depth_frame );

  returns, I am not sure if this is the same result as what I would get when I ask for the raw disparity frame from the HW (for the sake of minimum latency), but you suggest there are other processes performed on the disparity frame (such as rectification == undistortion if I am understanding you correctly), defeating the idea of cutting out the depth --> disparity conversion process (takes up to 4 ms) in the filter chain.  Be that as it may, assuming that the returned disparity pixel values are still in uint16, I am just asking for what that "invalid disparity" is, so that I may implement a different kind of filter than what is offered in the SDK, for example the one described in Methods for depth-map filtering in view-plus-depth 3D video representation, which requires distinguishing the invalid pixels when spatial filtering.  You must do this in your own code, and I will of course clone your repo and look for the filter implementation if no one knows the answer.

  Earlier in the day, I saw another post where someone was chasing down Valgrind memory leak problem when putting together the filter chains (egg, decimation --> hole filling --> spatial --> temporal, etc), and wondered why the RS team just didn't offer a single filter that will do everything (with parameters), but I guess if you guys fill it's simple enough, that's a good enough of a reason.

  0

  Comment actions Permalink
• MartyX Grover

  • November 30, 2020 13:45

  I knew that a RealSense user had previously produced a raw disparity map by accessing the camera hardware directly, and managed to track down the script solution that they posted for doing so.

  https://support.intelrealsense.com/hc/en-us/community/posts/360051896473/comments/360014626993 

  I do not have an answer for your invalid disparity value question though.

  Thank you for your clarification about the meaning of 'filter chain'.  An advantage of dividing filters into separate categories is that it makes it easier to customize a project to exact software and hardware requirements.  Because post-processing is performed on the computer's hardware and not on the camera's internal D4 processing hardware, having numerous different filters enabled simultaneously may over-burden the computer on some hardware.  Although the RealSense Viewer enables most filters by default, there is the option of individually toggling them on and off.

  0

  Comment actions Permalink

Please sign in to leave a comment.