Laden von bestimmten Daten aus TAR Archiv

[FinnK]

Hallo,

ich habe eine Frage bezüglich dem TAR und GZIP Archivformat. Ich möchte ungefähr 100 Bilder in ein Format bringen, dass nicht vom Nutzer geöffnet werden kann (Somit können die Bilder auch nicht bearbeitet werden). Dies ist mir auch schon gelungen mit folgendem Code:

// Erstellt Archiv
OutputStream os = Files.newOutputStream(Paths.get("images.tar"));
GzipCompressorOutputStream gzipOut = new GzipCompressorOutputStream(os);
TarArchiveOutputStream tarOut = new TarArchiveOutputStream(gzipOut);

// Iteriert durch Bilder
for (String inputFile : getImagesIn(inputFolder)) {
    TarArchiveEntry entry = new TarArchiveEntry(Paths.get(inputFile).toFile());
    tarOut.putArchiveEntry(entry);

    // Kopiert Datei in Archiv
    Files.copy(Paths.get(inputFile), tarOut);
    tarOut.closeArchiveEntry();
}

// Schließt Archiv
tarOut.finish();

Nun habe ich das Problem, dass ich erst das Archiv entpacken muss und dann erst die Bilder laden kann.
Heißt ich extrahiere alle Bilder z. B. in %temp% in einen Ordner und lade anschließend die Bilder aus diesem Ordner.
Ich suche schon seit längerem nach einer Möglichkeit, die Bilder direkt aus dem Archiv laden zu können. Angeblich funktioniert das nicht mit TAR und GZIP sondern nur mit ZIP.

Hat von euch einer eine Idee, oder auch eine ganz andere Möglichkeit wie ich das realisieren kann?

Danke im Voraus

 

[Robert Zenz]

Ich möchte ungefähr 100 Bilder in ein Format bringen, dass nicht vom Nutzer geöffnet werden kann (Somit können die Bilder auch nicht bearbeitet werden).

Wenn es ein tar ist, kann man es aufmachen und den Inhalt extrahieren. Wenn ich das richtig sehe, wuerde es bei deinem Format reichen einfach die Dateiendung auf "tar.gz" zu aendern.

Nun habe ich das Problem, dass ich erst das Archiv entpacken muss und dann erst die Bilder laden kann.

Du brauchst eine Implemenierung fuer Java welche es dir erlaubt die Dateien zu streamen direkt aus dem Archiv. Wenn ich das richtig sehe kann dass die Java Standard-Implementierung auch. Was genau hast du denn daran nicht hinbekommen?

 

[mihe7]

Dies ist mir auch schon gelungen mit folgendem Code:

Inwiefern?

Wenn Du Dateien willst, die der Anwender außerhalb der Anwendung nicht öffnen kann, dann musst Du sie in ein unbekanntes Format bringen (gzip, tar und zip sind jetzt nicht gerade unbekannte Formate), z. B. per Verschlüsselung. Das bringt natürlich nur bedingten Schutz, da das Format (bzw. der Schlüssel) der Anwendung bekannt sein muss. Für Otto-Normal-User sollte das aber ausreichen.

Und warum Du Bilder nicht aus einem Tar lesen können solltest, will mir gerade nicht einleuchten.

 

[KonradN]

Ich würde da die Ressourcen in einem jar halten. Wenn man dann ein image baut, dann liegt das schon nicht mehr als einfaches jar vor.

Egal was Du machst ist aber immer wichtig: Das ist reine Security by Obscurity! Damit kannst Du den Opa von nebenan hindern, der gerade einmal einen kleinen Kurs "Internet für ältere Menschen" absolviert hat und froh ist, dass er verstanden hat, dass bestimmte Mausbewegungen den komischen Zeiger auf dem Bildschirm bewegen. Sobald der kleine Nachbars-Junge aus dem Kindergarten (ja, ich übertreibe gerade massiv) aber zu Besuch ist und darauf wartet, dass die Mama von der Arbeit zurück kommt, hast du vermutlich schon ein Problem.

Du kannst es noch erschweren - Auf die Ressourcen greifst Du per getResourceAsStream zu und da hast Du noch einen eigenen DecryptStream oder so, damit die Daten verschlüsselt sind ... Aber wenn jemand an die Bilder im jar heran kommt, dann kommt er auch an den Code von deinem DecryptStream heran. Also keine wirkliche Hürde ...

Dann geht es Dir um Bilder. Die Bilder wirst Du irgendwann irgendwie anzeigen. Das bedeutet, das bekommt schon meine Katze hin: Beim auf die Tastatur legen kommt sie auf die PrintScreen Taste und schon habe ich ein Bild von Deinem Bild ...

Sorry, wenn ich etwas blumig und mit teilweise stark übertriebenen Beispielen gearbeitet habe - aber ich hoffe, dass dieses stilistische Mittel hilft. da meine Sichtweise etwas deutlich zu machen.

 

[FinnK]

Was genau hast du denn daran nicht hinbekommen?

Aktuell lade ich meine Bilder über folgenden Code.

TarArchiveInputStream tarIn = new TarArchiveInputStream(new GzipCompressorInputStream(new FileInputStream("images.tar")));

// Zufälliger Ordner unter %temp%
String tempFolder = System.getProperty("java.io.tmpdir");
File folder = new File(tempFolder, "" + RandomNumber.between(1000000, 9999999));
folder.mkdir();

// Extrahiere Dateien
ArchiveEntry entry;
while ((entry = tarIn.getNextEntry()) != null) {
    // Letzte Position von '/', wichtig für Dateiname
    int last = entry.getName().lastIndexOf("/");
    // Endgültiger Pfad
    String name = folder + "/" + entry.getName().substring(last + 1);
    
    // Kopiere Datei zu erstelltem Ordner
    Files.copy(tarIn, Paths.get(name), StandardCopyOption.REPLACE_EXISTING);
}

// Schließt Stream
tarIn.close();

Ich entpacke quasi erst alle meine Dateien in ein beliebiges Verzeichnis (Irgendwo im %temp%).
Dann lade ich die Bilder über den Pfad im %temp%.

Ich dachte nur, dass da noch ein bisschen mehr Performance möglich wäre, indem ich das Extrahieren überspringe und
in dem Archiv auf meine Daten zugreife.

 

[FinnK]

Ich würde da die Ressourcen in einem jar halten. Wenn man dann ein image baut, dann liegt das schon nicht mehr als einfaches jar vor.

Egal was Du machst ist aber immer wichtig: Das ist reine Security by Obscurity! Damit kannst Du den Opa von nebenan hindern, der gerade einmal einen kleinen Kurs "Internet für ältere Menschen" absolviert hat und froh ist, dass er verstanden hat, dass bestimmte Mausbewegungen den komischen Zeiger auf dem Bildschirm bewegen. Sobald der kleine Nachbars-Junge aus dem Kindergarten (ja, ich übertreibe gerade massiv) aber zu Besuch ist und darauf wartet, dass die Mama von der Arbeit zurück kommt, hast du vermutlich schon ein Problem.

Du kannst es noch erschweren - Auf die Ressourcen greifst Du per getResourceAsStream zu und da hast Du noch einen eigenen DecryptStream oder so, damit die Daten verschlüsselt sind ... Aber wenn jemand an die Bilder im jar heran kommt, dann kommt er auch an den Code von deinem DecryptStream heran. Also keine wirkliche Hürde ...

Dann geht es Dir um Bilder. Die Bilder wirst Du irgendwann irgendwie anzeigen. Das bedeutet, das bekommt schon meine Katze hin: Beim auf die Tastatur legen kommt sie auf die PrintScreen Taste und schon habe ich ein Bild von Deinem Bild ...

Sorry, wenn ich etwas blumig und mit teilweise stark übertriebenen Beispielen gearbeitet habe - aber ich hoffe, dass dieses stilistische Mittel hilft. da meine Sichtweise etwas deutlich zu machen.

Ja da stimme ich dir zu. Ich möchte nur nicht meine Bilder bzw. allgemein meine Daten in einem normalen Ordner oder in einer Zip aufbewahren.

Die Möglichkeit mit der jar hatte ich auch schon in Betracht gezogen.

 

[KonradN]

Ja da stimme ich dir zu. Ich möchte nur nicht meine Bilder bzw. allgemein meine Daten in einem normalen Ordner oder in einer Zip aufbewahren.

Das bezieht sich aber doch nur auf die Dateien während der Entwicklungsprozesses oder nicht? Und da liegen die Dateien alle in dem Ressourcen-Ordner. Das ist bei Maven/Gradle in der Regel src/main/resources.

Daher hast Du als Entwickler eigentlich gar nichts zu tun. Im Rahmen des Build Prozesses werden die Dateien dann mit berücksichtigt, landen in der jar Datei und dann über JLink im Image. JPackage baut daraus dann ggf. noch das AppImage mit Binary so dass Du kein Script hast (das kann unschön sein, z.B. auf dem Mac).

 

[FinnK]

Das bezieht sich aber doch nur auf die Dateien während der Entwicklungsprozesses oder nicht? Und da liegen die Dateien alle in dem Ressourcen-Ordner. Das ist bei Maven/Gradle in der Regel src/main/resources.

Daher hast Du als Entwickler eigentlich gar nichts zu tun. Im Rahmen des Build Prozesses werden die Dateien dann mit berücksichtigt, landen in der jar Datei und dann über JLink im Image. JPackage baut daraus dann ggf. noch das AppImage mit Binary so dass Du kein Script hast (das kann unschön sein, z.B. auf dem Mac).

Aktuell liegen die Dateien unter assets/ (Da wo auch der src/ liegt). Das hat den Grund, da ich möchte dass die Dateien getrennt vom Programm sind. Wenn ich mein Programm installiere, befindet sich dann im Ordner eine .exe (Gewrappte? .jar) und mein assets Ordner, den ich zuvor zu einem Tar Archiv gemacht habe. Ohne diesen Schritt würde halt der bloße Ordner mit allen Dateien dem Nutzer vorliegen, was ich nicht möchte.

Ich werde morgen nochmal ein bisschen zu dem Thema recherchieren.

 

[mrBrown]

Ja da stimme ich dir zu. Ich möchte nur nicht meine Bilder bzw. allgemein meine Daten in einem normalen Ordner oder in einer Zip aufbewahren.

Und was ist an einer tar anders als bei einer zip?

 

[FinnK]

Und was ist an einer tar anders als bei einer zip?

Naja gefühlt jeder hat auf seinem Rechner WinRar oder 7zip. Mit diesen Programmen lassen sich keine tar's (zumindest nicht meine) öffnen. Natürlich lassen sich tar's iegendwie mit bestimmter Software öffnen.

 

[Robert Zenz]

Naja gefühlt jeder hat auf seinem Rechner WinRar oder 7zip.

WinRar ja, aber 7zip kann tars. Weisz jetzt nicht was bei deinen schief laeuft, vielleicht die Erkennung weil es nicht ".tar.gz" ist, oder die Java GZIP Implementierung ist komisch (ich bilde mir ein den Fall mal gehabt zu haben).

 

[FinnK]

Weisz jetzt nicht was bei deinen schief laeuft, vielleicht die Erkennung weil es nicht ".tar.gz" ist

Da hast du Recht. Wenn ich .gz hinten anhänge, kann 7zip einfach das Archiv öffnen und die Dateien einsehen...
Brauch ich wohl eine andere Möglichkeit, um dem Nutzer das Öffnen eines Archives zu erschweren.

Danke

 

[KonradN]

Also ich kann Dich ehrlich gesagt nicht wirklich verstehen, denn für mich stellt sich das in etwa so dar:
Du versuchst irgendwie, da dein Gartentor sicher zu machen mit irgendwelchen Schlössern, aber du hast links und rechts keinen Zaun und jeder, der rein will, geht einfach neben dem Tor vorbei.
(Du machst Dir Sorgen um dein Archiv und dabei entpackst Du die Dateien sogar selbst auf dem Rechner. Und Du zeigst die Bilder vermutlich auch an...)

Und dann habe ich Dich so verstanden, dass Du ein jar File hast, das Du mit irgend einem Tool in eine exe packst (So dass da vermutlich niemand an die Klassen kommen kann zum decompilieren) ....

Wieso also nicht die Bilde auch in dem jar File halten? Da kannst Du diese dann auch lesen ohne sie vorher irgendwohin zu entpacken.

 

[Neumi5694]

Naja gefühlt jeder hat auf seinem Rechner WinRar oder 7zip. Mit diesen Programmen lassen sich keine tar's (zumindest nicht meine) öffnen. Natürlich lassen sich tar's iegendwie mit bestimmter Software öffnen.

WinRAR kann TARs öffnen. TAR ist nichts anderes als eine Ansammlung von Dateien, um ungenutzten freien Blockspeicherf zu sparen.

Wenn du möglichst offen für alles und jeden sein willst, verwende ZIP, das kann nun wirklich jedes Betriebssystem, unter Linux verwendet man halt heutzutage 7z, Windows kann das von sich aus lesen, Mac auch.

Da du aber das Gegenteil willst ... verwende Encryption. Verwende ein Passwort zum Erstellen deiner Dateien oder aber verschlüssle die Dateien selbst, dann musst du sie beim Verwenden halt erst mal wieder entschlüsseln. Performance sollte nicht deine Hauptsorge sein.

 

[FinnK]

Und dann habe ich Dich so verstanden, dass Du ein jar File hast, das Du mit irgend einem Tool in eine exe packst (So dass da vermutlich niemand an die Klassen kommen kann zum decompilieren) ....

Das ist richtig.

Wieso also nicht die Bilde auch in dem jar File halten? Da kannst Du diese dann auch lesen ohne sie vorher irgendwohin zu entpacken.

Es hat sich bei meinen Tests herausgestellt, dass Bilder (oder egal welche Dateien) schneller außerhalb der jar geladen werden, als wenn ich sie im jar über den ClassPath lade. Deswegen dachte ich wird es mit Sicherheit eine Möglichkeit geben, meinen assets/ Ordner ein wenig sicherer zu machen, sodass nicht jeder Nutzer ihn entpacken, ändern und wieder einfügen kann.

Da sich jetzt herausgestellt hat, dass 7zip tar Dateien öffnen kann, werde ich wohl auf eine andere Möglichkeit umsteigen (z. B. die Bilder doch in meinem jar halten).

 

[FinnK]

Da du aber das Gegenteil willst ... verwende Encryption. Verwende ein Passwort zum Erstellen deiner Dateien oder aber verschlüssle die Dateien selbst, dann musst du sie beim Verwenden halt erst mal wieder entschlüsseln.

Danke für die Alternative mit dem Passwort und der Encryption.

Performance sollte nicht deine Hauptsorge sein.

Leider mittlerweile schon. Ich lade ungefähr 100 - 150 Bilder. Ungefähr dauert das Laden der Bilder ungefähr 8 Sekunden - mit meinem tar ungefähr 11 Sekunden.

Ich werde mich mal damit beschäftigen.

 

[Robert Zenz]

Leider mittlerweile schon. Ich lade ungefähr 100 - 150 Bilder.

Wie grosz sind diese Bilder?

 

[FinnK]

Wie grosz sind diese Bilder?

Um genau zu sein sind es 235 Bilder. Insgesamt sind diese rund 10 MB groß.

Hier mein Einlese-Algorithmus:

    public static BufferedImage loadImage(String path) {
        try {
            BufferedImage original = ImageIO.read(new File(path));

            return toCompatibleImage(original);
        } catch (Exception e) {
            e.printStackTrace();
            return null;
        }
    }

    public static BufferedImage toCompatibleImage(BufferedImage image) {
        if (gfxConfig == null) initialize();

        if (image.getColorModel().equals(gfxConfig.getColorModel())) {
            return image;
        }
        BufferedImage newImage = gfxConfig.createCompatibleImage(image.getWidth(), image.getHeight(), BufferedImage.TYPE_INT_ARGB);

        Graphics2D g2d = newImage.createGraphics();
        g2d.drawImage(image, 0, 0, null);
        g2d.dispose();

        return newImage;
    }

Falls es Verbesserungsvorschläge dazu gibt, gerne schreiben.

 

[Neumi5694]

Um genau zu sein sind es 235 Bilder. Insgesamt sind diese rund 10 MB groß.

Hier mein Einlese-Algorithmus:

    public static BufferedImage loadImage(String path) {
        try {
            BufferedImage original = ImageIO.read(new File(path));
            BufferedImage image = new BufferedImage(original.getWidth(), original.getHeight(), BufferedImage.TYPE_INT_ARGB_PRE);

            Graphics2D g = image.createGraphics();
            g.drawImage(original, 0, 0, null);
            g.dispose();

            return toCompatibleImage(image);
        } catch (Exception e) {
            e.printStackTrace();
            return null;
        }
    }

    public static BufferedImage toCompatibleImage(BufferedImage image) {
        if (gfxConfig == null) initialize();

        if (image.getColorModel().equals(gfxConfig.getColorModel())) {
            return image;
        }
        BufferedImage newImage = gfxConfig.createCompatibleImage(image.getWidth(), image.getHeight(), BufferedImage.TYPE_INT_ARGB);

        Graphics2D g2d = newImage.createGraphics();
        g2d.drawImage(image, 0, 0, null);
        g2d.dispose();

        return newImage;
    }

Falls es Verbesserungsvorschläge dazu gibt, gerne schreiben.

Warum du ein Bufferedimage erstellst, in welches du ein anderes BufferedImage zeichnest, lass ich jetzt mal dahingestellt. Ich hätt's einfach nur geklont.
Was du machen kannst: 10 MB sind jetzt nicht wirklich viel. Lies den gesamten Inhalt ein, häng die einzelnen Objekte in eine Queue, welche dann von einem oder mehreren Threads abgearbeitet wird, welche die Bilder decodieren.

ps: Öffnest du die Resource jedesmal neu, wenn du ein Bild einlesen willst? Falls sich alles in einer Datei befindet und du eh alles einlesen willst, solltest du auch nur einen Zugriff starten.
Ein Jar ist nichts anderes als eine Zip-Datei. Falls du mit Jar arbeitest, kannst du den normalen Zip-Reader von Java verwenden.

 

[FinnK]

Warum du ein Bufferedimage erstellst, in welches du ein anderes BufferedImage zeichnest, lass ich jetzt mal dahingestellt. Ich hätt's einfach nur geklont.

Ups, da hast du vollkommen Recht. Ist im Code geändert.

Was du machen kannst: 10 MB sind jetzt nicht wirklich viel. Lies den gesamten Inhalt ein, häng die einzelnen Objekte in eine Queue, welche dann von einem oder mehreren Threads abgearbeitet wird, welche die Bilder decodieren.

Danke, hört sich interessant an.

ps: Öffnest du die Resource jedesmal neu, wenn du ein Bild einlesen willst? Falls sich alles in einer Datei befindet und du eh alles einlesen willst, solltest du auch nur einen Zugriff starten.

Nein, es gibt nur einen Zugriff.

 

[Robert Zenz]

Um genau zu sein sind es 235 Bilder. Insgesamt sind diese rund 10 MB groß.

Das klingt nach einer Tilemap oder etwas vergleichbaren, vielleicht waere es interessant hier einen Atlas zu verwenden. Wobei mich die 8 Sekunden etwas wundern, das klingt nach viel zu viel, insbesondere wenn du das streamst aus dem Archiv.

 

[Neumi5694]

Ups, da hast du vollkommen Recht. Ist im Code geändert.


Danke, hört sich interessant an.


Nein, es gibt nur einen Zugriff.

ps: Was ich noch sagen wollte, das decodieren per Thread kann natürlich auch parallel zum Einlesen passieren, du musst damit nicht warten, bis alles eingelesen ist, sondern nur, bis das erste Element vorhanden ist.
Nachdem fertig eingelesen ist, wartest du also so lange, bis die Queue wieder leer ist (die Decoder also ihre Arbeit beendet haben) und kannst dann loslegen. Das Decodieren müsste eigentlich deutlich schneller gehen als das Einlesen, weswegen diese letzte Wartezeig gegen 0 geht.

Und schau mal nach, ob du außen rum noch was anderes machst oder das Ganze mehrfach, die angegebene Zeit ist nämlich wirklich heftig.

Was man für zelda-artige Spielhintergründe und Animationen gerne macht: Anstatt vieler kleiner Bilder ein großes einlesen, in dem die vielen kleinen platziert sind (ich denke, @Robert Zenz hat das mit der Tilemap gemeint?), die kann man dannzur Laufzeit entweder immer noch aufteilen oder holt sich für die Verwendung den entsprechenden Ausschnitt raus.

 

[FinnK]

Wobei mich die 8 Sekunden etwas wundern, das klingt nach viel zu viel, insbesondere wenn du das streamst aus dem Archiv.

Dank @Neumi5694 seiner Methode mit den mehreren Threads, werden jetzt die Bilder in ungefähr 4 Sekunden geladen.

 

[FinnK]

Und schau mal nach, ob du außen rum noch was anderes machst oder das Ganze mehrfach, die angegebene Zeit ist nämlich wirklich heftig.

Ja das wundert mich auch. Die Bilder werden nur einmal beim Start geladen und in einer HashMap gespeichert, sodass ich auf sie zugreifen kann.

Was man für zelda-artige Spielhintergründe und Animationen gerne macht: Anstatt vieler kleiner Bilder ein großes einlesen, in dem die vielen kleinen platziert sind (ich denke, @Robert Zenz hat das mit der Tilemap gemeint?), die kann man dannzur Laufzeit entweder immer noch aufteilen oder holt sich für die Verwendung den entsprechenden Ausschnitt raus.

Ich verwende bei den meisten Bildern (Wo es auch Sinn macht) schon Spritesheets. Diese werden eingelesen und später dann in mehrere kleine Bilder unterteilt.