Support for 64-bit integers and 16-bit floats has been requested enough times that we may add it as a strictly opt-in feature. Note that all of these are already supported by at least one other open-source library, and I wouldn't even consider adding them otherwise.
Opt-in means that when creating a PlyData or PlyElement instance by any means to contain these types, additional keyword arguments would need to be supplied by the user, or the construction would fail as it does now. This should significantly reduce the risk of a user "accidentally" creating a non-conforming PLY file. There should be separate arguments for 64-bit integers and 16-bit floats, like allow_int64 and allow_float16.
The documentation (both reference site and docstrings) would need to clearly spell out that these types are not officially part of the PLY spec.
There is no change to plyfile's policy of not extending the PLY format. This feature is only being considered because a few other implementations do support it and there is clearly some desire to have it in plyfile as well, and I believe that supporting it in this way should primarily improve interoperability with those other implementations without further fragmenting the PLY user base. If that belief is mistaken, then the feature should be dropped.
Support for 64-bit integers and 16-bit floats has been requested enough times that we may add it as a strictly opt-in feature. Note that all of these are already supported by at least one other open-source library, and I wouldn't even consider adding them otherwise.
Opt-in means that when creating a
PlyDataorPlyElementinstance by any means to contain these types, additional keyword arguments would need to be supplied by the user, or the construction would fail as it does now. This should significantly reduce the risk of a user "accidentally" creating a non-conforming PLY file. There should be separate arguments for 64-bit integers and 16-bit floats, likeallow_int64andallow_float16.The documentation (both reference site and docstrings) would need to clearly spell out that these types are not officially part of the PLY spec.
There is no change to
plyfile's policy of not extending the PLY format. This feature is only being considered because a few other implementations do support it and there is clearly some desire to have it inplyfileas well, and I believe that supporting it in this way should primarily improve interoperability with those other implementations without further fragmenting the PLY user base. If that belief is mistaken, then the feature should be dropped.