Mehrere Bilder in einer Datei Speichern

[Mavarik]

Hi!

Macht es doch nicht so kompliziert...

Speicher die Bilder doch einfach hintereinander in eine Datei...

Erst ein Word oder Longint der Größe und dann das JPG... usw..
Dann kannst Du Dich einfach durch seeken...

Oder Speichere eine zusätzliche Indextabelle mit den Seeknummer auf die Bilderstarts und die Länge...

Fertig... Programmieraufwand keine 3 Minuten...

(Fast kürzer als die Antwort hier zu tippen)

Frank

[Christian.Ossi]

Wie das genau funktioniert mit den Seek-Nummern und hintereinander speichern würde mich mal interessieren

[himitsu]

schau mal in die OH ... stichwort seek

im Prinzip gibt es da 2 Möglichkeiten.

entweder alle bilder hintereinander und vor jedes Bild dessen Größe
Größe1, Bild1,
Größe2, Bild2,
Größe3, Bild3

oder erst ein "Array" mit den ganzen Positionen und Größen und dahinter die Bilder.
Position1, Größe1,
Position2, Größe2,
Position3, Größe3,
EndMarker,
Bild1,
Bild2,
Bild3

Anzahl,
Position1, Größe1,
Position2, Größe2,
Position3, Größe3,
Bild1,
Bild2,
Bild3

Letzere wären wohl besser, wenn man ein bestimmtes Bild will
und Ersteres macht sich besser, wenn man alle Bilder der Reihe nach auslesen will und nich erst die gesammte "Tabelle" zwischenspeichern will

Größe = Größe in Byte, damit man weiß wieviel man rausladen muß, wenn man das Bild will
Position = Position in der Datei, also an welcher Stelle das Bild beginnt.

Möglich wären och noch sowas
Anzahl,
Position1,
Position2,
Position3,
Größe1, Bild1,
Größe2, Bild2,
Größe3, Bild3

Position1,
Position2,
Position3,
EndMarker,
Größe1, Bild1,
Größe2, Bild2,
Größe3, Bild3


Bei den Varianten mit einr Tabelle am Anfang kann man halt ganz einfach mit
Seek(DateiHandle, Index * GrößeDerEinträge);
Read(DateiHandle, VariableFürEinenEintrag); // PS: PseudoCode, also nicht direkt so verwenden
die Werte für ein bestimmtes Bild besorgen.

Und dann direkt zu dem gewünschten Bild springen und dieses auslesen
Seek(DateiHandle, VariableFürEinenEintrag.Position);
Read(DateiHandle, Bild, VariableFürEinenEintrag.Größe);

Oder halt (wenn die Größe vorm Bild ist);
Seek(DateiHandle, VariableFürEinenEintrag.Position);
Read(DateiHandle, Größe);
Read(DateiHandle, Bild, Größe);


Wenn du ohne Tabelle arbeitest, dann müstest du dich ja jedesmal vom ersten Bild aus, über jedes einzelne Bild hinweg, bis zum entsprechenden Bild durchhangeln.

[Der_Unwissende]

Zitat von Christian.Ossi:

Wie das genau funktioniert mit den Seek-Nummern und hintereinander speichern würde mich mal interessieren

Also eigentlich sind das nur die Grundlagen eines TStream Objekts. Wenn dir hier die OH anschaust TStream wirst du schon so ziemlich alles finden was es zu wissen gibt. Die Idee ist einfach, du hast einen Stream ich bezeichne ihn einfach mal als ein völlig dynamisches Array von Bytes. Und du kennst die aktuelle Position auf der du dich befindest. Jede Aktion, die du ausführst ist immer relativ zu dieser Position. Schreibst du etwas, so wird es nicht automatisch hinten rangehangen, du schreibst einfach die Anzahl der angegebenen Bytes an die aktuelle Position (und ff). Gleiches gilt für das Lesen. Auch hier darfst du nicht davon ausgehen, dass du deine aktuelle Position bei 0 beginnt. Insbesondere gilt dies, wenn du die Position auf 0 setzt, einen Wert einliest und diesen nun überschreiben möchtest. Zum Überschreiben müsstest du nun erst zurück zur 0!

Da du als kleinste Einheit, die du speichern kannst ein Byte hast, wird die Anzahl der zu lesenden bzw. zu schreibenden Bytes angegeben. Ein Stream speichert alle Bytes die man ihm gibt (typ ist const, also beliebig), hat aber deshalb keine Größeninformationen. Möchtest du etwas speichern und wieder einlesen, so wird häufig der Trick angewendet, dass man erst die Anzahl der Bytes angibt, gefolgt von dem Datensatz. Die Anzahl der Bytes muss dann dabei in einer festen Größe (z.B. 4 Byte = Cardinal/Integer) abgelegt werden:

Delphi-Quellcode:

var stream : TStream;
    data : TByteDynArray;
begin 
  // data füllen
  ... 
  
  stream := TMemoryStream.Create;
  // wichtig, verwende einen Ressourcenschutzblock
  try
    stream.Position := 0;
    stream.write(length(data), sizeOf(Integer));
    stream.write(data[0], length(data));

    // weitere Daten hinzufügen und speichern des Streams
    ...
  finally
    stream.Free
  end; 

  finalize(data);
  setLength(data, 0);
end;

Hier soll nur einfach gezeigt werden, wie du das speichern würdest. Du weißt nun, dass deine Datei mit 4 Byte beginnt (die Länge des Arrays). Hast du die Länge x ausgelesen, sind die nächsten x Byte also das hier gespeicherte Array. Dahinter kommt dann die nächste Länge und das nächste Array.

Natürlich wäre es jetzt sehr nervig, wenn du jedesmal über die gesamte Datei laufen müsstest, um all diese Informationen zu holen. Ein weiteres Problem, du hast wenig Flexibilität. Wenn du mehr Meta-Infos benötigst als die Größe, so kannst du die nicht einfach einfügen, du kannst sie ja nicht von den Daten einer alten Datei unterscheiden. Also müsstest du die alten Dateien komplett neu anlegen.
Deshalb gibt es verschiedene Alternative Möglichkeiten. Da sich unabhängig von den Metadaten die Nutzdaten nicht ändern, kannst du einfach zwei Dateien verwalten. Die eine ist dann nur ein Stream, in dem die Nutzdaten einfach nur hintereinander stehen. Damit du nun weißt an welcher Stelle was steht und wie viel Bytes es einnimmt, speicherst du diese Informationen seperat in einer zweiten Datei.
Weitere Alternativen sind Dateiheader. Hier schreibst du die Metadaten an den Anfang (oder unüblicher an das Ende) der Datei. Wenn du diesen Bereich (beliebiger Größe) als solchen Kennzeichnest (spezielle Bytefolgen), so weißt du wo der Header anfängt und wo er endet. Die Erreichte Flexibilität hängt dann nur noch davon ab, wie geschickt der Header implementiert ist. Tiffs zum Beispiel haben ein sehr flexibles Containerformat, dass einem so ziemlich alles ermöglicht (man kann Multipage-Tiffs erstellen, die dann wirklich mehr als ein Bild enthalten, man könnte aber auch noch zusätzlich eine Zip Datei, ein Avi und ein Windowsimage in die Datei packen. Die letzteren Fälle müssten nur nicht von einem Standardkonformen Programm verstanden werden, doch das Tiff wäre valide).

Natürlich hast du die volle Flexibilität wenn du ein Stream verwendest. Aber ein Virtuelles Dateisystem und ein Archiv sind letztlich auch nur Kapselungen vom Selbigen. Ich bleib hier einfach mal bei einem Zip-Archiv. Hier wird intern auch nur ein Stream mit sehr speziellen Headern erzeugt, aber du musst dich nicht darum kümmern. Wo genau ein abgelegtes File anfängt und wo es endet weiß das Archiv, du sagst nur, leg die Datei ab und hol mir die Datei wieder. Natürlich kann ein Archiv noch etwas mehr, du hast automatisch eine Verschlüsselung (Zip-Passwort) oder eben nicht (kein Passwort), du hast eine Checksumme für die Konsistenzprüfung und natürlich wenn du möchtest Kompression. Was du davon verwendest ist dann deine Sache.
Ich will dir hier gar nicht von Streams abraten, nur braucht man von Zeit zu Zeit nicht das Rad neu erfinden...

[gintasdx]

Finally found info how to store image data in XML node.
Stream position always must be set manually to zero it seems,else no data is saved.

[Iwo Asnet]

Zitat von Mavarik:

Macht es doch nicht so kompliziert...
Speicher die Bilder doch einfach hintereinander in eine Datei...

Mach es doch nicht so kompliziert ...
Speicher die Bilder doch einfach in einer DB..