add float16, int64, and uint64

[christian-rauch]

Add additional data type mappings.

See NumPy types:
https://numpy.org/doc/stable/user/basics.types.html
and the same mappings in trimesh:
https://github.com/mikedh/trimesh/blob/a513c0e2cfa6dfbd3121a6dfd8ceb002b9ef55d8/trimesh/exchange/ply.py#L16-L36

---

📚 Documentation preview 📚: https://python-plyfile--87.org.readthedocs.build/en/87/

[dranjan]

Hey @christian-rauch, thanks for the interest and the contribution. The reason those types aren't supported by plyfile is that they are not officially part of the PLY format. This project is pretty conservative about extending the PLY format (see https://python-plyfile.readthedocs.io/en/latest/developing.html#contribution-guidelines), and we would only consider it if either the proposed extension is already widespread, or if the author of the format (Greg Turk) approves of it.

This exact proposal has come up before, and it was rejected for these reasons, but I'm always willing to revisit the question given new information. I did what I did then: do a quick survey of other PLY format implementations to see what they do.

• Greg Turk's C implementation still does not support 16-bit floats or 64-bit integers.
• A few other implementations simply depend on or embed Diego Nehab's C implementation RPly, which also doesn't support them.
• Of around 10 other implementations I could find, only 2 (including trimesh) support 64-bit integers, and only trimesh supports 16-bit floats. The most popular libraries do not seem to support these extensions.

Based on that, I'm not especially inclined to accept the extension at this time, but if you have more information or context to share, please do. In particular, if PLY files with these nonstandard property types are becoming more common, that would be good to know, as well as where they are coming from.

[christian-rauch]

Well, these types did not exist when the original C implementation was created. I am not aware of any updates to that implementation.

Since you explicitly use structured NumPy arrays, I assumed that you also support all the conventional data types.

[dranjan]

Greg Turk's code has a 2020 Copyright, so it has definitely been updated in some way. My only point with mentioning all this is that the author seems to be still active in the domain recently and thus there may still be a chance to get an official opinion from him, if you want to go that route.

We definitely don't support all NumPy data types in plyfile, e.g. complex scalars being another one we obviously don't support. A data type simply being available in NumPy isn't sufficient for plyfile to support it. The goal of plyfile is primarily to interoperate with other PLY implementations, not simply to back NumPy arrays. If that's your goal then there are actually much better data formats than PLY, but then of course you might get stuck using NumPy to read and write them.

That goal of interoperability is also why I've stated my position the way I did: if some nonstandard extensions become widely supported enough that their absence in plyfile becomes a major impediment in practice, then I'm open to adding them in plyfile. However, prematurely adding nonstandard extensions to plyfile does the exact opposite of what we want: it makes it more likely that plyfile will output files that can't be read by other implementations, which hurts interoperability.

[christian-rauch]

You are right about the copyright. The source from https://faculty.cc.gatech.edu/~turk/ply.tar.gz also states:

This source code is no longer actively being developed, but hopefully some
people still find it useful for their work.

In terms of standardisation, this is not maintained any more and there is unfortunately also not other way of standardisation, except just putting it out there waiting for others to pick it up.

I understand that you do not want this library to generate files with data types, that cannot be read by other libraries. Maybe you could have these data types as non-standard extensions and show a warning when such a file is exported? Otherwise, the PLY format will stay as it is, and someone has to come up with "PLY 2.0" and push the format.

[dranjan]

... and there is unfortunately also not other way of standardisation, except just putting it out there waiting for others to pick it up.

I don't buy this, since the author is still around and coauthoring research publications as recently as this month, even if his reference implementation is no longer actively developed. Actually though, since the format was developed at Stanford University, it may be they who technically "own" it, so to speak, and they're certainly still around.

My main point is that it really isn't my place, from my little corner of the ecosystem, to extend the format. If you really want a "PLY 2.0," then there's a principled way to go about it, which requires corresponding with whomever is the rightful steward of the format, presumably either the Stanford Computer Graphics Lab or Greg Turk. If you want to do that, more power to you, but it should be done by those who need the feature and can argue their use case properly, so not me (at least at this time).

All that being said, if we want to make this a strictly opt-in experimental feature so that there's negligible risk of someone creating a non-conforming PLY file without knowing what they're doing, I think I could stomach that.

[dranjan]

Closing for now, but see #88.