HOW TO REPRODUCE

• Launch mapping viewer targetting non-Cuda mapping service
• Start mapping session

EXPECTED BEHAVIOR

• A 3D visualization window opens, showing the marker reference frame, camera poses and cloud points with the color of the corresponding pixel in the image buffer retrived from the device sensor that was fed to the mapping service.

OBSERVED BEHAVIOR

• Cloud points are invisible, or more precisely, their color appears to be near black, as I think we can see some occlusion when moving the viewer viewpoint around.

• This does not happen with a Cuda-enabled service instance.

• This does not happen if viewer is configured to use a hard-coded color (for i.e. green) for the cloud points, but only when we use the fixedPointsColor property to use the color stored in the map's point cloud.

SUGGESTED SOLUTION
As the viewer is the same in both cases, I've diff'd the Cuda and non-cuda configuration files of the mapping service.
It appears that in Cuda mode, the configuration uses the SolARDescritorsExtractorFromImagePopSift component, which declares the imageMode property which defaults to "Float" and sets it to "Unsigned Char", whereas in non-Cuda mode, SolARDescriptorsExtractorAKAZE2Opencv is used and does declare such property.

So it may be worth checking how the RGB channels of the map's cloud points colors are encoded and interpreted by the viewer (expected to be either a [0..1] float value or a [0..255] unsigned int char value).

HOW TO REPRODUCE

• call option version on SolARServiceTest_Mapping_Multi_Viewer (develop branch)

EXPECTED BEHAVIOR

• returns correct version, i.e. as of today: 1.0.0 on developbranch.

OBSERVED BEHAVIOR

• returns out of date version: 0.9.3.

SUGGESTED SOLUTION

• Remove this option (LOC)
• or maybe find a way so that it stays in sync automatically. I've seen other places where there seems to be such a mechanism (exemple)