Fix byte indexing for depth patch pixels in ViewPicker::getPatchDepthImage #661
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Depth pixel data is now represented by a series of 3-byte sets, rather than a series of 4-byte sets as it was in ROS1 RViz. This means that the previous method used to access pixel data by index relative to the start of the depth patch array does not work correctly, and that each pixel after the first will be composed incorrectly. This change modifies the pixel indexing method to use sets of 3 bytes instead, and adds an assert to ensure that the depth patch uses the expected data format before accessing pixel data. Signed-off-by: Joe Schornak <joe.schornak@gmail.com>
schornakj
force-pushed
the
fix/ogre-depth-patch-pixel-indexing
branch
from
03888fd
to
f1ed337
Compare
jacobperron
approved these changes
Mar 16, 2021
jacobperron
pushed a commit
that referenced
this pull request
Aug 31, 2021
Depth pixel data is now represented by a series of 3-byte sets, rather than a series of 4-byte sets as it was in ROS1 RViz. This means that the previous method used to access pixel data by index relative to the start of the depth patch array does not work correctly, and that each pixel after the first will be composed incorrectly. This change modifies the pixel indexing method to use sets of 3 bytes instead, and adds an assert to ensure that the depth patch uses the expected data format before accessing pixel data. Signed-off-by: Joe Schornak <joe.schornak@gmail.com>
jacobperron
added a commit
that referenced
this pull request
Sep 13, 2021
Depth pixel data is now represented by a series of 3-byte sets, rather than a series of 4-byte sets as it was in ROS1 RViz. This means that the previous method used to access pixel data by index relative to the start of the depth patch array does not work correctly, and that each pixel after the first will be composed incorrectly. This change modifies the pixel indexing method to use sets of 3 bytes instead, and adds an assert to ensure that the depth patch uses the expected data format before accessing pixel data. Signed-off-by: Joe Schornak <joe.schornak@gmail.com> Co-authored-by: Joseph Schornak <joe.schornak@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Originally in #657; split off to separate a bugfix from an API change.
The method in which OGRE packs depth pixel data has changed in the version currently used by RViz2. In ROS Melodic RViz each uint32 pixel was represented by 4 sequential uint8 elements in an array, but only the first 3 elements actually contained useful data and the 4th element was discarded. In the current version (I'm testing with Foxy right now) it looks like each depth pixel is now represented by just 3 sequential uint8 elements, without the 4th "empty" index. This means that the previous method of accessing the data for each pixel by index relative to the start of the array no longer works correctly and returns mangled or misaligned data for all pixels after the first. A change to the data pointer indexing method in the ViewPicker::getPatchDepthImage function was needed to correctly calculate distances from the scene camera when getting patches containing more than one pixel. A new assert checks that the depth patch uses the expected data format before accessing pixel data.
The data indexing bug did not cause problems previously because it does not affect the depth value for the first pixel in the array. ViewPicker::getPatchDepthImage is only used by ViewPicker::get3DPatch, which is itself only used by ViewPicker::get3DPoint to get a single-pixel patch. This issue is also somewhat challenging to demonstrate, since I think the current RViz test suite only uses mock versions of these functions.
Signed-off-by: Joe Schornak joe.schornak@gmail.com