Das deutsche QBasic- und FreeBASIC-Forum

[Azrael]

Hallo!
Ich hab mir vor kurzem Free Basic herunter geladen und bin sehr angetan von diesem Produkt. Auch die Einarbeit ist sehr einfach. Nun stoß ich aber bei meinem ersten Projekt auf ein Problem:

Wenn ich ein Image über imagecreate erstelle, dann bekomme ich ja einen Pointer auf den reservierten Speicherbereich. Nun aber meine Frage, wie ist das Image aufgebaut? Existiert evtl. ein Header, der das Image genauer beschreibt, wie sind die Daten aufgelistet, und in welchem Datentyp?
Gibt es auch andere Methoden, Daten des Images auszulesen?
Der Point befehl schien nur auf den ersten Blick hilfreich. Oder hab ich dort was übersehen?

Ich hab schon das Forum durchsucht und auch die englische und deutsche Referenz, bin aber auf keinen Hinweis gestoßen.

Danke schonmal im Voraus.

[jb]

Du kannst ganz einfach mit den Drawing Primitives auf das Feld zugreifen, das du
mit IMAGECREATE erstellt hast, wenn du das meinst...

jb

[Azrael]

>"Diese Funktion reserviert einen Speicherbereich, in dem Pixeldaten gepuffert
werden können. Sobald dieser Puffer erstellt wurde, können alle
Drawing Primitives (Einfachste Grafikfunktionen) darauf zugreifen.
Bei seiner Erstellung wird der Speicherbereich mit der angegebenen Farbe oder
der Transparenzfarbe des jeweiligen Modus ausgefüllt (Für indizierte
Grafikmodi ist die Transparenzfarbe 0, für alle anderen ist es &HFF00FF)."

Das steht ja schon in der Referenz (übrigens sehr ausführlich ) Mich interessiert bloß, wie jener Puffer aufgebaut ist. Wenn ich zum Beispiel Daten des Images (seis Größe, seins Pixel) auslesen möchte, dann kann ich über den Pointer zugreifen. Bloß weiß ich nicht, in welchem Datentyp die Daten ausgelesen werden müssen, um was sinnvolles damit anzustellen. Und ich weiß nicht, ob nur die Bilddaten gespeichert sind, oder noch andere Sachen.

Der Point Befehl scheint ja auch zu den Drawing Primitives zu gehören, aber wie kann ich mit dem auf Images zugreifen?

Ich hoffe ich drück mich nicht zu umständlich aus.

[Lutz Ifer]

Servus!

Die ersten vier Byte sind Höhe und Breite, danach (zumindestes in den gebräuchlichsten 24 oder 32 bpp Farbtiefe) &H00rrggbb für ein Pixel.
Daher auch die Größe des allozierten Speichers: 4+(4*h*b) Byte

(Der Vollständigkeit halber: theoretisch "aarrggbb", mit alpha-channel...)

Hoffe, das war, was Du gemeint hast.

Gruß
Lutz Ifer

[Azrael]

@Lutz Ifer: Danke, danach hab ich gesucht. Ich war mir halt nicht sicher, wofür die ersten 4 Bytes standen, da sie bei meinen Versuchen scheinbar keinen Sinn ergaben.
Beim Versuch, das Image auszulesen, ist dennoch einiges unklar:

[MisterD]

probier mal ushort

und farbwerte verdreht gibts öfters..
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra

[volta]

Hi,
Farbwerte sind nicht verdreht, sondern als 'Integer' abgespeichert.
Siehe:

[Azrael]

@Volta: Danke das war sehr hilfreich
Ich versteh zwar immer noch nicht ganz, warum die Breite nicht einfach ohne *8 + 4 ausgegeben wird, aber wenn ich Bescheid weiß ists auch gut.
Das mit Integer hab ich auch verstanden.

Bleibt noch eine Frage:

Wenn ich mit BLoad eine 24 bit BMP lade, aber die Grafik nur im 16bit Modus läuft, dann ändert sich automatisch das Image. Statt 4 Byte stehen nur noch 2 Byte zur Verfügung. Alpha fällt weg, aber ich weiß nicht, wie die Farben von 3 Bytes auf 2 Bytes heruntergeschraubt werden. Kennt vielleicht jemand eine Seite auf der das gut beschrieben wird, oder gibts da eine einfache Formel/Algorithmus?

[MisterD]

höhe*breite = anzahl der pixel des gesamten bilds

höhe*breite*8 = anzahl der bytes des gesamten bilds (2byte rot, 2 byte grün, 2 byte blau, 2 byte alpha = 8 byte pro pixel

höhe*breite*8+4 = anzahl der bytes des gesamten bilds inklusive header (2 byte höhe und 2 byte breite)..

also in Offsets gesprochen:

[Azrael]

@MisterD:

Sorry, aber du verwirrst mich?! Soweit ich weiß, steht jeder Farbe nur ein Byte zur Verfügung. So wie du rechnest, müsste ich ja eine Farbtiefe von 64 bit erreichen. Demnach 4 byte pro pixel.

Und in Offsets:

[MisterD]

oh öhm, stimmt... ein byte reicht ja eigentlich auch.
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra

[Dusky_Joe]

Sollte ich die erkenntnisse dieser Diskussion zur Referenz hinzufügen?
Mecki würde dann im Laufe der nächsten beiden Wochen die Updates online stellen.
(Ich möchte ihn nicht mit dem Auftrag belästigen, nur einen Eintrag zu ändern, deswegen müsstet ihr ein bisschen warten, bis ein paar andere Einträge mitgeändert werden )
_________________
fully biological degradable

Once, the big wave arrives, you've got two ways, you can go:
Either, you ride it, or you don't do.
But, if you don't ride, you'll never know wether you'd have gone wet.

[volta]

Hi,

[marzec]

die gfxlib muß beim blitten ( puten ) ja wissen wie groß euer bild ist. dazu reichen die dimensionen höhe und breite natürlich nicht aus, die lib muß auch über die bittiefe des bildes bescheidwissen ( aka. farbtiefe ). die wird in den ersten 3 bit des ersten 16-bit werds im image gespeichert. daraus folgt:

dim src as short ptr
src = imagecreate( w, h, 0 );

breite = src[0] shr 3
höhe = src[1]
bytepropixel = src[0] and 4 ( maskiere untere 3 bits 4dec = 111b )

d.h. über diese lustige formel könnt ihr alle nötigen daten zum bild auslesen.

zum thema verkehrt herum gespeicherte rgb werte: argb mapped genau so auf den gegebenen pixel wert ( 1byte, 2byte oder 4byte ) dass alpha immer in den obersten bits zum liegen kommt. gegeben dem little endian format das wir auf dem lustign x86 architekturen haben kommt diese byte hinten im speicher zu liegen. HEX$ gibt einen wert auch byteweise und zwar so wie die bytes im speicher liegen. d.h. b als erster g, r und a in der reihenfolge. vom zahlenwert her ists aber argb...

16-bit farbtiefe ist innerhalb der gfxlib immer so bitweise organisiert

[Azrael]

BIG T]-[X euch beiden. Werde mir bei Gelegenheit alles genaustens angucken