Good question! Here is the (almost compliant) APA style citation:
(where X is the sub-version number and YYYY the current year)Edit (2016/1/07)
Code: Select all
CloudCompare (version 2.X) [GPL software]. (YYYY). Retrieved from http://www.cloudcompare.org/
I removed EDF R&D and Telecom ParisTech from the citation as CC is now an open-source project with a lot of contributions. Therefore I don't think that we could list all of 'rightholders' here...Edit (2014/10/28)
When citing CloudCompare in a scientific article (which is good ;) several common issues are often made.1. Cite the plugin author first
When you use a particular plugin you should also (or at least
- if you want to cite only one source) cite the plugin's author.
This is particularly true for plugins relying on academic work or third party libraries (i.e. most of them!):2. Know what you measure (and what you get ;)
When you use the 'simple' Cloud-to-cloud distance computation tool:
- Ask yourself if you could gain something by using a 'local modelization strategy' (see [[Distances_Computation | Distances computation]]). Especially if your reference cloud is very sparse (i.e. with a very low density). It's simple, just a little bit slower and potentially much accurate when considering global statistics on the whole cloud (such as the mean value and standard deviation for instance). If you have doubts or questions, don't hesitate to send an email to the author (cloudcompare [at] danielgm.net).
- Speaking of global statistics, please mind that the output of the Cloud-to-cloud distance computation tool is unsigned (i.e. no negative values). So there's absolutely no chance that the result follows a Normal Distribution. Sometimes the error/deformation/etc. you are measuring does follow a Normal distribution, but even in this (ideal) case the output unsigned scalar field follows a Folded Normal Distribution (http://en.wikipedia.org/wiki/Folded_normal_distribution).
The 'Edit > Scalar Fields > Compute Stat. Params
' tool doesn't take this into account. It simply and blindly fits a Normal distribution
to the current scalar field (a future version will let the user specify if the scalar field is folded
But in any case (and this is a more general consideration, not only applicable to CloudCompare output) if your samples don't follow a Normal distribution, first you can clearly visualize that the theoretical Normal distribution doesn't fit well... and then you have to ask yourself if the corresponding parameters (mean values, standard deviation, etc.) have any meaning at all?
Waiting for a proper mean to compute the 'Folded Normal Distribution' parameters: