Rätselhaftes BitMap-Pic

[TuxPeter]

Ich habe jetzt eine ganze Weile mit diesen Pics rumgefummelt und möchte Euch das kleine Software-Abenteuer nicht vorenthalten.

Mein Handheld-Oszilloskop kann Screenshots speichern, was eine feine Sache ist. Noch besser ist, dass diese auch per USB auf den PC übertragen werden können. Dort werden die Pics als "Windows-BMP-Bild" erkannt und lassen sich z.B. mit meinen Standard-Viewern gthumb und gpicviw darstellen.

Leider ist die Darstellung ziemlich unbrauchbar, da komplett umgedreht: Die linke Seite rechts und die rechte Seite links. außerdem fehlt oben ein kleiner Streifen. Nun, Gimp stellt das Bild völlig korrekt dar. Merkwürdig nur: wenn man das Bild mit der Funktion "Überschreiben" der Ausgangsdatei abspeichert, dann kann es anschließend nicht wieder geöffnet werden.

Gimp meldet dann: "... konnte nicht geöffnet werden: Unbekanntes oder ungültiges BMP-Komprimierungsformat."

gpicview und ristretto sagen es kürzer: "Vorspanndaten des BMP-Bildes sind Unsinn", und auch die anderen Viewer funktionieren nicht.

Nun, man kann das Bild unter gimp als ~jpeg abspeichern, spart viel Platz und die Qualität ist auch völlig ausreichend, ist halt ein wenig umständlich.

Dann gibt es dann noch die wunderbare Imagemagick-Suite mit dem schönen Befehl "display". Und dieser hat nicht die geringsten Probleme, alles korrekt darzustellen. Mehr noch, es gibt dort auch den Befehl "mogrify", und der korrigiert den Fehler:

Code: Alles auswählen

$ mogrify -strip 1_strip.bmp

mogrify-im6.q16: length and filesize do not match `1_strip.bmp' @ error/bmp.c/ReadBMPImage/854.

Das Bild hat sich anschließend von ca 800 kiB auf 1,1 MiB aufgebläht und funktioniert überall tadellos. Somit habe ich schon eine Idee, worin des Rätsels Lösung entsteht, möchte diese Vermutung hier aber nicht verraten.

Nun habe ich gerade das kaputte ~bmp in ~gif umbenannt und wollte es in die Galerie hochladen (weil die Galerie zwar ~gif, aber nicht ~bmp akzeptiert), falls jemand auch damit spielen möchte. Leider ist die Forensoftware zu schlau und verweigert sich, weil "die Größe nicht ermittelt werden kann". Nun denn, dann eben nur der Text.

[Tintom]

Du könntest mittels cat <Bilddatei>|base64 > bild.b64 daraus einen Text generieren und das nach nopaste laden.

[DeletedUserReAsG]

Was ist deine Frage? Unabhängig davon wäre die Benennung des Oszis und das Zurverfügungstellen eines Beispielbilds bei der Fehlersuche sicher hilfreicher, als ellenlange Prosa.

[Meillo]

Ich finde die Backgroundstory ganz interessant. Auch wenn sie die Loesung des Raetsels fuer TuxPeter verzoegert, so habe ich daran mein Wissen schon erweitert.


Zur Loesungssuche: Was sagen `file' und `mediainfo' zu den Dateien? Die kaputten Dateien koenntest du mal im Editor aufmachen. Manchmal kann man da erkennen, wo die Probleme liegen, gerade wenn der ``Vorspann'' Unsinn sei, dann muss der Beginn der Datei ja irgendwie anders aussehen, als bei anderen Dateien gleichen Formats.

[DeletedUserReAsG]

Ich finde die Backgroundstory ganz interessant.

Interessant wäre eine Beispieldatei, die Benennung des konkreten Geräts, sowie eine Frage dazu gewesen

[Meillo]

Ich finde die Backgroundstory ganz interessant.

Interessant wäre eine Beispieldatei, die Benennung des konkreten Geräts, sowie eine Frage dazu gewesen

Nur Geduld, die Breite der Geschichte beginnt sich ja erst zu entfalten. Lehne dich zurueck und geniesse.

[GregorS]

Ich frage mich gerade, ob es im OP tatsächlich kein Fragezeichen gibt, oder ob ich es übersehen habe.

Interessant wäre eine ... Frage dazu gewesen

Scheinbar habe ich es wohl doch nicht übersehen.

Gruß

Gregor

[TuxPeter]

Hi,

danke für Eure Beiträge, ich wollte allerdings keinen Unwillen erregen, sondern nur ein bisschen zur allgemeinen Unterhaltung beitragen.
Das Gerät, das die Bilder liefert, heißt Frnrsi 1013 D, hier ein Hersteller-Link: http://www.fnirsi.cn/productinfo/419011.html Es sind leicht diverse Tests und Besprechungen von Heise bis zu Bastler-Blogs zu finden, den von mir festgestellten Fehler fand ich allerdings nicht erwähnt.

Ich habe jetzt mal das fehlerhafte Teil, als jpeg neu abgespeichert, hochgeladen:

Original sollte es wie folgt aussehen (hier mittels mogrify --strip von fehlerhaften Daten befreit):

(es musste für die Forum-Galerie als ~gif umbenannt werden)

Habe übrigens gerade festgestellt, dass Firefox sich auch von den fehlerhaften Header-Daten nicht beirren lässt und das Bild trotzdem richtig darstellt. Eine sichere Lösung des Rätsels wäre wohl nur zu erreichen, wenn man man die gif- und bmp- Standards vergleicht und das Ding daraufhin mit einem Hex-Editor untersucht, worauf ich nun gar keine Lust habe, zumal der Workaround mit dem mogrify ja ganz prima funktioniert. Und außerdem kann ich die Firmware des O'scopes sowieso nicht ändern.

Hätte ja sein können, dass jemandem ein ähnliches Phänomen schon mal begegnet ist.

Wenn ich übrigens einen längeren Textstring in einem mehrzeiligen Fenster strikt am Rande umbreche (ohne Zeilen- und Word-Umbruch, Silbentrennung etc!), dann kann ich durch Einfügen oder Löschen am Anfang ganz ähnlichen Effekt erreichen! An alten Fernsehern, wenn die Zeilensynchronisation schlapp macht, gibt es auch so etwas.

Einen schönen Abend noch!
wünscht
TuxPeter

[Meillo]

Eine sichere Lösung des Rätsels wäre wohl nur zu erreichen, wenn man man die gif- und bmp- Standards vergleicht und das Ding daraufhin mit einem Hex-Editor untersucht, worauf ich nun gar keine Lust habe, zumal der Workaround mit dem mogrify ja ganz prima funktioniert. Und außerdem kann ich die Firmware des O'scopes sowieso nicht ändern.

Das ist jetzt aber unfair von deiner Seite: erst uns heiss zu machen, mit dem Problem und dann sagen, dass es sich fuer dich erledigt hat und uns haengen zu lassen! Da mogelst du dich aus der Affaire.

Jetzt, wo du schon damit angefangen hast, wollen wir auch Beispieldateien sehen, damit zumindest *wir* das Problem genauer untersuchen koennen.

Stelle uns also bitte eine unveraenderte Originaldatei bereit. Entweder als Zip/Tar verpackt, falls das im Nopaste geht, oder nach Tintoms Vorschlag base64-kodiert.

Ich finde, das bist du uns schuldig.

[TuxPeter]

Finde ja auch, dass Ihr die Dateien zum Spielen bekommen solltet. ABER:
nachdem ich das kaputte bmp nicht in die Galerie bekommen habe ...

Nun habe ich meine recht verkümmerte Bekanntschaft mit zip und tar erneuert. Geht alles, nur dass nopaste die nicht frisst!

Und ganz neu war für mich: base64. Hat auch funktioniert, leider, leider: geht auch nicht nach nopaste!

Code: Alles auswählen

ls *bmp
1.bmp  1_gimp_out.bmp  1_strip.bmp

cat 1.bmp | base64 > 1_bmp_b64

base64 -d 1_bmp_b64 > 1.bmp

Und läßt sich auch einwandfrei wieder herstellen.
Tja, da werde ich mir wohl noch was überlegen.

[MSfree]

Code: Alles auswählen

cat 1.bmp | base64 > 1_bmp_b64
base64 -d 1_bmp_b64 > 1.bmp

Und läßt sich auch einwandfrei wieder herstellen.

Das könnte am useless use of cat liegen
Ausserdem überschreibst du dir die Ursprungsdatei beim Decoden.

Versuch es mal mit

Code: Alles auswählen

base64 1.bmp> 1_bmp_b64
base64 -d 1_bmp_b64 > 1_decoded.bmp

[TuxPeter]

@msfree: Klar, das war nur'n Beispiel. Zum Testen habe ich's in 'nem anderen Verzeichnis ausgepackt.

Aber hiermit solltet Ihr nun endlich in den Besitz der Bildchen kommen können:
(Es geht doch nix über eine eigenen HP)

https://jodre.de/Raetselhafte-BitmapPics/

MfG
TuxPeter

[MSfree]

Was als erstes auffällt ist, daß 1.bmp eine Tiefe von 16 Bit (maximal 65536 verschiedene Farben) verwendet. Die konvertierten Versionen sind 24Bit. 16 Bit ist relativ exotisch und könnte den Schluckauf mit diversen Programmen erklären.

[Meillo]

Ich schaue mir gerade den Header (erste 14 Bytes) an. Die Groesse der Datei stimmt bei 1.bmp z.B. schonmal nicht genau. (Wobei in der Wikipedia steht, dass die nicht zwangslaeufig genau stimmen muss.): c5ff8 = 811000 ... die Datei ist aber genau 800000 Bytes gross. Bei den anderen zwei Dateien ist der Wert korrekt.

Dann unterscheidet sich der Offset to Image Data massiv. In den korrekten Bildern ist es jeweils 8a = 138 Bytes, d.h. die 14 Bytes Header plus weitere 124 Bytes weitere Header. Bei 1.bmp dagegen ist der Wert 4e20 = 20000. Wenn ich durch den Hexdump scrolle, dann sieht es ab da dann auch so aehnlich aus wie in den anderen Dateien ab 8a. D.h. die Problemdatei hat viel mehr weitere Header. Da gibt es wohl allerlei Varianten, was man an weiteren Headern nutzen kann. Das koennen die Programme wohl nicht.

Allerdings frage ich mich, warum `file' die Datei nur als ``data'' anzeigt, wenn der Hauptheader korrekt da ist. Vielleicht ist irgendwie begrenzt, wieviel Headerdata es geben darf und 20000 Bytes sind ausserhalb der Spec. Da bin ich nicht Experte genug.


https://de.wikipedia.org/wiki/Windows_Bitmap
https://en.wikipedia.org/wiki/BMP_file_format

[TuxPeter]

Was ich auch verwunderlich finde (hier noch mal der Output von identify aus Imagemagick):

Code: Alles auswählen

dentify 1.bmp
1.bmp BMP3 800x480 800x480+0+0 8-bit sRGB 800000B 0.000u 0:00.003
identify-im6.q16: length and filesize do not match `1.bmp' @ error/bmp.c/ReadBMPImage/854.

identify 1-stripped.bmp 
1-stripped.bmp BMP 800x480 800x480+0+0 8-bit sRGB 1.09876MiB 0.000u 0:00.001

identify 1_gimp_out.bmp 
1_gimp_out.bmp BMP 800x480 800x480+0+0 8-bit sRGB 1.09876MiB 0.010u 0:00.001

Der Output von gimp kann also von gimp selber sowie diversen anderen Viewern nicht wieder eingelesen werden, sieht aber zunächst gleich aus. Wenn ich das ausmultipliziere 800 * 480 * 3 / 1024 / 1024 komme ich ja auf diese 1.0986328125 MiB etwa. Passt, da ja die Header dazu kommen. Da muss dann noch was anderes faul sein. Denn wie kommt man von dem kleineren Originalfile auf das größere "gestrippte"?

[Meillo]

Denn wie kommt man von dem kleineren Originalfile auf das größere "gestrippte"?

-strip
strip image of all profiles and comments

Es gibt keinen direkten Zusammenhang zwischen Stripping und der Dateigroesse. Beim Strippen werden zwar ggf. vorhandene Kommentare, Metadaten und Profile entfernt, aber die Bilddaten koennten auf ausfuehrlichere Weise abgelegt sein. Lass dich davon nicht irritieren.

[MSfree]

aber die Bilddaten koennten auf ausfuehrlichere Weise abgelegt sein.

Das hatte ich oben schon geschrieben:
1.bmp hat 16 Bit pro Pixel. Die beiden anderen haben 24 Bit pro Pixel, benötigen also 50% mehr Platz.

[Meillo]

aber die Bilddaten koennten auf ausfuehrlichere Weise abgelegt sein.

Das hatte ich oben schon geschrieben:
1.bmp hat 16 Bit pro Pixel. Die beiden anderen haben 24 Bit pro Pixel, benötigen also 50% mehr Platz.

An diese Implikation deiner Aussage hatte ich nicht gedacht, aber klar.


Was mich noch interessieren wuerde, sind die Bedeutung der weiteren Header in 1.bmp, also was das fuer Zeug ist, um dadurch vielleicht darauf schliessen zu koennen, warum das nicht erkannt wird.

Kennt jemand von euch ein Programm, mit dem man die Inhalte einer Bilddatei byteweise grafisch aufbereiten lassen kann, damit man z.B. so eine Darstellung bekommt: https://en.wikipedia.org/wiki/File:BMPfileFormat.svg ? ... mit den konkreten Werten und am besten mit Link in die Hexdump-Darstellung. Das waere ein tolles Hilfsmittel in dem Fall.

[TuxPeter]

Baustelle direkt nebenan:

Ich habe jetzt noch ein wenig mit gimp gespielt und auch andere Bilder benutzt und dabei festgestellt, dass unser gutes Grafik-Flaggschiff anscheinend überhaupt nur kaputte ~bmp produzieren kann, die weder von gimp selbst noch von anderen Bilddarstellern gelesen werden können (außer "display" von Imagemagick, welches alle meine Versuche korrekt darstellt.) Ich habe dabei die vorgegebene Standardeinstellung von gimp benutzt: RL-codiert nein, Kompatibilitätsoptionen und erweiterte Optionen ja. Kann oder mag das jemand nachvollziehen? (gimp 2.10.22 unter Stable)

__________________________________________________
Edit:
Nachtrag, weiter getestet:
Anscheinend sind hier die vorgegebenen Params nicht ganz tauglich:
Habe mal aufs Geratewohl folgendes eingestellt:
Kompatibilitätsoptionen -> Farbrauminformation nicht schreiben
und unter
Erweiterte Optionen -> 16 bit -> R5 G6 B5
Damit ergeben sich allgemein darstellbare bmp's

[MSfree]

Wenn ich 1.bmp mit gimp (2.10.22) als 16 Bit BMP exportiere, kann ich das Bild auch wieder mit gimp lesen. Wenn ich es als 24 Bit BMP exportiere, ist das Bild kaputt und gimp meldet eine illegale Kompression. Der BMP Code, den gimp verwendet, ist also irgendwo fehlerhaft.

BMP ansich ist aber ein furchtbares Bildformat. Urspünglich wurde es für Icons in Windows 2.0 "erfunden". Folglich war es auch nur für "Bildchen" mit 16x16 Pixeln gedacht. Für so primitive Anwendungen ist BMP aber viel zu kompliziert aufgebaut (Typisch MS eben).

[TuxPeter]

OK, ich wäre sonst auch nie auf die Idee gekommen, irgendwas mit ~bmp zu machen, wenn es nicht eben von diesem O'scope so angeliefert worden wäre. Möglicherweise wird dieses alte Zeug von den gimp-Entwicklern auch nicht besonders ausführlich beäugt, und Fehler fallen selten auf - wer braucht das schon, vor allem in der output-Funktion.

Vermutlich ist das Format zum Codieren des O'scope-Screens recht hardwarenahe, sozusagen 1 : 1, brauchbar. Und wurde somit mit minimalem Entwicklungsaufwand auch gleich in die Export-Funktion gepackt.

[DeletedUserReAsG]

Vermutlich ist das Format zum Codieren des O'scope-Screens recht hardwarenahe, sozusagen 1 : 1, brauchbar. Und wurde somit mit minimalem Entwicklungsaufwand auch gleich in die Export-Funktion gepackt.

… zumindest können’s andere Hersteller besser: hier vorliegend sind Siglent und Owon; die Bitmaps beider Geräte sind absolut unauffällig. Bitmaps von Rigol hatte ich auch schon in den Fingern, und kann mich nicht an Probleme damit erinnern.

[michaa7]

OK, ich wäre sonst auch nie auf die Idee gekommen, irgendwas mit ~bmp zu machen, wenn es nicht eben von diesem O'scope so angeliefert worden wäre. Möglicherweise wird dieses alte Zeug von den gimp-Entwicklern auch nicht besonders ausführlich beäugt, und Fehler fallen selten auf - wer braucht das schon, vor allem in der output-Funktion.

... wäre aber einen bugreport gegen gimp wert ...

[DeletedUserReAsG]

wäre aber einen bugreport gegen gimp wert

Allerdings auch an die Adresse des Herstellers: Gimp ist ja laut Eingangsbeitrag nicht das einzige Programm, welches über das Bildformat stolpert. Kann natürlich auch sein, das alle der Programme die gleiche Lib für das Format nutzen, und der Fehler dort ist – in dem Fall ginge der Bugreport am besten in deren Richtung.

[Meillo]

wäre aber einen bugreport gegen gimp wert

Allerdings auch an die Adresse des Herstellers: Gimp ist ja laut Eingangsbeitrag nicht das einzige Programm, welches über das Bildformat stolpert. Kann natürlich auch sein, das alle der Programme die gleiche Lib für das Format nutzen, und der Fehler dort ist – in dem Fall ginge der Bugreport am besten in deren Richtung.

Ich denke, dass michaa7 den falschen Post zitiert hat. Das was MSfree geschrieben hat, ist der Grund fuer einen Bugreport gegen Gimp. (Falls Gimp wiederum eine Lib fuer BMP nutzt, dann ist es die Aufgabe der Entwickler den Bugreport weiterzureichen.)

Das Problem mit dem Originalbild sollte an den Hersteller des Oszilloskops gemeldet werden.