Split 2D+3D capture - #149
Open
torbsorb wants to merge 1 commit into
Open
Conversation
Zivid SDK will capture both 2D and 3D if `Zivid::Settings`
contain `Zivid::Settings::color`. However, it will not return
from the capture until both 2D and 3D has been acquired.
In order to get 2D data as fast as possible we split the capture
into two separate calls. This allows us to publish the 2D color
image as soon as it is ready.
This has no impact on the subscriber, other than in which order the
topics arrive.
Before: `acquisition_done` -> `color/image_color` -> `points/xyz`
After: `color/image_color` -> `acquisition_done` -> `points/xyz`
The order of `color/image_color` and `acquisition_done` depends on
the 3D acquisition settings and the processing speed of 2D color.
Note! Previously the resolution of the 2D image, when published
as part of the 3D capture service, was tied to the 3D point cloud.
That also applied to intrinsics. Now it will only reflect the 2D
settings. In other words, in order to have 1-to-1 mapping between
the 2D color image and the point cloud one must set the same
Zivid::Settings::Sampling in both. In other words:
```yml
Settings:
Color:
__version__: 7
Settings2D:
Sampling:
Color: rgb
Pixel: all
```
must equal
```yml
Settings:
Sampling:
Color: rgb
Pixel: all
```
in order to have the same resolution on both.
This also means that there is no path to publish the point cloud
resolution mapped color image, which was previously published
even when `Zivid::Settings2D::Sampling` != `Zivid::Settings::Sampling`
In this commit we also cache the intrinsics in order to unblock
publishing 2D color image. This is because calculating intrinsics
requires the camera.
vawale
reviewed
Jul 1, 2025
Comment on lines
+40
to
+44
| // ros::spin(); | ||
| ros::AsyncSpinner spinner(3); // Use 2 threads or more, depends on workload | ||
| spinner.start(); | ||
|
|
||
| ros::waitForShutdown(); |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Zivid SDK will capture both 2D and 3D if
Zivid::SettingscontainZivid::Settings::color. However, it will not return from the capture until both 2D and 3D has been acquired. In order to get 2D data as fast as possible we split the capture into two separate calls. This allows us to publish the 2D color image as soon as it is ready.This has no impact on the subscriber, other than in which order the topics arrive.
Before:
acquisition_done->color/image_color->points/xyzAfter:
color/image_color->acquisition_done->points/xyzThe order of
color/image_colorandacquisition_donedepends on the 3D acquisition settings and the processing speed of 2D color.Note! Previously the resolution of the 2D image, when published as part of the 3D capture service, was tied to the 3D point cloud. That also applied to intrinsics. Now it will only reflect the 2D settings. In other words, in order to have 1-to-1 mapping between the 2D color image and the point cloud one must set the same Zivid::Settings::Sampling in both. In other words:
must equal
in order to have the same resolution on both.
This also means that there is no path to publish the point cloud
resolution mapped color image, which was previously published
even when
Zivid::Settings2D::Sampling!=Zivid::Settings::SamplingIn this commit we also cache the intrinsics in order to unblock
publishing 2D color image. This is because calculating intrinsics
requires the camera.