You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is not a duplicate. Before opening a new issue, please search existing issues.
This issue is not a question, bug report, or anything other than a feature request directly related to this project.
Proposal
I was dismayed when discovering that apparently* the FILL mode in depth reconstruction has been removed. It is available in the ZED tools but the option seems to have disappeared in the ROS wrapper. I understand that you say it is not good for robotics but it would be great if the decision to use it or not was left with the user. We need it and not having it will force me to implement my own, which is really annoying given that the underlying library supports it.
Can we please have it back?
I have not found the option described anywhere and have tried the old option and that made no difference.
Use-Case
We use the depth image to create a height (above ground) image and process it to extract specific areas. Having holes in the image messes up our processing while having erroneous values is fine (our statistical method is robust to that).
Anything else?
No response
The text was updated successfully, but these errors were encountered:
Preliminary Checks
Proposal
I was dismayed when discovering that apparently* the FILL mode in depth reconstruction has been removed. It is available in the ZED tools but the option seems to have disappeared in the ROS wrapper. I understand that you say it is not good for robotics but it would be great if the decision to use it or not was left with the user. We need it and not having it will force me to implement my own, which is really annoying given that the underlying library supports it.
Can we please have it back?
Use-Case
We use the depth image to create a height (above ground) image and process it to extract specific areas. Having holes in the image messes up our processing while having erroneous values is fine (our statistical method is robust to that).
Anything else?
No response
The text was updated successfully, but these errors were encountered: