Was ist eine PLY-Datei?

PLY ist ein Binärformat, das nur einem Programm etwas sagt, das es kennt. Es speichert Formen und Koordinaten statt Bildpunkte und bleibt deshalb in jeder Größe scharf — ein Logo auf Plakatgröße verliert nichts. Eingesetzt wird es für das Scannen und den Austausch zwischen Programmen.

Die Endung lautet .ply, der volle Name Polygon File Format. Beides sagt weniger aus als das, was die Datei halten kann — und davon handelt der Rest dieser Seite.

Stanford University hat es 1994 veröffentlicht.

Einem Format, das so lange lesbar geblieben ist, kann man etwas anvertrauen, das man in zehn Jahren wiederhaben will.

Sie ist vollständig veröffentlicht, das Format lässt sich also aus dem Dokument umsetzen statt durch Nachsehen. Deshalb taucht es in so vielen Programmen auf, und deshalb gehen Dateien von vor zwanzig Jahren heute noch auf. Veröffentlicht heißt allerdings nicht lizenzfrei: Wo ein Format einen Codec einpackt, ist die Patentfrage eine eigene, die der Standard nicht mitbeantwortet.

PLY speichert seinen Inhalt exakt. Erneutes Speichern ändert nichts, es lässt sich also beliebig oft öffnen, bearbeiten und wieder ablegen, ohne dass sich Schaden ansammelt — genau das macht es zu einem Arbeitsformat und nicht zu einem Ausgabeformat.

MeshLab, Blender und CloudCompare lesen es, und die meisten Programme derselben Art ebenfalls.

Wenn eine Datei nicht aufgeht, liegt es selten am Format — häufiger daran, dass das Programm älter ist als das Format. Die Umwandlung in etwas Älteres ist der verlässliche Weg daran vorbei, und dafür gibt es den Rest dieser Website.

Kein Browser liest es.

Das ist der häufigste Grund, es umzuwandeln: nicht dass das Format schlecht wäre, sondern dass die Stelle, an der die Datei erscheinen soll, es nicht lesen kann.

PLY ist zum Öffnen und Ändern gedacht. Behalte die Datei in diesem Format, solange die Arbeit läuft, und exportiere daraus, wann immer eine fertige Fassung gebraucht wird.

PLY entstand Mitte der Neunzigerjahre in Stanford für die Daten eines Laserscanners, und genau dafür wird es bis heute meist verwendet. Photogrammetrie-Software, Handscanner, Streifenlichtscanner, Lidar-Werkzeuge — sie alle sprechen PLY, weil es für das entwickelt wurde, was ein Scanner tatsächlich liefert: Millionen gemessener Punkte, jeder mit den Eigenschaften, die das Gerät an dieser Stelle erfasst hat.

Der Grund, warum es sich so lange gehalten hat, liegt in der Kopfzeile: Sie listet auf, was jeder Punkt mitbringt — Position, Farbe, Normalenvektor, Konfidenzwert, Intensität, was ein bestimmtes Gerät eben misst —, und ein lesendes Programm nimmt, was es versteht. Ein Format von 1994 kann so Daten eines erst letztes Jahr gebauten Instruments transportieren.

OBJ bemalt eine Oberfläche mit einem Bild, das auf sie projiziert wird. PLY macht es meist einfacher: Jeder Punkt trägt seine eigene, an genau dieser Stelle gemessene Farbe.

Für einen Scan ist das die richtige Herangehensweise, denn der Scanner hat Farbe punktweise erfasst, und es gibt ohnehin keine abgewickelte Fläche, auf die man ein Bild legen könnte. Das bedeutet zugleich: Die Farbauflösung ist an die Punktdichte gekoppelt, ein grobes Netz hat grobe Farbe, mehr Detail entsteht nur durch mehr Punkte. Genau das ist der Tausch gegenüber Texturen, bei denen ein Modell mit wenigen Flächen ein sehr feines Bild tragen kann.

Hier entsteht die häufigste Verwirrung. Eine PLY-Datei kann eine reine Liste von Punkten ohne jede Verbindung sein — eine Punktwolke — oder ein echtes Netz mit Flächen zwischen den Punkten. Beides ist gültig, beides trägt dieselbe Dateiendung, und ein Programm, das eines von beidem erwartet, tut mit dem anderen etwas Unpassendes.

Eine Punktwolke, in einem netzbasierten Programm geöffnet, erscheint als feiner Staub aus Punkten oder gar nicht — sie ist nicht beschädigt, es fehlen schlicht die Flächen zum Zeichnen. Aus einer Wolke ein Netz zu machen ist eine Rekonstruktion — etwa mit Poisson- oder Ball-Pivoting-Verfahren in MeshLab oder CloudCompare — und ein eigener Verarbeitungsschritt mit Parametern, keine bloße Formatumwandlung.

Wie bei STL steht die Kodierung in der Kopfzeile. ASCII ist lesbar und rund viermal so groß, Binär ist das, was ein echter Scanner tatsächlich schreibt.

Selbst binär bleiben diese Dateien groß, weil die Punktzahlen es sind. Ein per Smartphone photogrammetrisch erfasstes Objekt liefert routinemäßig zwei bis fünf Millionen Punkte, ein Lidar-Scan eines Raums Zehnmillionen. Bei etwa fünfzehn Byte pro Punkt mit Farbe ergibt eine Erfassung mit hundert Millionen Punkten anderthalb Gigabyte, bevor überhaupt etwas daraus rekonstruiert wurde — das ist für das Format normal und kein Zeichen einer fehlerhaften Ausgabe.

Rohdaten sind nie fertig. Es gibt Hintergrund — Tisch, Boden, Raum —, der weggeschnitten werden muss. Es gibt Ausreißer, einzelne Punkte, die an einer Stelle schweben, weil der Scanner eine Spiegelung oder Kante falsch eingeschätzt hat. Es gibt Löcher dort, wo das Gerät nichts sehen konnte — unter dem Objekt und hinter jeder Überhangung.

Danach folgt Ausdünnung, weil ein Fünf-Millionen-Punkte-Netz für alles Weitere unhandhabbar ist, dann das Schließen der Löcher, und erst dann ein Netz, das sich texturieren oder drucken lässt. MeshLab und CloudCompare sind die freien Werkzeuge für all das. Der Scanner liefert Messwerte, aus Messwerten ein Modell zu machen ist eine eigene und die größere Aufgabe.

PLY nach STL ist der übliche letzte Schritt, und dabei geht die Farbe verloren — STL kennt keine —, während die Form erhalten bleibt. Das ist in aller Regel unproblematisch, denn ein Einzelmaterial-Drucker hätte die Farbe ohnehin nicht nutzen können.

Der Fehler, mit dem man rechnen muss, ist fehlende Wasserdichtheit. Scans haben systembedingt Löcher: Unter dem Objekt wurde nichts gemessen, und überall dort, wo das Instrument keine Sichtlinie hatte, fehlt Detail. Ein Slicer braucht einen eindeutigen Volumenkörper, also müssen die Löcher vor der STL-Ausgabe geschlossen und das Netz geprüft werden. Wer das überspringt, bekommt eine Datei, die der Slicer ablehnt — oder schlimmer, eine, die er annimmt und nach eigenem Ermessen interpretiert.

Erhalten bleiben in jede Richtung: die Dreiecksgeometrie, Namen je Netz, sofern das Zielformat einen Namensplatz vorsieht, und Knotentransformationen, die fest in die Punktkoordinaten eingerechnet werden. Verworfen werden überall Materialien, Texturen, UV-Koordinaten, Normalenvektoren an Ecken und Flächen, Kameras, Lichter, Animationen und die Szenenstruktur — das Zwischenformat kennt nur Punkte und die Dreiecke zwischen ihnen, für Farbe oder ein UV gibt es keinen Platz.

Eine hochgeladene PLY-Punktwolke ohne Flächen wird abgelehnt, weil aus Punkten eine Fläche zu machen eine Rekonstruktion wäre und keine Umwandlung. Beim Schreiben nach PLY entsteht ausschließlich ASCII, mehrere Netze werden zu einem zusammengefasst und die einzelnen Namen gehen dabei verloren — genau wie bei STL. Alles läuft im Browser, ohne dass die Datei irgendwohin hochgeladen wird.

Geht das Modell in eine Spiele-Engine oder einen Web-Viewer, ist glTF die richtige Wahl: Es trägt Texturen, Materialien und eine Szene und ist für Auslieferung gebaut, nicht für Erfassung. Geht es in ein Modellierprogramm zur Weiterbearbeitung, ist OBJ die verbreitetere Wahl. Geht es an einen Drucker, ist es STL.

PLY hat seinen Platz am Anfang der Kette, wo punktweise Eigenschaften und eine erweiterbare Kopfzeile genau das leisten, was gebraucht wird. Bewahren Sie es als das Archiv dessen, was tatsächlich gemessen wurde, und erzeugen Sie daraus die Auslieferungsformate — der umgekehrte Weg, Messwerte aus einem ausgedünnten Netz zu rekonstruieren, ist nicht möglich.