Create RCS scan and RCP project without decimation

[lamorlette]

I want to create and write on disk RCS scans and RCP projects from point cloud data in memory.

I use RCProjectImportSession::addScan() and RCProjectImportSession::addPointsToScan().

RCProjectImportSession::addScan() takes as second parameter a RCScanImportOptions.

RCScanImportOptions has a pointsPerMM3 field (which is wrongly named as explained in What is "pointsPerMM3" mean in RCScanImportOptions?). It seems that, for this field, the 0, -1 and 1 values have the same effect, leading to a kind of 1 mm decimation.

Recap doesn't behave the same: if I import the same point cloud in Recap (with no decimation in 'advanced settings') and then export from Recap (in E57 format), I can see all the original points, without any decimation.

So, with Recap SDK, how can I create a RCS scan or a RCP project without any decimation

[martin.graner]

Are you writing your rcs files structured or unstructured?

--->RCScanMetadata.isStructured?

If you are writing unstructured data I can only recommend to write an intermediate laz instead and don't use the memory buffer, because your complete cloud is written into your %temp% folder, and given that your customers have the same project sizes as our customers, they won't be happy to have Terrabytes of uncompressed data on c:, while writing the rcs point cloud. We had enough complains about c: getting full and the rcp project wasn't written due to hard drive overflow.

If you are writing structured scans I think the option doesn't matter, since this option is used for the visualization cloud, not for the panoramas, and all points are still stored in the rcc files (wild guessing here).

[lamorlette]

Thanks @martin.graner.

I am writing structured RCP.

I have not yet managed to inspect what is the resulting panoramic image, but I will do so.

I tried to open the resulting RCP in Recap and then to export it to E57: the resulting file is decimated, contrary to what I get with the original point cloud file imported to Recap and exported to E57.

[yan.fu]

When you export structured e57 scan from ReCap, the information is exported from .rcc file, where there is no indexing structure created, so there is no decimation. 

If you are exporting to unstructured point cloud, the information will be retrieved from the indexing tree structure, thus decimation applies (depending on your setting, but minimum is 1mm.)

Hope it can explain the difference.

Thanks,

Yan

[lamorlette]

Hello @yan.fu,

My question is not about the difference between structured and unstructured export from Recap application.

It is about the difference between creation of RCP from structured E57 in Recap application, and creation of structured RCP from Recap SDK:

• In Recap application, when I create a RCP from a structured E57 file, all points are correctly saved in the RCP, without any decimation: from the created RCP, I can export an E57 with all the original points.
• With Recap SDK, when I create a structured RCP from the point cloud data I read from the same original E57 file, I get a decimated RCP: from the created RCP, if I export to structured “complete” E57, many points are missing in areas with very high points density.

How can I get the same non-decimated RCP with Recap SDK than with Recap application?

[yan.fu]

Hi @lamorlette ,

We are not aware of the difference yet. ReCap SDK and ReCap desktop use the same engine for scan importing. In ReCap SDK, the decimation is majorly controlled by pointsPerMM (will be renamed). The minimum supported decimation grid size is 1mm. 

Did you compare the .rcc file size created by ReCap desktop and ReCap SDK? If .rcc file size are similar but .rcs file size is different, then there might be problem in decimation. 

If there are already difference in .rcc file size, then it might be some issue in creating .rcc file, the cause might be wrong structured scan meta data, which causes wrong structured scan resolution. 

If you would like to share your project with us, we can take a look at what the cause might be.

Thanks,

Yan

[lamorlette]

Comparing the result from Recap application and Recap SDK:

• The sizes of the .rcs files are very close.
• But the .rcc file created by Recap SDK is 6 times smaller than the one created by Recap application.

You wrote: “In ReCap SDK, the decimation is majorly controlled by pointsPerMM (will be renamed). The minimum supported decimation grid size is 1mm.”

I think this is the key point of my question:

• In Recap application, when you import a scan, you can go to “scan settings” - “advanced” and disable the “decimation grid”. The display in Recap application is still decimated, but it seems that this setting allows to get back all the points form the original file when exporting the point cloud in “complete” mode.
• Is is possible to get the same “disable decimation grid” setting with Recap SDK?

[yan.fu]

Hi @lamorlette ,

When you export structured e57, the data is fetched from .rcc file, so no loss, all the information will be exported. 

For ReCap SDK, you can set decimation grid value to negative value and then it will use the minimum supported decimation value. 

You mentioned that .rcs file size are close then it means the 3D point cloud data is not decimated a lot. I think the issue you mentioned about decimation in ReCap SDK is mainly at the much smaller .rcc file size, which means your .rcc file is decimated a lot.  You can check the structure information setting used form RCProjectImporter to see if there is something wrong. 

Thanks,

Yan

[lamorlette]

@yan.fu Thanks for your explanations.

I made many new tests, and found out several interesting things, leading me to new questions.

1) In RCStructuredScanMetadata, setting startAzimuth, endAzimuth, startElevation, endElevation, azAngularSpacingRad and elAngularSpacingRad has an impact on decimation:

• When I set them, I can see that the .rcs size is reduced (but the .rcc remains unchanged).
• If I leave them unset, whatever the RCScanImportOptions::pointsPerMM3 value, the .rcs and .rcc remain unchanged.

Is it the intended behaviour?

What is the usage of all these RCStructuredScanMetadata members (for my usage, they seem useless)?

(Of course, in all cases, I set numRows and numColumns since I want to create a structured scan.)

2) I confirm that when the .rcc is unchanged, even if the .rcs size is reduced, as in the case described above, I get back all the original points if I do a complete E57 export.

3) Writing in global or local coordinates has a huge impact:

• If I set the station pose in RCScanMetadata::globalTransformation and write the points coordinates in local scan coordinate system, whatever the RCScanImportOptions::pointsPerMM3 value, the .rcc contains all points data, as stated above.
• If I don't set RCScanMetadata::globalTransformation and write the points coordinates in global coordinate system, then, even with RCScanImportOptions::pointsPerMM3 set to 0, both .rcs and .rcs sizes are reduced (and many points are missing if I a do an E57 export).

What do you think about this?

[yan.fu · Accepted solution]

RCStructuredScanMetadata defines the resolution and angle range of the spherical scan. If you don't set it, the SDK will compute the information from the input points by projecting the points to a spherical image. The derived information might be wrong in some cases such as there are some abnormal points. 

RCScanImportOptions::pointsPerMM3 should affect .rcs file size. It's not intended behavior that .rcs file size remains same for different pointsPerMM3 setting (unless the point density is below the setting, thus there is no decimation.)

The global transformation is important because the input points need to be transformed to scan local coordinates for spherical projection. If global transformation is not provided, the input point coordinates will be treated as local coordinates and then cause projection error. In this case, you may notice small .rcc file but big .diff file. 

Yan

[lamorlette · Accepted solution]

@yan.fu Thanks for the explanations.
I confirm that if, in RCStructuredScanMetadata, I leave startAzimuth, endAzimuth, startElevation, endElevation, azAngularSpacingRad and elAngularSpacingRad unset, the RCScanImportOptions::pointsPerMM3 value seems to have no impact (I tested on a project with, near the pole, very close points: about 0.1 mm, or even less, between adjacent points).

Actually this behaviour is very fine for my purpose!
So I will let Recap SDK compute the spherical resolution, which is also fine for me.