Citation

[mankoff]

If I want to cite or reference CloudCompare in a manuscript, do you have a preferred format?

[daniel]

Good question! Here is the (almost compliant) APA style citation:

Code: Select all

CloudCompare (version 2.X) [GPL software]. (YYYY). Retrieved from http://www.cloudcompare.org/

(where X is the sub-version number and YYYY the current year)

Edit (2016/1/07)

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!):

• refer to the 'Plugins' section of the wiki: http://www.cloudcompare.org/doc/wiki/in ... le=Plugins (all the sources should be up-to-date now)

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 or not).

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?

cc_bad_distribution_fit.jpg (38.11 KiB) Viewed 583927 times

Waiting for a proper mean to compute the 'Folded Normal Distribution' parameters:

• a way to get signed distances is to convert the reference cloud to a triangular mesh
• another way is to use the more evolved distance computation method named M3C2 and developed by D. Lague et al. (see http://www.cloudcompare.org/doc/wiki/in ... PluginM3C2)

[rossparsons]

How would I cite an in-text citation? (APA format?)

Thanks,
Ross

[daniel]

Well if I believe http://libguides.jcu.edu.au/content.php ... id=4158512 ("no rights holder" version) you could use (CloudCompare, YYYY) or what may be clearer (CloudCompare 2.X, YYYY).