ZFX + Developia

Hi,

Ich muss ein paar Metadaten in einer Bitmap-Datei unterbringen … im Grunde reicht schon ein einziges Byte, aber Platz zur Erweiterung würde nicht schaden. Die Frage ist nun, wo ich die Daten hinschreiben soll, ohne die Kompatibilität zu anderen Programmen zu brechen. Es gibt zwei Möglichkeiten:

• a) Zwischen Informationsblock und Bilddaten darf ungenutzter Platz folgen.
  b) Nach den Bilddaten darf ebenfalls Freiraum folgen, bevor die Datei endet.

Die erste Möglichkeit ist ein klein wenig attraktiver, weil ich dort eh Freiraum einbaue, damit die Pixel 16-Byte-aligned sind. Die eigentliche Frage ist nun aber: Gibt es Bildprogramme, die diesen Platz schon anderweitig interpretieren? Sollte ich den Daten eine Magic Number o.ä. voranstellen? Gibt es vielleicht Sammlungen, in denen ich nachschlagen kann, was es für nonstandard-Extensions für Bitmaps gibt?

Gruß, Ky

Nö, afaik gibt es da keine 'Sammlung'.

Ich denke auch nicht dass es sinnvoll ist in einer BMP-Datei Metadaten unterbringen zu wollen. Lieber eine gleich benannte XML-Datei im Verzeichnis. Das Ausdehnen von Standards (selbst wenn laut Spezifikation legal) ist niemals eine gute Lösung. Ich sage es deswegen, weil ich mich in Assimp seit Monaten mit Exportern herumärgere die solche Spielchen in der einen oder anderen Form treiben.

BMP ist sowieso kritisch. Das Format erlaubt eine ganze Menge (z.B. mehrere Bildebenen oder RLE/PNG/JPG-Kompression), de-facto unterstützen die meisten Loader aber nur ganz normale 8/16/24Bit Bitmaps. Da wäre ich dementsprechend vorsichtig Metadaten unterzubringen, und wenn nur am Dateiende.

Aufgrund der Formatunsicherheit ist BMP imho sowieso ein ungeeignetes Bildformat. Lieber DDS, PNG, (EXR), ...

Danke für die Antwort :)

Aramis hat geschrieben:Lieber eine gleich benannte XML-Datei im Verzeichnis.

Würde ich gerne tun, aber der Loader muss auf Streams anwendbar sein, was soviel bedeutet wie dass er überhaupt nicht weiß, ob die Daten in einer einzelnen Datei liegen und ob die überhaupt einen Namen hat, also auch keine weitere Datei öffnen kann.

Aramis hat geschrieben:Das Ausdehnen von Standards (selbst wenn laut Spezifikation legal) ist niemals eine gute Lösung.

Ja, das stimmt. Allerdings besteht dort ein grundsätzlicher Konflikt: Die Spezifikation schreibt ungenutzten Platz grundsätzlich vor, klärt aber nicht, wie der aussehen soll. Rein theoretisch müsste es für die Loader also keinen Unterschied machen, ob da Nullen stehen, zufälliger Müll oder meine Metadaten. Kritisch wird es nur, wenn dort auch andere Programme nonstandard-Daten erwarten :/

Aramis hat geschrieben:BMP ist sowieso kritisch. Das Format erlaubt eine ganze Menge (z.B. mehrere Bildebenen oder RLE/PNG/JPG-Kompression), de-facto unterstützen die meisten Loader aber nur ganz normale 8/16/24Bit Bitmaps. Da wäre ich dementsprechend vorsichtig Metadaten unterzubringen, und wenn nur am Dateiende.

Ich benutze nur die gängige und relativ einfache Version 3, also keine PNG-/JPEG-Kompression, nur eine Ebene usw.

Aramis hat geschrieben:Aufgrund der Formatunsicherheit ist BMP imho sowieso ein ungeeignetes Bildformat. Lieber DDS, PNG, (EXR), ...

Ich bevorzuge PNG überall wo es geht, wo Daten aber schnell geschrieben werden müssen (Debug-Ausgaben, Kontrollergebnisse usw.) ist BMP unverzichtbar.

wo Daten aber schnell geschrieben werden müssen (Debug-Ausgaben, Kontrollergebnisse usw.) ist BMP unverzichtbar.

Da würde ich irgendwie immer zu TGA greifen :) Glaube da gibts aber auch keine möglichkeit der Metadaten.

Ist TGA nicht noch komplexer zu schreiben? Zumindest erscheint es mir nach Wikipedia so … und da mein Lieblingsbildbetrachter „Paint“ keine TGAs unterstützt fällt es für mich von vornherein weg :D

Krishty hat geschrieben:

Aramis hat geschrieben:Aufgrund der Formatunsicherheit ist BMP imho sowieso ein ungeeignetes Bildformat. Lieber DDS, PNG, (EXR), ...

Ich bevorzuge PNG überall wo es geht, wo Daten aber schnell geschrieben werden müssen (Debug-Ausgaben, Kontrollergebnisse usw.) ist BMP unverzichtbar.

Bist du dir da sicher? Ich meine bei mir war es so, dass jpg/png schneller als bmp war, schlicht und einfach weil das Schreiben auf die Festplatte der Flaschenhals ist, nicht das bisschen CPU Zeit für die Kompression.

Ciao

Helmut hat geschrieben:Bist du dir da sicher? Ich meine bei mir war es so, dass jpg/png schneller als bmp war, schlicht und einfach weil das Schreiben auf die Festplatte der Flaschenhals ist, nicht das bisschen CPU Zeit für die Kompression.

Mein PNG-Writer ist noch nicht auf dem neuesten Stand, darum kann ich es nicht benchen … momentan dauert außerdem das Konvertieren der Bilddaten in ein ausgabefähiges Format rund dreimal so lange wie das eigentliche Schreiben der Datei auf die Festplatte … hast aber natürlich Recht, ich sollte nicht aus den Augen verlieren, wo eigentlich mein Flaschenhals liegt.

Du könntest die Informationen auch direkt im Bild verstecken. Wenn du unkomprimierte BMPs benutzt, dann wird es sicher niemanden auffallen, wenn du von manchen Pixeln ein Bit für deine Informationen verwendest. Dadurch könnte das Bild weiterhin von jedem Programm gelesen werden und du hättest relativ viel Speicherbandbreite zur Verfügung.

Oder du nimmst 32Bpp-Bitmaps und verwendest diesen Pseudo-Alphakanal. Die meisten Bildbetrachter sollten damit klarkommen bzw. ihn ignorieren. Wie auch immer, es bleibt imho eine schlechte Idee :twisted:

Zudomon hat geschrieben:Du könntest die Informationen auch direkt im Bild verstecken.

Verlustfrei - 1 Bit = verlustbehaftet ;) Nein, das geht schon allein deshalb nicht, weil dann jedes Bild aus einem Drittprogramm, das zufällig die richtigen Bits gesetzt hat, falsch geladen würde.

Aramis hat geschrieben:Oder du nimmst 32Bpp-Bitmaps und verwendest diesen Pseudo-Alphakanal. Die meisten Bildbetrachter sollten damit klarkommen bzw. ihn ignorieren.

Der vierte Kanal ist genauso ungenutzter Platz wie das Padding vor den Pixeln, unterscheidet sich aber durch zwei Details: Zum einen kostet er erheblich Speicherplatz und zum zweiten weiß ich von Photoshop, dass er auch tatsächlich ausgewertet wird.

Aramis hat geschrieben:Wie auch immer, es bleibt imho eine schlechte Idee :twisted:

Ist aber leider unumgänglich … ich habe mal die zehn Bytes nach den Headern vollgeschrieben und teste gerade, ob Drittprogramme Probleme damit haben … Bildvorschau, Paint, Paint.NET, Gimp und der DDS Viewer schonmal nicht … aber solche Probleme kommen ja immer dann, wenn man sie nicht erwartet.

Ist TGA nicht noch komplexer zu schreiben?

Also

|Header|
|Data|

find ich nicht kompliziert zu schreiben. 1 Struct, byte aligned natürlich ... 2 Write Operationen und du hast TGAs geschrieben. Dasselbe in Grün beim auslesen. BMP hab ich mir seitdem nie angeguckt.