SF removal still same .las size, BUG or Feature?

If you are allergic to bug trackers, you can post here any remarks, issues and potential bugs you encounter
Post Reply
PablerasBCN
Posts: 296
Joined: Sat Jan 20, 2018 1:57 pm

SF removal still same .las size, BUG or Feature?

Post by PablerasBCN »

Hi,

I was going to report this as bug but now I'm confused.

I was pretending to make data lighter by removing SF I don´t need, in bulk, via commndline.

To my surprise the outgoing file had exactly same size than input.

I tested manually and by manually deleting, same ressult.

YET, when using DELETE ALL SF there is some size reduction.

So I'm confused wethere this is related to the format, like it may allocate memory for default-ish fields or what. Or may the program be only deleting the reference in the SF array and leaving all the data in there??¿?¿?

Image
daniel
Site Admin
Posts: 7713
Joined: Wed Oct 13, 2010 7:34 am
Location: Grenoble, France
Contact:

Re: SF removal still same .las size, BUG or Feature?

Post by daniel »

LAS files have a 'fixed' structure indeed. So for a given point format, you'll always get the same file size (whether the fields are effectively used or not).

The only thing you could expect is the I/O plugin in charge to lower the point format if the conditions are met. But it may not be implemented (especially with the old plugins based on LASlib and maybe PDAL) or it may not be possible due to other constraints (such as the presence of colors, etc.).

I would say that with version 2.13.alpha and its new plugin based on LASzip, we should be able to trust them. But if you have a specific use case/example for which you can provide us with a cloud and a command line, I could double check things.
Daniel, CloudCompare admin
PablerasBCN
Posts: 296
Joined: Sat Jan 20, 2018 1:57 pm

Re: SF removal still same .las size, BUG or Feature?

Post by PablerasBCN »

Hello,

I tried with the beta, with same ressults.

Still if you think is worth doing any further testing this is the file used, includes the .bat

https://mega.nz/file/VssXSDpS#GZzqed7Y3 ... 9qOwMa56p8

With this file, you coul also test the performance crash when doing segmentation, which occurs after first cut and if the decimation of the cloud in the windows has a point count higher than the current cloud being segmented. Even the drawing of the line of the segmentation tool is choppy af.
daniel
Site Admin
Posts: 7713
Joined: Wed Oct 13, 2010 7:34 am
Location: Grenoble, France
Contact:

Re: SF removal still same .las size, BUG or Feature?

Post by daniel »

Thanks for the file. So I confirm that the point format is originally '3', and if you remove all the scalar fields, it will drop to '2' (to be able to store the colors). This correspond to a 40% gain on the output size. And you have to use the -REMOVE_ALL_SFS option, or 'n' times '-REMOVE_SF 0' for instance (see your other post).

And I confirm that it will work with either the GUI or the command line version (with REMOVE_ALL_SFS). If you don't remove all SFs, depending on the fields you leave on the cloud, you might keep a format '3' (see the LAS format specifications).

And regarding the performance drop, since the cloud has 45 million points, and we shift from VBOs (before the first segmentation), to single point display routines, I'm not that surprised by the performance drop sadly. We would have to find another way to manage these partial visibility filtering, but sadly I don't see how right now.
Daniel, CloudCompare admin
PablerasBCN
Posts: 296
Joined: Sat Jan 20, 2018 1:57 pm

Re: SF removal still same .las size, BUG or Feature?

Post by PablerasBCN »

Thanks for clarifying this thing related to the format / file size..

In regards to the segmentation I'll post in the other thread tomorrow. I understand it is something related to not cutting the points behind the camera.
Post Reply