New scalar field: Normals

[daavoo]

To be added in scalar_fields/k_neighbors.

Use Hugues Hoppe 92 to compute normals based on eigen values.

Use Scipy sparse matrix and graph routines. for build and transverse Riemannian graph.

[ghost]

Hi, how can I use this functionality, to get normal to a point using k neighbors? Thanks

[daavoo]

Hi @jazzyearrings . This issue is still open because I haven't implemented part of the functionality yet.

You can right now obtain the normals with the following code (make sure to re-install or git pull because I just merged a pull request #118 with this):

from pyntcloud import PyntCloud
cloud = PyntCloud.from_file("test/data/sphere.ply")
k_neighbors = cloud.get_neighbors(k=10)
cloud.add_scalar_field("normals", k_neighbors=k_neighbors)

And you should now have 3 new columns in cloud.points (nx, ny, nz) wich represent the x,y,z coordinates of the normal vector associated to each point:

cloud.points.tail()

x	y	z	nx(10)	ny(10)	nz(10)
24.2735	3.026610	-5.16087	0.971312	0.120302	-0.205135
24.6763	2.028710	-3.45929	1.000000	0.000000	0.000000
24.6763	1.740000	-3.61314	1.000000	0.000000	0.000000
24.9189	0.872828	-1.81245	1.000000	0.000000	0.000000
0.0000	0.000000	0.00000	0.000000	0.048083	-0.998843

However please note that this normals are unoriented, meaning that some normals might be flipped and pointing to the opposite direction as they should. This is because when you use PCA to fit the plane to the neighbourhood the orientation of the normal of the plane is ambiguous.

A post-processing of the normals is what I haven't implemented yet.

[felix-tracxpoint]

Are they oriented now or still unoriented?

(Great job, anyhow!)

[daavoo]

@felix-tracxpoint they are still unoriented 👼 I have a working implementation of oriented normals but it makes use of some libraries that I don't really want to add as dependencies because I'm trying to keep dependencies to the minimum. Hopefully will find some time to work on this soon

[felix-tracxpoint]

Are you doing something like this?

[daavoo]

I'm doing exactly that El 8 dic. 2017 18:37, "felix-tracxpoint" <notifications@github.com> escribió:

…

Are you doing something like this <http://www.cloudcompare.org/doc/wiki/index.php?title=Normals%5COrient_Normals_With_Minimum_Spanning_Tree> ? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMFyZXfPS6Oo-5lbPDpMZQrZW6ud9iUCks5s-YHVgaJpZM4MbuE-> .

[cosama]

I just started with pyntcloud, there is really not much out there to fill that niche. Thanks for your great work so far.

I just tried to calculate normals according to your description with a cloud of >100'000 points. It produces a MemoryError in sf_kneighbors.py at graph = np.zeros((n, n), dtype=np.float32).

100'000 points doesn't seem that crazy to me, thus maybe worth looking into a method that is not as memory greedy.

[daavoo]

@cosama Holly guacamoli thank you so much for pointing that. That code should not be merged at master and that is my fault.

The code for orienting the normals is still in progress and I'm still looking for a efficient way of doing the reimanian graph stuff in Python.

[daavoo]

Note.
Take a look at this:
https://onlinelibrary.wiley.com/doi/full/10.1111/cgf.12795
https://github.com/NSchertler/StreamingNormalOrientation

[cosama]

Your welcome. Thanks for the links.

I looked at your last commit of sf_kneighbors.py and reverted it. I do not need any orientation, I just want to know if the normals point more up/down or towards the sides in a certain region. It seems to work fine that way.

By the way, normals are by definition a vector, not a scalar field (I know I'm a bit picky here :) ).

[daavoo]

Unoriented normals added in #163 . No orientation code included for now and remove the code that caused the crash.

Orientation to viewpoint will be added soon.

General orientation is not a very high priority for me but contributions are welcome.