Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

Aufbau eines Images?!

 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC.
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
Azrael



Anmeldungsdatum: 21.11.2005
Beiträge: 12

BeitragVerfasst am: 21.11.2005, 19:18    Titel: Aufbau eines Images?! Antworten mit Zitat

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. lächeln
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
jb



Anmeldungsdatum: 14.01.2005
Beiträge: 2010

BeitragVerfasst am: 21.11.2005, 19:29    Titel: Antworten mit Zitat

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

jb
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Azrael



Anmeldungsdatum: 21.11.2005
Beiträge: 12

BeitragVerfasst am: 21.11.2005, 19:43    Titel: Antworten mit Zitat

>"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 lächeln) 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.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Lutz Ifer
Grillmeister


Anmeldungsdatum: 23.09.2005
Beiträge: 555

BeitragVerfasst am: 21.11.2005, 20:22    Titel: Antworten mit Zitat

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 böse Ifer
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Azrael



Anmeldungsdatum: 21.11.2005
Beiträge: 12

BeitragVerfasst am: 22.11.2005, 15:43    Titel: Antworten mit Zitat

@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:

Code:


Screen 16, 32

Dim h As Any Ptr

h = ImageCreate(1, 1, Rgba(250, 200, 150, 100))

Print Peek(Short, h)
Print Peek(Short, h + 2)

For i = 4 To 7
  Print Peek(uByte, h + i)
Next

Put (100, 100), h', Alpha

Sleep





Wenn du sagst, das Höhe und Breite auf 4 Bytes verteilt sind, ist es dann richtig anzunehmen, dass sie jewails durch ein "Short" representiert werden? Demnach sollten die ersten beiden Prints 1 und 1 sein, bei mir jedoch 1 und 12 ?!

Und wie es aussieht, wird ein Pixel BBGGRRAA gespeichert - etwas verwirrend?!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
MisterD



Anmeldungsdatum: 10.09.2004
Beiträge: 3071
Wohnort: bei Darmstadt

BeitragVerfasst am: 22.11.2005, 18:35    Titel: Antworten mit Zitat

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
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
volta



Anmeldungsdatum: 04.05.2005
Beiträge: 1876
Wohnort: D59192

BeitragVerfasst am: 22.11.2005, 19:23    Titel: Antworten mit Zitat

Hi,
Farbwerte sind nicht verdreht, sondern als 'Integer' abgespeichert.
Siehe:
Code:
Screen 16, 32

Dim h As Any Ptr

h = ImageCreate(10, 8, Rgba(250, 200, 150, 100))

Print Peek(Short, h) 'Breite*8 + 4
Print Peek(Short, h + 2) 'Höhe

'For i = 4 To 7
  Print Hex$(Peek(integer, h+4))
'ist:    aarrggbb
'Next

Put (100, 100), h', Alpha

Sleep


Gruß
Volta
EDIT/ etwas anschaulicher?
Code:
Screen 16, 32

Dim h As Integer Ptr
Dim As Integer Breite, Hoehe
Breite =10
Hoehe =9
h = ImageCreate(Breite, Hoehe, Rgba(250, 200, 150, 100))
Print "Breite*8 + 4 = "; (LoWord(*h))
Print "Hoehe        = "; (HiWord(*h))

Print Hex$(*(h+1))
Print "aarrggbb"
 
Put (100, 100), h', Alpha
Sleep

_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Azrael



Anmeldungsdatum: 21.11.2005
Beiträge: 12

BeitragVerfasst am: 23.11.2005, 17:19    Titel: Antworten mit Zitat

@Volta: Danke das war sehr hilfreich lächeln
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. verwundert Kennt vielleicht jemand eine Seite auf der das gut beschrieben wird, oder gibts da eine einfache Formel/Algorithmus?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
MisterD



Anmeldungsdatum: 10.09.2004
Beiträge: 3071
Wohnort: bei Darmstadt

BeitragVerfasst am: 23.11.2005, 18:11    Titel: Antworten mit Zitat

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:
Code:
bild[0] = offset des headers, vier byte länge
bild[4] = offset des ersten pixels, 8 byte länge
bild[4 + x*8] = offset des pixels y in der ersten zeile (8 byte pro pixel)
bild[4 + y*breite*8] = offset der zeile y
bild[4 + y*breite*8 + x*8] =  offset des pixels (x,y)

Der header hat 4 bytes länge, daher die 4 und ein pixel hat 8 byte für die farbwerte, daher die 8.
Immer, wenn du an den Pixeln arbeitest, muss du zu dem ursprünglichen offset 4 dazuzählen um den header zu überspringen und du musst mit 8 byte pro pixel rechnen.
_________________
"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
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Azrael



Anmeldungsdatum: 21.11.2005
Beiträge: 12

BeitragVerfasst am: 23.11.2005, 18:34    Titel: Antworten mit Zitat

@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:

Code:

bild[0] = offset des headers, vier byte länge
bild[4] = offset des ersten pixels, 4 byte länge
bild[4 + x*4] = offset des pixels y in der ersten zeile (4 byte pro pixel)
bild[4 + y*breite*4] = offset der zeile y
bild[4 + y*breite*4 + x*4] =  offset des pixels (x,y)


Oder seh ich da irgend etwas falsch?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
MisterD



Anmeldungsdatum: 10.09.2004
Beiträge: 3071
Wohnort: bei Darmstadt

BeitragVerfasst am: 23.11.2005, 20:23    Titel: Antworten mit Zitat

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
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Dusky_Joe



Anmeldungsdatum: 07.01.2005
Beiträge: 1007
Wohnort: Regensburg/Oberpfalz

BeitragVerfasst am: 25.11.2005, 16:31    Titel: Antworten mit Zitat

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 zwinkern )
_________________
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.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
volta



Anmeldungsdatum: 04.05.2005
Beiträge: 1876
Wohnort: D59192

BeitragVerfasst am: 26.11.2005, 15:40    Titel: Antworten mit Zitat

Hi,
Azrael hat Folgendes geschrieben:
Ich versteh zwar immer noch nicht ganz, warum die Breite nicht einfach ohne *8 + 4 ausgegeben wird.
ich habe auch keine Erklärung dafür gefunden!
Azrael hat Folgendes geschrieben:
..aber ich weiß nicht, wie die Farben von 3 Bytes auf 2 Bytes heruntergeschraubt werden..?


Code:
Option Explicit
Dim As UInteger iRGBA
Dim As UByte bRot, bGelb, bBlau
Dim As UShort sRGB

iRGBA = &H60557788 '=RGBA(&H55,&H77,&H88,&HA60)
'   AA RR GG BB
'&H 60 55 77 88
'   Hi Lo Hi Lo  Byte
'    Hi    Lo    Word
bRot  = LoByte (HiWord (iRGBA))'RR
bGelb = HiByte (LoWord (iRGBA))'GG
bBlau = LoByte (LoWord (iRGBA))'BB
'RGB( bRot, bGelb, bBlau)

' jede Farbe auf 64 Werte (5 Bit) reduzieren
bRot  = bRot  \8
bGelb = bGelb \8
bBlau = bBlau \8

'zu einem 16 Bit (15 Bit) UShort Wert zusammensetzen
'sRGB = &B00000000000rrrrr ; sRGB = bRot
'sRGB = &B000000rrrrr00000 ; 5 Bit nach links schieben
'sRGB = &B000000rrrrrggggg ; + bGelb
'sRGB = &B0rrrrrggggg00000 ; 5 Bit nach links schieben
'sRGB = &B0rrrrrgggggbbbbb ; + bBlau
sRGB = (((bRot Shl 5) + bGelb) Shl 5) + bBlau

' Anzeige Binär
Print Right("00000" + Bin(bRot),6)
Print Space(6) + Right("00000" + Bin(bGelb),5)
Print Space(11) + Right("00000" + Bin(bBlau),5)
Print Right(String(16, "0") + Bin(sRGB),16)
Sleep
End
Ich hoffe du kommst mit den Erklärungen im Listing klar.
Gruß
Volta
PS:
Code:
sRGB=0
'einfacher in InlineAssembler
'32/24bpp zu 16bpp (15 Bit)
ASM
 Mov eax, iRGBA 'AARRGGBB nach eax
 Mov bx, ax     'GGBB nach bx kopieren
 And eax, &H00F80000 'rot maskieren
 Shr eax, 9     'Bit nach rechts
 Mov cx, ax     'rot ist ok
 Mov ax, bx     'Kopie holen
 And ax, &HF800 'gelb maskieren
 Shr ax, 6      'Bit nach rechts
 Or cx, ax      'gelb und rot ist ok
 Mov ax, bx     'Kopie holen
 And ax, &H00F8 'blau maskieren
 Shr ax, 3      'Bit schieben
 Or ax, cx      'blau, gelb und rot ist ok
 Mov sRGB ,ax
End ASM

Print Right(String(16, "0") + Bin(sRGB),16)
grinsen
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
marzec



Anmeldungsdatum: 13.10.2004
Beiträge: 267

BeitragVerfasst am: 27.11.2005, 08:33    Titel: Antworten mit Zitat

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

Code:

15 14 13 12 11 10 9  8  7  6  5  4  3  2  1  0
r  r  r  r  r  g  g  g  g  g  g  b  b  b  b  b


24-bit wird so codiert ( jetzt byteweise ) wobei u für unused also ungenutzt steht.
Code:

3 2 1 0
u r g b


32-bit so codiert ( ebenfalls byteweise )
Code:

3 2 1 0
a r g b


diese codierungen ( speziell die 16-bit codierung ) gilt so nur innerhalb der gfxlib. bei sdl, opengl etc. können diese codierungen je nach hardware etc. variieren
_________________
Yagl - yet another gameprogramming library
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden MSN Messenger
Azrael



Anmeldungsdatum: 21.11.2005
Beiträge: 12

BeitragVerfasst am: 27.11.2005, 15:27    Titel: Antworten mit Zitat

BIG T]-[X euch beiden. Werde mir bei Gelegenheit alles genaustens angucken lächeln
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC. Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.

 Impressum :: Datenschutz