✔ DATA-URL statt Images - Größe

[ComFreek]

Dann reicht es bei der ID vollkommen aus, wenn du auf INT 11 Stellen angibst, weil das reicht dann von 1 bis 99.999.999.999 Einträgen

Wenn du INT(11) meinst, dann hat die 11 übrigens gar nichts mit der Anzahl der benutzbaren Stellen zu tun. Siehe z. B. hier: http://stackoverflow.com/a/6921637/603003 Es geht lediglich darum, wie viel Stellen von der MySQL-Konsole selbst dargestellt werden.

 

[Alice]

@ComFreek

Kennst Du dich nicht mit XML aus?

Ich habe mal zum Testen 120 "Grafiken" aus der XML-Datei in ein Array gepackt und als Image (Image-Tag) ausgegeben. Ladezeit ist ein bisschen länger als eine normale Seite.

ABER: Niemand bekommt die Grafiken zu sehen. Diese sollen und werden nur von IMagick (SVG-Datei) verarbeitet.

Was ist für mein Vorhaben besser geeignet?

Ich lade die Grafiken folgendermaßen.

<?php
  $xml = simplexml_load_file("Kaffee.xml") or die("Error: Cannot create object");

  $Image[] = $xml->xpath("Kaffee-Varianten/Kaffee-Gold/800-Euro");
  $Image[] = $xml->xpath("Kaffee-Varianten/Kaffee-Gold/700-Euro");
  $Image[] = $xml->xpath("Kaffee-Varianten/Kaffee-Normal/5-Euro");
  $Image[] = $xml->xpath("Kaffee-Varianten/Kaffee-LowBudget/3-Euro");
...
...
...
...
...
...

  foreach ($Image as $IMG)
  {
  echo '<img height="50px" style="padding:1px;" src="'.$IMG[0].'" />'."\n";
  }
?>

Der Vorteil in meinen "laien" Augen.

- XML wird nur einmal geladen
- Ich kann das Image-Array an beliebigen Stellen im Skript befüllen
- Bin ich nicht auf MySQL angewiesen

 

[ComFreek]

Was ist für mein Vorhaben besser geeignet?

Was sind die zwei Alternativen? DB vs XML?

Wieso lädst du nicht gleich alle I-Tags per XPath? $XML->xpath("//I")

 

[Alice]

Ich bin da ganz offen.

Ich habe mich auch mit den Gedanken an "DATA-URL's" gewöhnt und frage mich: Wieso bin ich nicht schon vorher darauf gekommen?

Wichtig ist für mich:
Die Url's bequem laden und entsprechend zuweisen zu können. Die Url's werden immer in einer Finalen SVG gespeichert und diese wird dann ins PNG-Format konvertiert.

Ich habe nur in einer Sache bedenken:
Die XML wird Zwangsläufig noch etwas größer, weil noch ein paar "Grafiken" dazu kommen. Ich schätze 200 MB als "Finale" Version.

Von dir weiß ich: Du bist ein Experte! Eine Eierlegende Wollmilchsau für jeden laien. Kannst Du mir etwas vorschlagen? Wenn ja: Bitte mit kurzer Begründung.

 

[ComFreek]

Ich fasse nochmal kurz zusammen:

- Du möchtest Bilddaten speichern.
- Du möchtest Bilddaten in einer finalen SVG referenzieren. Dies geht nur mit Data URIs, da echte Pfade von deiner ImageMagick-Installation nicht unterstützt werden.

Die Frage ist nun, was das beste Speicherformat für die Bilddaten ist, um sie später gezielt im SVG einzusetzen.

In einer XML-Datei Data URIs zu speichern, ist eher eine schlechte Lösung, wenn man immer die ganze Datei laden muss, bevor man mit den Daten arbeiten kann. Als einfache Lösung bietet sich z. B. ein SAX-Parser an. Hierbei ist es meist so, dass du bei einer Callback-Funktion, die für jedes gefundene Element (ggf. sogar entsprechend einem von dir gewählten Filterschema) aufgerufen wird, die Möglichkeit hast, die Daten zu speichern. Der Vorteil ist, dass nicht alle Daten auf einmal im Arbeitsspeicher Platz finden müssen.

Die (relationale) DB hat den Vorteil, dass du die Bilder auch später anderweitig in der DB referenzieren kannst. Selbst in der DB würde ich keine Data URIs speichern, sondern nur die Pfade zu den Originalbildern. Die Data URIs würde ich "on the fly" generieren - natürlich mit einem Cache dieser in Dateien. Die Pfade zu den Cache Dateien kannst du ggf. auch in der DB speichern. Aber wenn du keine DB möchtest, kannst du auch nur mit dem Dateisystem arbeiten.

Wie viel eingebettete Bilder landen denn endgültig in einer SVG-Datei?

 

[Alice]

Wenn möglich möchte ich doch gerne auf Grafiken im Form von üblichen Rastergrafiken in Zukunft verzichten.

Warum?

Die kleinsten Grafiken sind 415x415px groß. Die größte knapp 10000x5000px. Der Durchschnitt liegt in der Mitte. Davon sind knapp 2700 vorhanden. Die Verwaltung habe ich schon immer als "störend" empfunden.

In einer Finalen SVG landen durchschnittlich 15 Grafiken.

PS: Habe das Skript Testweise so umgebaut, dass nun DATA-URL's statt Grafiken eingebunden werden und gefühlt ist das Skript nun sogar schneller als je zuvor.

 

[ComFreek]

Wie oft pro Sekunde/Minute/Stunde muss das Skript eine finale SVG produzieren?

Ich empfinde die Dateisystemlösung mit Cache immer noch als die einfachste.

 

[Alice]

Das kann ich nicht genau sagen. Die User sollen das Skript ja verwenden. Also zwischen 0-5000 mal am Tag ist alles drin würde ich sagen.

Wobei ich sagen muss: Ich klicke auf "Start" und das Teil läuft 2 Sekunden. Für die Mange an "Berechnungen" ist das der Hammer.

 

[ComFreek]

Um den Cache-Gedanken nochmal ein wenig auszuführen:

Du hast erst einmal deine Originaldatei:
img/myfile1.png

Innerhalb deines Skriptes stellst du fest, dass du diese brauchst. Also prüfst du, ob folgende Datei existiert:
cache/myfile1.datauri

Existiert sie, wird sie einfach geladen. Existiert sie noch nicht, wird sie generiert und gespeichert.

Wenn du irgendwann feststellst, dass das Prüfen auf die Existenz einer Datei zum Performance-Bottleneck wird, kannst du auch eine Liste aller Dateien irgendwo zwischenspeichern. Anscheinend hast du aber sowieso nur eine unveränderliche Anzahl an Bildern, die von vornherein feststeht, sodass du dir sicher sein kannst, dass eine Data-URI-Datei existiert.