Scale factor x,y, z, LAS-file, what is it?

[Mathias Abrahamsen]

Hello.

Can someone explain a little more about the scale factor of x, y, z in a LAS-file. What does it mean? Is it important to a LAS dataset, if so, in what way? 

Thanks

MA

[Jakub Krawczyk]

From Las specification 

X, Y, and Z scale factors: The scale factor fields contain a double floating point value that is used to scale the corresponding X, Y, and Z long values within the point records.  The corresponding X, Y, and Z scale factor must be multiplied by the X, Y, or Z point record value to get the actual X, Y, or Z coordinate. 

The x,y,z for each point is stored as Integer according to the LAS specification. So if you want to store information about x,y,z  with some decimal points (ie. cm accuracy or more) you use scale factor for it. 

For example, if the X, Y, and Z coordinates are intended to have two decimal point values, then each scale factor will contain the number 0.01. 

Jakub Krawczyk - Aerial Survey Department Manager jakub.k...@opegieka.pl tel. +48 +48 55 237 60 41  |  mobile +48 +48 723 233 443  |  fax +48 55 237 60 01

OPEGIEKA Sp. z o.o., al. Tysiąclecia 11, 82-300 Elbląg, Poland, www.opegieka.pl Bank Millennium S.A., PL: 84 1160 2202 0000 0000 6191 2549, EUR: PL 71 1160 2202 0000 5296 6311, SWIFT CODE: BIGBPLPW, NIP (Tax Identification Number) PL 5780004498, REGON (National Busi- ness Register Number) 001364260, KRS (National Court Register Number) 0000190471. Paid-up share capital 101, 000 PLN.

 

 

--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe

[Antoine Cottin]

Hi,

Coordinates are stored as long in the point record. This is why you need a scaling and offset factor to transform the signed long into a signed float.

Scaling ‘remove’ the decimal in the coordinates system

Offset makes sure that the integer value falls into the range of a signed long possible values

Antoine

--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe

-----------------------
Dr Antoine Cottin
Chief Technology Officer

Carbomap Ltd.
7th Floor, Appleton Tower
11 Crichton Street
Edinburgh
EH8 9LE

http://www.carbomap.com

http://carbomap.wordpress.com

http://github.com/carbomap

@carbomap

+44 (0)7577 444-046

[Lewis Graham]

Yes and the entire scheme is because floating point has base two logarithmic reduction in resolution (not precision) as numbers become larger.  Using integer format allows one to maintain constant resolution.  This is an extremely important consideration in point cloud work.

 

Lewis Graham

GeoCue Group

9668 Madison Blvd., Suite 202

Madison, AL USA 35758

01-256-461-8289

www.geocue.com

www.LP360.com

[Mathias Abrahamsen]

Thanks for the answer guys.

Can you please look at these pictures and look at the scale factors before and after:

Is this ok? Can I rely on this data for volume measurement on so on?

Thanks again:)

[Antoine Cottin]

Hi there, it seems that the scale have an issue… did you use CloudCompare ?

CloudCompare has a bug when you save a LAS file.

You can use LAS2LAS to correct the issue

las2las -i lasFile.las -rescale 0.001 0.001 0.001 -auto_reoffset -odix _mm -olas #LiDAR

Cheers

Antoine

[Dimitri Lague]

Hi,

The latest version of Cloudcompare 2.6.0 has updated to the latest version of liblas who’s in charge of I/O for las files. There was indeed some problems saving .las files in the previous versions. If the bug is still there, could someone post it in the Cloudcompare forum for correction in the next release ? The .las I/O capabilities of Cloudcompare was a request from users, but Daniel Girardeau-Montaut the main developer does not use a lot, so small bugs not directly visible when loading the file may skip its attention.

 

Thanks in advance

 

Dimitri

----------------------------------------------------------------------------------------------

Dr Dimitri Lague, Chargé de Recherche CNRS, Quantitative Geomorphology

Géosciences Rennes, UMR 6118 CNRS

Université Rennes 1, Campus de Beaulieu

35042 Rennes Cedex - FRANCE

Tel : +33 (0) 223235653

Fax : +33 (0) 223234375

www : http://www.geosciences.univ-rennes1.fr/spip.php?rubrique95

Laser scanning webpages: http://www.geosciences.univ-rennes1.fr/spip.php?article1125

-------------------------------------------------------------------------------------------------------

 

 

 

De : last...@googlegroups.com [mailto:last...@googlegroups.com] De la part de Antoine Cottin
Envoyé : Saturday, 13 December 2014 12:59
À : last...@googlegroups.com
Objet : Re: [LAStools] Scale factor x,y, z, LAS-file, what is it?

---

This email is free from viruses and malware because avast! Antivirus protection is active.

[Mathias Abrahamsen]

Yes I used CloudCompare.

Tried the new version and got the same result, please see attachment:

[Daniel Girardeau-Montaut]

Hi everyone,

I'm the administrator of the CloudCompare project. Dimitri pointed me to this thread (next time, don't hesitate to post a message on CC's forum or send me an email if you spot something that looks like a bug ;).

First, let me explain how CloudCompare works:

- CloudCompare doesn't handle units. It reads the data as they are stored in the file (whatever its format) and the user is responsible for any conversion of the coordinates that would be necessary for its own process

- for efficiency reasons values are stored internally as 'standard' floating point values (as most formats do by the way - LAS and E57 files are the only formats that use this offset/scale coding scheme).

- therefore, when CC saves a cloud (that can come from ANY file format) to LAS format, it doesn't have any particular information and it saves the cloud with a very high relative accuracy (= scaling) of 10^-9 multiplied by the cloud bounding-box dimension (10^-9 because the integer saved in LAS files is coded on 32 bits which roughly corresponds to +/-2.10^9).

This is why you can see very small values for the scale. But there's no real loss of accuracy with this way of working and it works whatever the cloud source is.

But I understand that it's more the value of the 'scale' itself that bugs you?

What would you expect exactly?

• that CloudCompare remembers the original offset/scale information when loading the cloud from a LAS file? (the issue is that if you modify the values inside CC, this information might not be adapted to the new coordinates of the cloud)
• or that CloudCompare asks the user for the right offset/scale values when saving the file? (in a kind of 'advanced mode' of course)

I hope you'll understand that CloudCompare is not a LAS-only tool and therefore those kind of 'particularities' are quite painful to manage (especially when it's not for the sake of accuracy ;).

Cheers,

Daniel

[Mathias Abrahamsen]

Hello.

Yes I used CloudCompare. I have now tried to fix the las file. Does this look better?

[Dr Antoine Cottin]

Yes it does

Envoyé de mon iPhone

[Mathias Abrahamsen]

Hello Daniel.

Thank you for your answer! Great program!

The las-file is a cloud exported from agisoft´s photogrammetry program. It is georeferenced, using a lot of GCP measured with GNNS Rover/GPS.

Yes, it more the value itself than the "scale". When I exported the las-file from Agisoft Photoscan I got factors of 0.001. My concerns is that now when the scale factors has changed after export from CC, the cloud no more is as accurate it was before import to CC?? I am going to use the cloud for volume calculation of a big area with of lots of piles of stone and soil in another program. Can the dataset be "thrusted" when the scale factor has changed from 0.001 to 0.00000064323442something. 

Does it actually matter that the scales has changed? The actual problem here is that I don't quite understand the scale factor and offset. I just want to be sure that the cloud is reliable and accurate for volume calculation, with the georeferencing (coordinate system of Euref89 Utm zone32) still in there.

As you can see above "a.cottin" stated that I had to do something about the scale factors. Do I need to use LAStools to change the factors?

Thanks for the help everyone, and Daniel:)

MA

...

[Daniel Girardeau-Montaut]

Hi Mathias and thanks for your feedback.

"Theoretically" the change of scale shouldn't matter. But as the cloud is georeferenced, the issue may be on the offset side, or even somewhere else on CC's side (as the handling of georeferenced point cloud in CC is quite new and has always been quite tricky).

I would be very interested to get your dataset (or at least a small part) to conduct some tests. By the way how do you evaluate this loss of accuracy? Have you been able to quantify it?

Eventually, if the file output by CC is already broken, fixing the scale afterwards shouldn't change anything. Apart if the other software you import the file into doesn't handle well this offset/scale mechanism (but it would be very surprising).

Daniel

[Mathias Abrahamsen]

Hello again Daniel.

I don't know if there actually was a loss of accuracy, but I am afraid that it might be, this because I saw that the offset and scale factor changed after CC export. What I wanted to know is that the dataset are still good(reliable) even tough these changes. Is it? 

I have not checked the accuracy yet as I was hoping to hear that the scale factor and offset doesn't affect the accuracy of the cloud, but it does?

You are welcome to perform some test with my dataset, (that would be great!) how would like me to send it to you?

Best regards

Mathias

[Daniel Girardeau-Montaut]

As I said, theoretically there shouldn't be any loss of accuracy. It can be a bit weird but after all:

0 + 10000 * 0.01 = 95 + 65535 * 0,000076295 (+/- 10^-6) 

Assuming that your cloud coordinates are all actually between 95 and 100 and that you can only store your points with integer coordinates (which is the case in a LAS file), in the first case you'ill only have 500 different values available to represent all your values while in the second case you'll have 65535 different possibilities. This is of course a "caricature" but that's the spirit of the offset/scale mechanism. In CC we simply maximize the integer part span by default, whatever the actual accuracy of the input values (as we don't know it).

But I can still check that it's actually working with your data just to be sure. Do you have a dropbox or google doc account? Otherwise I can open an FTP account on CC's server. Just send me a private email.

And if people are interested, I can still add an option dialog to let advanced users define their own offset/scale values.

Thanks,

Daniel

[Steven F]

Hey Mathais,

I think I saw your original posting on the photoscan forum. If CloudCompare handles the files correctly, which I'm sure it does, there shouldn't be any loss in accuracy. But some compressibility might be lost by having such an odd scaling factor. Would you mind posting the file sizes of the LAS file from CloudCompare, the LAS file after re-scaling the CloudCompare output, and a LAZ (laszipped) version of both LAS files? It might be helpful for us all to know whether or not re-scaling and re-offsetting really makes a difference when working with files like this. Thanks.

[Daniel Girardeau-Montaut]

Hi again,

We've performed some tests with Mathias data and we can conclude that there's indeed no loss of accuracy due to the way CloudCompare automatically set the offset and scale when saving to LAS/LAZ, even for georeferenced data.

There's an absolute numerical error of 10^-7 which is "standard" in CloudCompare due to the fact that we internally store the values as 32 bits floating point numbers.

About the "compressibilty", I'll be interested by the test results. I don't expect a real difference though: the coordinates in a LAS file are stored as 32 bits integers (whatever the scale is). Using a scale of '0.01' or '0.0000657' is arbitrary and it doesn't make 'nicer' or more regular integers for coordinates (we are dealing with computers here: 0.01 is not a 'simpler' number than 0.0000657 when converted to IEEE 754 floating point representation AND binary representation afterwards ;)... Maybe LAZ files use the scale information to deduce a kind of absolute accuracy to shrink down the coordinates? I don't think so as I believe it is a loss-less compression.

Even if there's no bug in CC, I still think we should add an 'advanced options' dialog for LAS saving so that people requiring particular values for the offset and scale can specify their own.

Daniel

P.S. : here are the coordinates of the first point in Mathias file before and after it has been loaded and saved by CC:

before = (578331.61699999997, 6595830.7400000002, 4.6440000000000001)

after   = (578331.61700058600, 6595830.7399997693, 4.6440000563289630)

--

[Martin Isenburg]

Hello Daniel,

> About the "compressibilty", I'll be
> interested by the test results. I don't
> expect a real difference though

I expect (and have witnessed) an enourmous difference in compression. The LAS formats stores the points quantized to a suitable resolution, usually centimeters (0.01) or millimeters (0.001). That means the range of integer numbers that needs to be compressed for coordinates ranging - for example -  from -1.27 to 25.92 is exactly -127 to 2592 ... namely 2720 different possible values whose differences will be small. If you change the scale factor so that the coordinates range from 0 to 1000000000 instead then we suddenly have 1000000000 different possible values whose differences will be huge (and much more bit-costly to compress).

> Maybe LAZ files use the scale
> information to deduce a kind of
> absolute accuracy to shrink down the
> coordinates? I don't think so as I
> believe it is a loss-less compression.

Yes, LAZ is lossless. It compresses the coordinates at whatever scale they are. Adding "resolution fluff" (e.g. several low-order bits whose content is determined solely by whatever the floating-point arithmetic on inflated scale values puts here) results in larger correction vectors that compress less good. The same loss in compression happens when storing cm rounded points with mm precision (e.g. changing the scale factor from 0.01 to 0.001 while at the same time multiplying all integer coordinates with 10).

> Even if there's no bug in CC, I still think
> we should add an 'advanced options'
> dialog for LAS saving so that people
> requiring particular values for the offset
> and scale can specify their own.

Good idea. Also for all other formats as winzipping or gzipping a PLY, OBJ, PTS or PTX with "resolution fluff" suffers the same lowered compression translating into bulkier storage, more IO, and higher CPU usage as all these uncompressible low-order bits will have to be read back in, decompressed, and - for ASCII formats - also be translated.

Have a look at http://pointzip.org that is a variant of http://laszip.org to compress PTS and PTX files. Offering the option to scale the output results in much "nicer" and less bulky ASCII PTS and PTX files after decompression than the standard 6 decimal digits (micrometer resolution) output by Cyclone.

Remember the diameter of a human hair ranges from 40 to 120 micrometer to the scanned points. Hence the scanned measurements exported by Cyclone have - in theory - enough resolution to compute the exact total hair volume as well as perform a hair brittleness analysis for any perdon who was scanned. But - in practice - neither the density of pulses, nor the laser beam width, nor the ranging accuracy produce points that have micrometer accuracy. Exporting them with micrometer resolution may be a convenient way to be überconservative ... but produces gigantic ASCII files that do not compress well.

I can not even imagine the world-wide savings in storage hardware, network bandwidth, and computation power over the past 20 years if Cyclone would have exported only 4 decimal digits for each coordinate ... maybe we would have a human colony on Mars already. (-;

Regards,

Martin @rapidlasso

[Daniel Girardeau-Montaut]

Thanks Martin, that's informative.

The issue we have in CloudCompare is that we don't only handle laser scanning clouds but any kind of cloud. In metrology applications you will typically need 3 to 6 digits (depending on the units). And it's not always 'real life' objects that are represented by point clouds. One could argue that LAS shouldn't be used for other clouds than LIDAR but I've also seen some strange clouds with km units for instance (so a 0.01 scale won't do).

In the same spirit the older versions of CC were writing ASCII files with 6 digits by default. But some users complained (some even quite violently ;) so we let users set the output precision up to 12 or 16 digits (even if that doesn't have any meaning ;).

So basically we don't 'suppose' anything about the cloud precision and scale in the general case (especially since we don't handle units). This is why we use this 'optimum for accuracy' scale (obviously LAZ compression was clearly out of scope). Moreover most users simply don't understand this offset/scale mechanism... So I guess in addition to the 'advanced parameters' button we should also add a warning message when people save clouds as LAZ (or a kind of 'data profile' so that CC can guess the right 'scale').

Daniel

--