Bilder sinnvoll in XML speichern

[CalganX]

Hi,
ich würde gerne Bilder in einer XML-Datei speichern und zwar so, dass sie unter C# problemlos geladen und geschrieben werden können.
Hat da jemand eine gute Idee, wie man das sinnvoll anstellen könnte?

Chris

[Grendel]

Du könntest z.B. die Bilder hexadezimal oder Base64 encodiert ins xml einfügen und nach dem Auslesen wieder in Binärdaten umwandeln.

Bis neulich ...

[CalganX]

Hi,

Zitat:

Zitat von Grendel

Du könntest z.B. die Bilder hexadezimal oder Base64 encodiert ins xml einfügen und nach dem Auslesen wieder in Binärdaten umwandeln.

ich schätze dann aber mal, dass die XML-Datei unermesslich groß wird, da ja wiederrum jede Darstellung erneut 8bit pro Zeichen benötigt und dadurch das ganze ja acht mal größer werden sollte, als die Ausgangsdatei, oder? :gruebel:

Chris

[Tubos]

Schau dir mal Base64 an. Kenne ich nicht wirklich, aber nach Überfliegen des Wikipedia-Artikels stelle ich fest dass man für 6 Bit (= 0,75 Byte) ein Zeichen braucht - es geht also nicht besonders viel Speicherplatz drauf.

Würde mich aber interessieren ob man es irgendwie anstellen kann das gar kein Platz verloren geht obwohl XML verwendet wird.

[dizzy]

Zitat:

Zitat von Tubos

Würde mich aber interessieren ob man es irgendwie anstellen kann das gar kein Platz verloren geht obwohl XML verwendet wird.

Da XML so einfach keine Binärdaten zulässt (da reservierte Ausdrücke für die Strukturierung existieren, die eine Binärdatei "zufällig" produzieren könnte), geht es an sich nicht ohne Konvertierung nach Base64. Um aber Platz zu sparen könnte man sich (vorm Base64) einer Kompression bedienen. RLE, Huffman oder LZW-Typen sind mal ein paar die Verlustfrei arbeiten, wobei RLE eher geringe Kompression verspricht (ja nach Bildinhalt), dafür aber recht simpel ist vergl. zu den anderen beiden.
Falls Verluste nicht das Problem sind: JPEG in Base64 und das ins XML ;) (Oder PNG/GIF für verlustfrei - da spart man sich das Selbstschreiben eines Kompressors.)

[Robert Marquardt]

Das XPM File Format, das unter Linux gebraeuchlich ist, koennte das geeignetste sein.

[Hador]

Zitat:

Zitat von dizzy

wobei RLE eher geringe Kompression verspricht (ja nach Bildinhalt), dafür aber recht simpel ist vergl. zu den anderen beiden.

In der Codelib gibts den in Pascal umgesetzten Huffman Algo.

Und sonst: Huffman,

[bigg]

Hi, :)

was hälst du davon, nur den Dateipfad des Bildes in die XML-Datei zu schreiben?
Oder ist dir das zu unprofessionell?

[CalganX]

Hi,
danke für die Ideen. Ich werde sie mir noch genauer ansehen, wenn ich mal wieder etwas Zeit habe. :)

@bigg: Das Problem ist, dass ich eigentlich alles in einer Datei haben möchte und nicht alles herumfliegen lassen will. Sonst kommt ein User auf die Idee einfach mal die Bilddateien zu löschen oder sowas. Alles in der XML-Datei ist einfach... praktischer. ;)

Chris

[mschaefer]

Moin, moin,

Bin der Auffassung, das XML das Format der Wahl für den Dateiaustausch zwischen sonst inkompatiblen Systemen ist.
Damit ist die Dateigröße kein wirkliches Argument. Zumindest nicht für den Anfang eines solchen Projektes.
Wenn das ein Argument wäre, dann würde man die gepackten Bildformate nehmen.

Da die die Standartschrift für Kommandos reserviert ist und hier kein Parser ducheinander kommen soll,
würde ich das zunächst mal ganz trivial anfangen:

1: in XML setze Bildangangstoken <Picture>
2: Speicher das Bild in einen Stream
3: greife byteweise jedes Bildbyte aus dem Stream
4: Teile das Bildbyte in zwei xml-Bytes.
Dabei könnten die unteren vier Bits
jeweils komplett gesetzt werden und
auf die zwei oberen vier Bitbereiche
teilst Du das Bildbyte auf.
5: setze Bildendtoken </Picture>


Grüße // Martin

[CalganX]

Hi Martin,
hm... du hast vielleicht Recht aber ich wähle hier XML, weil ich dafür außer dem Framework, was ich ohnehin brauche, kein übergroßes Datenbanksystem benötige und mir XML persönlich gefällt. ;)

Nur eine Frage zum Verständnis:

Zitat:

4: Teile das Bildbyte in zwei xml-Bytes.

Warum soll ich denn das Bild vergrößeren? Was hat das für einen Vorteil, dass ich mehr Bytes in Anspruch nehme? Dann kann ich ja eigentlich auch das Bild Bit-für-Bit übernehmen...

Chris

[dizzy]

Zitat:

Zitat von Chakotay1308

Warum soll ich denn das Bild vergrößeren? Was hat das für einen Vorteil, dass ich mehr Bytes in Anspruch nehme? Dann kann ich ja eigentlich auch das Bild Bit-für-Bit übernehmen...

Eben nicht. Die Idee dahinter war vermutlich, dass so garantiert werden soll, dass die binären Bildinformationen nicht zufällig eine Zeichenfolge produzieren die dem XML-Parser als Token vorkommen. Eine Variante wäre es wie beschrieben zu machen, und die Bilddatei dabei in ihrer Größe zu verdoppeln, aber genau die selbe Intention hat man ja bei Base64 auch! Nur dass dabei im Schnitt nur 1.25-fach statt 2-fach Daten anfallen.

[mschaefer]

Hi Chris,

ja das mit XML als portables Format ist meiner Meinung nach sinnvoll, den es ist die Sturkutr nachvollziehbar. Das ein soches Format nicht Byteeffizient ist, liegt auf der Hand, ist aber für den Datenaustausch eigentlich kein relevantes Problem.

Fabian, hat meine Intention voll getroffen. Das mit Base64 trifft es auch auf den Punkt, wollte aber zunächst mal den prinzipiellen Weg nehmen. Da kommt mir noch so ein Gdanke: Es müßte eigentlich auch XML-Komponenten geben die Blob-Felder aufnehmen. Da muß das Problem doch schon gelöst sein....

Heute Abend ist Schluß mit Computer, werde morgen mal nachrecherchieren, da gibt es bestimmt was.

Grüße // Martin

[CalganX]

Hi,
ich werde mir das mal mit Base64 ansehen. Ich denke das wird die Beste Möglichkeit sein. :)

@Martin: naja, eigentlich will ich keine Komponente, da ich mit dem Namespace System.Xml eigentlich ganz zufrieden bin. ;)

Chris