-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to change untextured pointcloud resolution (size) independently from the RGB setting? #1924
Comments
Hi @mszuyx The RealSense ROS wrapper provides a decimation filter that can be used to reduce depth scene complexity. It can be enabled by adding filters:=decimation to the roslaunch instruction. In ROS1, once a decimation filter is defined then its value (Magnitude) could be configured with dynamic_reconfigure, as demonstrated in the link below. If you are using ROS2 though, it does not use dynamic_reconfigure. Doronhi the RealSense ROS wrapper developer offers advice in the link below about setting filter values in ROS2. Alternatively, a RealSense ROS user in the link below took the approach of custom-defining a low resolution in the roslaunch instruction, which they said significantly reduced the number of points per message in their pointcloud configuration. When defining a custom resolution, three factors should be provided for each stream type that is being defined: width, height and FPS. If the three factors are not provided then the custom configuration is recognized as invalid and the default configuration of the particular camera model being used is applied instead. |
@MartyG-RealSense Thank you! I am using ROS1 with the latest SDK and ros wrapper. I have tried decimation filter actually. But I couldn't notice any change in pointcloud resolution. Here is my launch file, please advice if I did something wrong. Thank you!
|
It looks as though you are setting up the decimation filter within your launch file, but this does not set the magnitude value for the filter that determines the extent to which the filter will affect the ROS image. As mentioned earlier, after launch the magnitude could be set during runtime in ROS1 with dynamic_reconfigure: rosrun dynamic_reconfigure dynparam set camera/decimation 'Filter Magnitude' 1 |
@MartyG-RealSense Thank you! I will try that ASAP and let you know the outcome! (Even though I didn't try it in the way you suggest, I tried playing around the magnitude via "rosrun rqt_reconfigure rqt_reconfigure" and it doesn't appear to do anything either. And I believe the default magnitude setting of the decimation filter is 2, so at least the resolution should go down by a factor of two if I set it in the launch file... Anyway, I will let you know how it goes! ) |
The limiters for depth auto-exposure and auto-gain in librealsense were introduced in SDK 2.42.0 and require a firmware version 5.12.11.0 or newer. Which firmware version does your camera currently have installed please? IntelRealSense/librealsense#8220 As this feature just sets maximum limits for auto exposure and gain values, removal of the settings from dynamic_reconfjgure as indicated by the warnings would not likely have a significant effect on your roslaunch. Looking at your launch file that you kindly provided earlier, it looks as though it is a custom launch file rather than a pre-made one like rs_launch. So I cannot be certain whether your rosparam code for defining the decimation filter or the dynamic reconfigure value for the filter is correct because I do not have a similar reference to compare it to, unfortunately. Can you try defining the filter the 'standard' way to see whether it makes a difference to the depth image please, using an rs_launch first and then a rosrun secondly. roslaunch realsense2_camera rs_camera.launch filters:=decimation rosrun dynamic_reconfigure dynparam set camera/decimation 'Filter Magnitude' 8 |
Hi @MartyG-RealSense , the Realsense SDK is ver 2.47.0 and my D455 cameras are with firmware 5.12.14.50 (updated recently). And I have been following the latest release of realsense ros wrapper. |
The filter_magnitude / Filter Magnitude issue is mentioned in the #583 (comment) case mentioned earlier, though I do not have knowledge about it other than that comment. Do you experience any difference in the point cloud in regard to the RGB resolution if you set allow_no_texture_points to False in your launch file instead of True? |
Hi, @MartyG-RealSense |
Thanks very much @mszuyx for the test data. I will refer the questions in the above comment to @doronhi the RealSense ROS wrapper developer, since the question about a future update in the wrapper is a development related query. @doronhi would also be the best person to answer your question about the transformation / projection matrix used for align_depth on D455 in the ROS wrapper. Thanks! |
Hi @doronhi ! Would you kindly direct me to the right documentation? Thanks : ) |
Regarding the request to split the align_depth flag for images and for pointcloud - I think it's a valid request. I'll try to attend to it shortly but I don't have a timetable yet. The transformation between the color and depth sensors is available using
with these:
|
@doronhi Thanks! This is awesome! I will try it and let you know the outcome ASAP! : ) |
Hi @mszuyx Do you have an update that you can provide about this case, please? Thanks! |
@MartyG-RealSense Sorry! I am working on it! |
No problem at all - thanks for the update! |
@doronhi @MartyG-RealSense Just did what doronhi suggested. Updates:Now even if the align_depth is set true. The resolution of the camera/depth/image_rect_raw and the associated pointcloud match with the resolution setting for depth_width and depth_height (instead of matching the color_width and color_height like before, great!). However, the decimation filter still doesn't seem to work on the camera/depth/image_rect_raw or the pointcloud after this modification. -- which doesn't seem like the intended behavior. (i.e., even if the align_depth is set true, the pointcloud resolution will respect the depth resolution setting and it will be further reduced according to the decimation filter setting) An additional question:
|
Hi @mszuyx, The resolution of the pointcloud matches the resolution of the depth image it was built upon. |
@doronhi I am working on this. The behavior I am looking for is that the decimation filter can be applied on the /camera/aligned_depth_to_color/image_raw frame such that the resolution of the pointcloud generated from this frame can also be reduced accordingly. Based on your last reply: "In the original implementation, without any modifications, the pointcould is built upon the depth image that passed through all the filters. That means that if you set the "align_depth" filter, the pointcloud will be built based on a depth imaged aligned to the color image and it too will be aligned to the color image. If you set the "decimation" filter, the point cloud will have the resolution resulted from the decimation filter." It seems like the original implementation is aiming for the same behavior. But based on my observation (please refer to my earlier comments), once the align_depth is set true, the pointcloud will be built based on /camera/aligned_depth_to_color/image_raw frame like you described, but the resolution of this frame is always equal to the RGB frame regardless of the depth frame resolution setting or decimation filter setting. And in result, the pointcloud generated upon this frame will also have the same resolution as the RGB frame regardless of the depth frame resolution setting or decimation filter setting. To me, it seems like the aligned depth frame is untouched by the decimation filter even though the code clearly said: Thanks!! |
Hi @mszuyx Do you have an update about this case that you can provide, please? Thanks! |
@MartyG-RealSense Hi, not really. I am still waiting on doronhi's response. |
Thanks for the information @mszuyx |
Hi @doronhi Could you take a look at the question by @mszuyx at #1924 (comment) please? Thanks! |
Hi, Sorry for the late response.
Out of curiosity - why use the decimation filter instead of requesting the reduced resolution in the stream definition? i.e. |
@doronhi Thank you for your response! Yes, I have also come to the realization that the aligned_depth_to_color image is not affected by the decimation filter in any way. To answer your question, my application requires a high-resolution RGB stream (>1280x720 for object recognition), and a manageable size point cloud stream (after some trial and error, 424x240 is sufficient and preferable). In the end, all information will be presented in a traversability map, so it is preferable that the aligned_depth_to_color flag be set to true. My current solution is to set the aligned_depth_to_color flag to false and perform the alignment myself. (transformation should be easy, not so sure about the FOV difference. But I am using D455 so I think the two images should be similar.) Does this sound like a reasonable workaround? (meanwhile, it would be really handy if the resolution setting and decimation can also affect the aligned image directly. I think it will benefit lots of people who use RS cameras for navigation and recognition) |
If I understand correctly, you would like to apply the decimation filter on the RGB image after the aligned_depth_to_rgb image was already created. |
Hi @mszuyx Do you have an update about this case that you can provide, please? Thanks! |
Hi RS community,
For my application, I need a high resolution RGB stream for image classification and a low resolution pointcloud (without texture) stream for object detection. I originally assumed the size of the pointcloud is dominated by the "depth_width" and "depth_height" (the width and height of the sensor_msg::pointcloud2 should be the same as these two arguments). But it turns out the pointcloud size is dominated by "color_width" and "color_height" instead. (which makes sense as D455 uses stereo images to recover depth and pointcloud).
However, for my application, to maintain a high RGB resolution, I have to live with an unnecessarily detailed pointcloud. I wonder if the ros wrapper offers a way to change pointcloud size without touching the RGB setting. If not, I'm going to explore some ways to sub-sample the pointcloud. (But the whole point here is to reduce CPU usage. Sub-sampling will help, but not subscribing/processing the full-size pointcloud at all is better. )
Thank you!! : )
Yu
The text was updated successfully, but these errors were encountered: