Datein einlesen...

Darian

Hallo Leute,

das mit dem Padding funktioniert jetzt schon, mir ist zwar noch immer nicht so klar wie das gemeint ist, oder wie das alles im Hintergrund genau arbeitet, aber es geht zumindest.

http://nopaste.info/59bec70c84.html

Jetzt sollte ich mir noch eine Art long Ersatz machen, dass man es leicht ändern kann falls ein long mal nicht die 4 Byte hat..oder?

Oder wie würdet ihr da vor gehen um diese eine Fehlerquelle jetzt noch auszuschalten?

lg Darian

Edit: Wie sind jetzt die Farbtabellen auszulesen:...

unsigned char pixel1;
heightmap.seekg(54, ios::beg);
heightmap.read(reinterpret_cast<char*>(&pixel1), sizeof(unsigned char));
cout << pixel1 <<endl;

Gibt nur folgendes aus: "Pixel1: " also gar nichts...

CStoll

Darian schrieb:

Jetzt sollte ich mir noch eine Art long Ersatz machen, dass man es leicht ändern kann falls ein long mal nicht die 4 Byte hat..oder?

Bei Windows ist WORD==2 Byte, DWORD==4 Byte, also nimm doch letzteres.

(PS: Und weiter oben hatte ich einen Link zur FAQ gepostet, wo die Typ-Bestimmung für feste Größen über Templates gelöst ist)

Darian

@CStoll, ich bin im Linux unterwegs und habe daher kein dword oder so glaub ich zumindest.

Das mit den Templates ist mir leider noch zu hoch, daher würde ich es gerne ohne machen. Aber ich werde mir das noch genauer ansehen um endlich einmal über die, ahhh bitte keine Templates, Phase weg zu kommen.
(werde mal ein paar Dokus darüber lesen müßen)

lg Darian

CStoll

Darian schrieb:

@CStoll, ich bin im Linux unterwegs und habe daher kein dword oder so glaub ich zumindest.

Und trotzdem verwendest du es in deinem struct

PS: Wenn du nicht mit Templates arbeiten willst, kannst du auch den Präprozessor bemühen - ist allerdings etwas aufwendiger, für jeden in Frage kommenden Compiler einen 2-Byte- (word) und einen 4-Byte- (dword) Datentyp zu suchen.

PS: Auf den meisten Systemen sollte word==short und dword==int ausreichend sein. Und wenn tatsächlich jemand einen zu großen short definiert, müsstest du dir doch selber etwas basteln:

//achtung - ungetestet
class word
{
  char data[2];
public:
  word(short val)
  {
    data[0]=(val>>8)&0xFF;
    data[1]=val&0xFF;
  }
  operator short()
  {
    return data[0]<<8 | data[1]&0xFF;
  }
};

LordJaxom

Unter Linux stehen Dir aber Typen wie int8_t, int16_t, uint8_t usw. zur Verfügung. Diese Typen sind auch im aktuellen Standard erwähnt, jedoch optional, müssen also nicht zwingend vorhanden sein.

Darian

@CStoll, ist mir auf den ersten Blick auch nicht ganz klar das Code, denke aber dass ich mich da durch tüffteln könnte mit googel Templates kann ich sowieso nicht immer ausweichen, steht schon auf meiner ToDo Liste.

Ja super fein, diese ints muß ich ja gleich einmal ausprobieren. Aber wo kann ich mir den Standard ansehen? Oder wo siehst du da nach, weil ich habe auf die schnelle eher unübersichtliche Docs gefunden, muß aber noch genauer sehen.

lg Darian

CStoll

Darian schrieb:

@CStoll, ist mir auf den ersten Blick auch nicht ganz klar das Code, denke aber dass ich mich da durch tüffteln könnte mit googel Templates kann ich sowieso nicht immer ausweichen, steht schon auf meiner ToDo Liste.

Das Ding dort oben simuliert einen 2 Byte großen Ganzzahltyp - für Systeme, auf denen selbst short zu groß sein sollte. Auf gängigen Systemen dürfte aber ein tyedef short word; völlig ausreichen.

Darian

Das freut mich dass es ausreichend ist.

Habe ein Testbild gemacht mit 10 Pixel, und fixen Farbwerten, aber es ging nicht, und die Farbwerte passen nicht so ganz.

Erste Pixel rot:

Pixel1: 255
Pixel2: 0
Pixel3: 0
...usw (bis erst einmal 10 Werte die es mir ausgibt)

Ist aber ganz was anderes...

Kann mir da jemand sagen woran das liegt, weil das selbe habe ich ja mit dem Bitmap auch gehabt, und ist jetzt bei dem tga Loader das selbe.

Wenn ich das gelöst habe, könnte ich weiter kommen.

Wäre super wenn mir hier jemand Infos geben kann!

lg Darian

CStoll

Schau dir doch auch mal an, mit welcher Bitgröße dein Bild gespeichert ist - das kann zwischen 1 und 32 Bit pro Pixel liegen und macht durchaus Unterschiede bei der Repräsentation der Farbwerte.

(1- bis 8-Bit-Bilder verwenden eine Farbtabelle, in der für jede Bitkombination eine RGB-Kombination steht, größere Bilder speichern die Farben direkt (bei 32 Bit je ein Byte R,G,B und ungenutzt))

Darian

Hallo,

jedes Pixel ist mit 24 Bit gespeichert also ganz normal RGB oder in einer anderen Reihenfolge, weiß ich jetzt nicht genau.

Ich dachte nachdem es keine Farbpalette gibt, und Bild-ID optional ist, und auch nicht da ist (glaube ich zumindest) beginnen gleich nach dem Header die Bildaten.

Aber ich komme auf keine brauchbaren Werte.

Der Code hat sich bis jetzt zu dem obigen noch nicht verändert.

lg

CStoll

Darian schrieb:

jedes Pixel ist mit 24 Bit gespeichert also ganz normal RGB oder in einer anderen Reihenfolge, weiß ich jetzt nicht genau.

Ist das eine Vermutung von dir oder hast du das im Header (Feld biBitCount) kontrolliert? (achja, die Reihenfolge ist BGR)

Ich dachte nachdem es keine Farbpalette gibt, und Bild-ID optional ist, und auch nicht da ist (glaube ich zumindest) beginnen gleich nach dem Header die Bildaten.

Was zwischen Header und Bilddaten liegt, hängt vom Programm ab, das die Datei geschrieben hat - jedenfalls solltest du dich nicht darauf verlassen, daß die lückenlos aufeinander folgen. Darum gibt es auch den Eintrag bfOffBits - der sagt dir, wo die Bilddaten beginnen.

Darian

Hallo CStoll,

jap, du hast recht, mein Letzter Beitrag hat wirklich nicht gestimmt, weil ich da vom TGA gesprochen habe.

Jetzt wieder zum Bitmap.

Ich habe dazu geschrieben welche Werte die Pixel haben sollten, und welche Ausgabe ich bekomme. Die Werte der Ausgabe, und der Gemessenen (mit Gimp) passen nicht zusammen.

http://nopaste.info/e0cfe447f4.html

Habe wegen der Übersicht hier alles in ein nopaste System gegeben.

OffBits wurden berücksichtit. Farbtabelle gibt es keine. also müßten die Werte passen.

lg Darian

P.S.: Habe eher das ähnliche oder selbe Problem mit den tga Werten.

CStoll

OK, ich hab' mir den Code mal angesehen - und wenn ich raten müsste, würde ich Zeile 74 als Problemursache einstufen.

Darian

Und so wie ich das sehe glaube ich du hast recht

Tja dummer Fehler von mir stimmt, und ich denke beim tga war es das selbe.

Viel viel dank, ich hoffe sowas passiert mir nicht mehr wieder.

Für die anderen, ich habe die datei geschlossen und habe sie nachher noch einmal benutzt, darum stimmte es nicht zusammen, und ich habe irgendwelchen Müll ausgelesen.

lg und danke dir/euch
Darian