4. fread vertauscht daten

fread vertauscht daten

  • G

    Hallo,

    ich habe eine Datei, die folgendermaßen aussieht:
    0xFF 0x00 0x00
    0xFF 0x00 0x00
    0xFF 0x00 0x00
    0xFF 0x00 0x00
    ...

    diese Datei lese ich mit folgendem Code aus

    FILE * file = fopen(/*Dateiname*/);
void * pData = malloc(/*Dateigröße*/);
fread(pData, 1, /*Dateigröße*/, file);

    allerdings steht anschließend im RAM folgendes:
    0x00 0x00 0xFF
    0x00 0x00 0xFF
    0x00 0x00 0xFF
    0x00 0x00 0xFF
    ...

    Ich habe das gefühl, dass die Datei von hinten eingelesen wird. Vielleicht kann mir ja jemand weiterhelfen.

    Vielen Dank schonmal im vorraus

    EDIT: wieso schreibt der "v_o_r_r_a_u_s" so komisch??? 😕

    0
  • M

    Gast#649237 schrieb:

    Ich habe das gefühl, dass die Datei von hinten eingelesen wird.

    Das ist extrem unwahrscheinlich. Vermutlich interpretierst du den Speicherinhalt falsch. Zeig doch mal, wie du auf diesen angeblichen Speicherinhalt kommst. Hast du eine Ausgabe, oder schaust du das im Debugger an?

    wieso schreibt der "v_o_r_r_a_u_s" so komisch??? 😕

    Weil's falsch ist. RTFDuden 😉

    0
  • G

    debugger

    0
  • M

    Ist das der gesamte Code, oder machst du hinterher noch etwas mit pData? Inkrementieren, oder so?

    0
  • G

    Hallo, hier ist mal mein ganzer Code

    bool GTextureManager::LoadBMP(char * pFile, unsigned short &sizeX, unsigned short &sizeY, void * &pData)
{
	//Open the file
	FILE * file = fopen(pFile, "r+b");

	//Check for errors
	if (!file) return false;

	//File is open

	//for file format watch: http://de.wikipedia.org/wiki/Windows_bitmap

	//read the header
	//ignore the first 2 bytes
	fpos_t position = 2;
	fsetpos(file,  &position);

    struct tBMPHeader
	{
		DWORD 	bfSize; 	//Größe der BMP-Datei in Byte.
		DWORD 	bfReserved; //	0
		DWORD 	bfOffBits; 	//Offset in Byte der Bilddaten vom Beginn der Datei an.
	} BMPHeader;
	fread(&BMPHeader, sizeof(BMPHeader), 1, file);

	//read the infoheader
	struct tBMPInfoHeader
	{
		DWORD biSize;
		LONG biWidth;
		LONG biHeight;
		WORD biPlanes;
		WORD biBitCount;
		DWORD biCompression;
		DWORD 	biSizeImage;
		LONG 	biXPelsPerMeter;
		LONG 	biYPelsPerMeter;	
		DWORD 	biClrUsed;
		DWORD 	biClrImportant;
	} BMPInfoHeader;
	fread(&BMPInfoHeader, sizeof(BMPInfoHeader), 1, file);

	//Set the Size
	sizeX = BMPInfoHeader.biWidth;
	sizeY = abs(BMPInfoHeader.biHeight);

	//allocate space
	pData = malloc(sizeX*sizeY*3);

	//set the file pointer to the data
	position = BMPHeader.bfOffBits;
	fsetpos(file,  &position);
	//and read the Data
    fread(pData, 1, sizeX*sizeY*3, file);

	return true;
}
    0
  • G

    Diese Ladefunktion ist für OpenGL. Ich glaube ernsthaft, dass der die Datei falschrum einliest, weil:
    1. das Bild ist gespiegelt
    2. die Grün-Werte stimmen und die Rot- und Blau-Werte sind vertauscht

    http://mitglied.lycos.de/youngsolutions/temp.JPG

    Jetzt sieht's so aus, wie das erste Bild und so wie das zweite sollte es aussehen.

    0
  • M

    Ist BMPInfoHeader.biHeight positiv oder negativ?

    0
  • ?

    Ich denke das fread korrekt arbeitet, denn sonst wäre dein Bitmapheader ja auch
    falsch. Soweit ich weis, werden BMP's von unten nach oben eingelesen.
    Du must also die Datei von hinten nach vorne in den Speicher einlesen oder
    mit einer Funktion die Scanlines tauschen. Eine Beschreibung dazu ist in der
    MSDN:

    The following illustration presents the developer's perspective of the bitmap found in the file Redbrick.bmp. It shows a palette array, a 32-by-32 pixel rectangle, and the index array that maps colors from the palette to pixels in the rectangle.

    row 0, scanline 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    row 1, scanline 30 00 00 00 00 00 00 00 00 09 00 00 00 00 00 00 00
    row 2, scanline 29 11 11 01 19 11 01 10 10 09 09 01 09 11 11 01 09
    .
    .
    .
    row 31, scanline 0 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99

    In the preceding example, the rectangle of pixels was created on a VGA display device using a palette of 16 colors. A 16-color palette requires 4-bit indexes; therefore, the array that maps palette colors to pixel colors is composed of 4-bit indexes as well. (For more information about logical color-palettes, see Colors.)

    Note In the above bitmap, the system maps indexes to pixels beginning with the bottom scan line of the rectangular region and ending with the top scan line. A scan line is a single row of adjacent pixels on a video display. For example, the first row of the array (row 0) corresponds to the bottom row of pixels, scan line 31. This is because the above bitmap is a bottom-up device-independent bitmap (DIB), a common type of bitmap. In top-down DIBs and in device-dependent bitmaps (DDB), the system maps indexes to pixels beginning with the top scan line.

    Eine detailierte Beschreibung ist in der MSDN unter: About Bitmaps zu finden

    Gruss
    EB

    0
Anmelden zum Antworten