Das neue Feature in der Version v1.1 ist der Zusatz eines fraktalkomprimierten Bildlesers innerhalb der Anwendung, der mit ImageIO kompatibel ist.

Daher können Sie ein komprimiertes Bild (.dfc) mit der Anwendung wie folgt lesen:

BufferedImage image = ImageIO.read("image.dfc");

Vergleicht man das Bild im.jpg-Format und im.dfc-Format der Anwendung, sieht man, dass die Qualität etwas schlechter ist als in.jpg und dass es eine etwas größere Datei aufnimmt (wie erwartet).

Aber das Ergebnis ist überhaupt nicht schlecht.

Angesichts der langen Bearbeitungszeit, die für die Komprimierung benötigt wird, sind diese Art der Komprimierung und ihre Umsetzung in der Anwendung jedoch nur von akademischem Interesse.

04/05/2026 - 04/12/2026 . Nachdem ich die Entwicklung dieser Anwendung wiederhergestellt habe, schlage ich vor, Tests mit realen Bildern durchzuführen, und versuche es mit einem von "4000 x 3000" Pixeln.

Ich habe viele Probleme:

• Der Prozess dauert für immer in den geteilten Iterationen (durch die umfangreichen Triangulationen von bis zu 400.000 Dreiecken, und dass die geteilte Bedingungsprüfung für alle Dreiecke in jeder Iteration wiederholt wurde)
• Der Speicher läuft aus, nachdem ich die Grenze von 23 GB erreicht habe, die ich auf meinem System hatte.
  • Das Ergebnis der Split- und Merge-Iterationen wurde in einer booleschen Liste gespeichert (ca. 16 Iterationen x 2 Triangulationstypen x 3 Kanäle x 400.000 Elemente!!!!). Das macht insgesamt rund 40.000.000 Elemente, die noch akzeptabel sind)
  • Darüber hinaus wurde die Auswahl des Buches der repräsentativsten Dreiecke (auf 256 gesetzt) mit einem K-Medoiden durchgeführt (über 400.000 Elemente) (Ich denke, der Speicher, den dieser Algorithmus verwendet, ist O(n^2). Jetzt kommt es aus der Hand...)
  • Und, für mehr INRI, diese Berechnungen wurden parallel für die drei Kanäle durchgeführt (rgb)!!
• Sobald diese Probleme gelöst sind, schaffe ich es, das (4000 x 3000) Bild zu komprimieren, aber ich sehe, dass es zwischen 6 und 8 Stunden dauert, um die Arbeit abzuschließen.

Und ich schlage vor, sie zu lösen:

• Für die Verewigung von Splits. Lösung:
  • Ich erhöhe die minimale Größe der Dreiecke zu teilen, in einer schrittweisen Weise proportional zur Anzahl der Pixel im Bild. Das Ergebnis ist eine Verringerung der Anzahl der Dreiecke in den Dreiecken. Im verwendeten Bild von (4000 x 3000) wird die Anzahl der Dreiecke durch mehr als 4 geteilt (wir gingen von etwa 400.000 Dreiecken auf etwa 100.000 Dreiecke).
  • Außerdem erstelle ich ein Set mit den Dreiecken, die das Split-Kriterium nicht erfüllen (relativ zur Varianz der Werte ihrer Pixel), um sie nicht in jeder Iteration zu wiederholen.
• Das System läuft aus dem Speicher. Lösung:
  • Ergebnis von Splits und Merges, die in booleschen Listen gespeichert sind. Lösung:
    • Während die geteilten Iterationen voranschreiten, ist die Anzahl der Dreiecke, die geteilt werden, radikal kleiner, der verwendete Speicher wird gespeichert, indem die Indizes der Dreiecke gespeichert werden, die sich in einem Satz teilen.
  • Speicher von K-Medoiden (vermutlich O(n^2)). Lösung:
    • Da wir die Anzahl der Dreiecke durch 4 geteilt haben..., den Speicher, der für diesen Algorithmus benötigt wird, beinhaltet diese Reduktion der Dreiecke die Teilung des Speichers, der durch einen Faktor von etwa 16 verwendet wird.
    • Drei K-Medoiden parallel (eine für jeden Kanal). Lösung:
      • Wir sequenzieren die Berechnungen der Triangulationen und die Auswahl der repräsentativsten Dreiecke für das Code-Buch (mit K-Medoiden).
    • Wir haben das Gedächtnis für K-Medoiden von 48 geteilt!!
• Die Bearbeitungszeit mit "echten" Bildern dauert für immer (die Komprimierung des Beispielbildes dauert zwischen 6 und 8 Stunden) mit 3 Threads, einem für jeden Kanal. Lösung:
  • Stellen Sie die Anzahl der Threads konfigurierbar. (Durch die Konfiguration auf 23 Threads (mein System hat 24 Kerne) wird die Bearbeitungszeit auf dreieinhalb Stunden reduziert).
• Auswirkungen der Lösung:
  • Der Effekt der Teilung der Anzahl der Dreiecke durch 4 führt offensichtlich zu einem bemerkenswerten Verlust der Qualität des komprimierten Bildes. Aber mit so viel Auflösung ist es nicht so wichtig.
  • Wenn die Anzahl der Dreiecke durch 4 geteilt wird, wird auch die Größe der komprimierten Datei geteilt, angeblich auch in der Reihenfolge 4.

Ich versuche auch, die Größe der komprimierten Datei zu minimieren, indem ich die zu speichernden Informationen neu organisiere.

Die Idee ist, vor allem in der Kodierung der Indexlisten der Dreiecke, die in jeder der Iterationen, deren ursprüngliche triviale Codierung war, verwenden ein Bit pro Dreieck, die Angabe, ob es sich aufgeteilt oder nicht.

Ich entwickle einen Algorithmus, um zu versuchen, die Größe zu minimieren, die benötigt wird, um jeden dieser Indexsätze zu speichern.

Ich denke, es ist nicht verschwendet... wenn Sie neugierig sind auf dieser Website erkläre ich die wichtigsten Punkte, auf die ich mich verlassen habe.

Obwohl es sich vielleicht mehr gelohnt hätte, nach einem allgemeinen verlustfreien Kompressor wie zip oder 7z zu suchen und ihn auf die Globalität der komprimierten Datei anzuwenden... Vielleicht für das nächste Mal.

In der letzten Version der Lieferung ist eine Befehlsschnittstellenanwendung enthalten, die ein Archiv, das mit weniger optimierten Versionen des Coders erstellt wurde, in die neueste Version des Coders übersetzt, die vermutlich weniger Platz benötigt.

Mit dieser kleinen neuen Anwendung auf einem Paar von Dateien mit der ursprünglichen Kodierung (eine von 143x143 und eine andere von 4000x3000), ist es, dass die Größe der komprimierten Datei um etwa 4% in ihnen reduziert wird.