Was ist eine J2K-Datei?

Eine J2K-Datei enthält denselben rohen Codestream für JPEG 2000, den andere Werkzeuge .j2c oder .jpc nennen. Die Erweiterung .j2k ist eine Dateinamenskonvention für dieses eine Format, kein eigenständiger Codec oder Container. Der Inhalt konzentriert sich auf komprimierte Bilddaten, nicht auf Container-Metadaten.

.j2k ist einer von mehreren Namen für einen rohen Codestream für JPEG 2000. Die Werkzeuge von OpenJPEG behandeln .j2k, .j2c und .jpc als dasselbe Eingabeformat. Die IANA-Registrierung des Codestream-Medientyps image/j2c führt j2k als Dateierweiterung auf. Das Decodieren beginnt mit den eigenen Headern des Codestreams, dem SOC-Marker und dem SIZ-Markersegment, nicht mit einer Container-Signatur oder einer Formatkennung des Containers. Die folgenden Markersegmente halten Encoding-Stil, Quantisierung und Progressionsreihenfolge fest. Innerhalb des Streams wird ein Bild als eine oder mehrere rechteckige Kacheln codiert. Die komprimierten Daten jeder Kachel sind in Pakete aufgeteilt, die jeweils zu einer Qualitätsschicht, einer Auflösungsstufe, einer Komponente und einem Precinct gehören. Die Reihenfolge der Pakete einer Kachel ermöglicht es einem Decoder, vorzeitig aufzuhören oder mit reduzierter Auflösung zu decodieren. Eine Pipeline, die Container-Metadaten benötigt, kann denselben Codestream in eine JP2-Datei einbetten. Diese speichert ihn in einer Contiguous-Codestream-Box nach den Boxen JPEG 2000 Signature, File Type und JP2 Header.

Wie sollte eine Pipeline eine Datei mit der Erweiterung .j2k erkennen? Anhand des Inhalts. Ein roher Codestream beginnt mit den Bytes FF 4F FF 51, eine JP2-Datei dagegen mit einer Signaturbox von 12 Byte: 00 00 00 0C 6A 50 20 20 0D 0A 87 0A. Das Werkzeug opj_decompress von OpenJPEG zeigt die sicherere Prüfreihenfolge: Es liest die ersten Bytes. Widersprechen sie der Erweiterung, gibt es eine Warnung zur falschen Erweiterung aus und decodiert anhand der Bytes. Eingaben, deren erste Bytes keiner bekannten Signatur entsprechen, werden als unbekanntes Eingabeformat abgelehnt. Eine Ausnahme ist eine Datei namens .jpt: Sie wird anhand der Erweiterung ohne diese Prüfung akzeptiert.
Was entscheidet, ob ein Werkzeug einen Codestream mit der Erweiterung .j2k oder eine JP2-Datei schreibt? Meist der Ausgabedateiname. Die Dokumentation zu opj_compress von OpenJPEG nennt .j2k und .jp2 als Ausgabeerweiterungen. Pillow wählt die Form anhand der Erweiterung, sofern no_jp2 nicht gesetzt ist. Ist diese Option gesetzt, erzwingt sie einen rohen Codestream. Das Umbenennen einer vorhandenen Datei konvertiert nichts: Die Bytes bleiben ein Codestream oder eine JP2-Datei, unabhängig von der Endung.
Ist eine Datei mit der Erweiterung .j2k verlustbehaftet? Der Name verrät es nicht. Die Kernsyntax erlaubt sowohl den reversiblen Wavelet-Filter 5-3 als auch den irreversiblen Wavelet-Filter 9-7. Sowohl opj_compress von OpenJPEG als auch Pillow verwenden ohne andere Vorgabe den reversiblen Filter. Ein reversibler Filter beweist dennoch keine Verlustfreiheit: Kompressionsverhältnisse oder Qualitätsziele für den Encoder können zu verlustbehafteten Qualitätsschichten führen. Ob die vollständige Datei noch verlustfrei ist, hängt vom Ziel für die letzte Schicht ab. Das Handbuch zu opj_compress beschreibt das Beispiel -r 20,10,1 als „20x komprimieren, dann 10x, dann verlustfrei“: verlustfrei, wenn alle Schichten decodiert werden, verlustbehaftet, wenn es nur die früheren sind. T.800 weist außerdem darauf hin, dass eine reversible Transformation in gekürzten Codestreams für verlustbehaftete Kompression verwendet werden kann.
Was ändert die Progressionsreihenfolge? Die Reihenfolge der Pakete innerhalb jeder Kachel und damit das Ergebnis, wenn diese Kachel nur teilweise gelesen wird. T.800 definiert fünf Reihenfolgen: LRCP, RLCP, RPCL, PCRL und CPRL. Sie werden im COD-Markersegment angegeben und lassen sich mit POC-Markersegmenten ändern. Bei schichtweiser Reihenfolge (LRCP) kann die Qualität mit eintreffenden Daten steigen; bei auflösungsweiser Reihenfolge (RLCP) werden zuerst Versionen aller Komponenten mit niedriger Auflösung geliefert. Da die Reihenfolge innerhalb einer Kachel gilt, garantiert sie bei Dateien mit mehreren Kacheln keine frühe Ansicht des gesamten Bildes: T.800 erlaubt Encodern, Kachelteile verschiedener Kacheln zu verschachteln, schreibt dies aber nicht vor. Ohne Verschachtelung erreicht ein sequenzieller Lesevorgang die Daten einer Kachel erst nach sämtlichen Daten der zuvor gespeicherten Kacheln. T.800 erlaubt außerdem, Kacheldaten durch das Verwerfen abschließender Bytes zu kürzen, sofern die Parameter des Kachellängen-Markersegments die Kürzung widerspiegeln. Die gewählte Reihenfolge bestimmt somit, was eine gekürzte Kachel noch enthält.

Die Formaterkennung sollte den Dateiinhalt untersuchen, da Erweiterungen allein die Varianten von JPEG 2000 nicht zuverlässig unterscheiden. Wird ein Parser gewählt, der nur Container unterstützt, kann die Verarbeitung einer gültigen J2K-Datei fehlschlagen.

Was ist eine J2K-Datei?

So funktionieren J2K-Dateien

Wichtige Fakten

Wann J2K-Dateien relevant sind

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline