Problem unsigned char auf LPCSTR?

ok dann mach ich mal den crosscheck

Decimad schrieb:

OpenIL da zurückliefert ist ein Array von Byte-Werten die die entsprechende Farbkompenente spezifizieren für Pixel.

check. versteh ich. ich hab im Array quasi 0,0,0,255 also RGBA. Gleich mal vorweg das ist in ANSI da UNICODE ja deaktiviert ist.

Decimad schrieb:

Was MultibyteToWideChar macht ist Multibyte (oder Ansi/Ascii/Utf8)-Kodierte Strings in UTF16-Strings zu rekodieren.

check. versteh ich. die benutze ich ja genau aus dem Grund. damit will ich aus den ANSI Daten Unicode machen, da krieg ich ja sonst symbolvielfalt wenn ich das ohne konvertierung exportier...

Decimad schrieb:

"0x000000FF" hat halt als String 10 Byte, während das was OpenIL da liefert wirklich binär ist, also pro Pixel 4 Byte. Eine Ascii-0 ist eben auch keine Binär-0, sondern im Speicher eine 48. Du musst daher, wie ich vorschlage, die Zahlen entsprechen in ihre Stringform bringen, was die entsprechenden Ausgabeoperatoren vom Stream erledegen.

Jetz wirds interessant daran hab ich so genau noch gar nich gedacht. 4 BytepP sind richtig, aber wenn ich 0,0,0,255 in hex wandle hab ich doch 000000FF? Ich dachte mein Problem is das meine 0-255 rgba werte durch den pflicht-signed-cast für die Funktion MyByte zu -127...+128 wird und dann die negativWerte falsch bei der ANSI konvertierung interpretiert werden...

Decimad schrieb:

Ich würde das Array zu einem unsigned int array casten .

der ist schon unsigned char von der IL.h aus.
den Streamc aste ich schon hex ins file, dass mache ich so während der filestream offen ist.:

for(j = 0; j < size; j++){

	  if(j%4==0){
		fp_out << "0x";
		//printf("0x");
		}

	  fp_out << setw(2) << setfill('0') << hex << unicodestr[j];
	  //fp_out << setprecision(2) << hex << unicodestr[j];

	  //New Line
	  if((j+1)%4==0){
	  fp_out << ";\n";
	  //printf(";\n");
	  }
  }

das macht auch was es soll...

Danke für die schnelle Antwort!
Gruß Max

OpenIL gibt kein Ascii oder Ansi oder überhaupt eine Text-Kodierung zurück. OpenIL gibt binärepresentation der Farbwerte zurück, wie zahlen halt im PC intern dargestellt werden (Denke daran dass bspw. 254 in ein Byte passt, aber 3 Schriftzeichen in Textkodierung braucht, also in Ascii 3 Byte oder UTF-16 halt 6 Byte). Deshalb müssen die Zahlen erst zu Ascii, Ansii oder UTF konvertiert werden.

Was ich mit den unsigned int-Array meinte war:

const unsigned int* intPtr = reinterpret_cast<const unsigned int*>( byteArray );

for( unsigned int i=0; i<numPixels; ++i )
{
    stream << intPtr[i];  // Hier wird unsigned int zu einem String konvertiert
}

so da bin ich wieder. Also erstmal, es ist definitiv eine funktionierende Lösung, ganz hingekriegt hab ichs aber doch ned hab aber erstmal versucht es selbst zu lösen ohne Erfolg...

//Create Stream for Output and Open File
  ofstream fp_out;
  fp_out.open("pngdata.txt", ios::out);

  //typecast byte array
    const int* intPtr = reinterpret_cast<const int*>( bytes ); 
	for( int i=0; i<size; ++i ) 
	{ 
		fp_out << hex << ";" <<intPtr[i];  // Hier wird unsigned int zu einem String konvertiert 
		cout << hex << "\n" << intPtr[i];
	}

gibt mir korrekt im File aus : FF000000;FF000000; etc und dachte das da halt ein Dreher drin ist weil ja eigentlich RGBA und das schaut nach ABGR aus aber dazu später ... Ich bekommen aber gegen Ende dann immer nen Zugriffsfehler beim Lesen. Das passiert ca bei einem i=300000, also liegst nich am i hät ich gesagt.
Den Fehler krieg ich ja normal wenn ich was mit den arrayelementen falsch gemacht hab.Also hab ich mir das Array genauer angeschaut:
Wenn ich intPtr decimal ausgeben lass krieg ich zB -16700000 oder ähnlich hohe Zahlen im negativen Bereich. Meineserachtens doch falsch oder? Dann hab ich bisl rumgespielt mit nem unsigned typecast etc aber ohne Erfolg.

Dann ist mir augefallen das bytes[] vom Typ char ist

ILubyte * bytes = ilGetData();

mit typedef unsigned char ILubyte
dh meine Werte von OpenIL sind gar keine "zahlenwerte" sonder chars? Wenn ich dann nen cast mache auf ein integer array kann das doch nich gutgehn oder?

Debenbei bemerkt:
Jetz hab ich auch glaub ich besser verstanden was du meintest. Wenn mir OpenIL die Daten in Zahlenwerten liefert, dann wär mir ANSI ansich wurscht wenn ichs einfach als hex in den Stream schiebe. Sobald ich irgendwas mit chars mache kommt ANSI ins spiel, right?

Gruß Max

MFK

Sanschoo schrieb:

gibt mir korrekt im File aus : FF000000;FF000000; etc und dachte das da halt ein Dreher drin ist weil ja eigentlich RGBA und das schaut nach ABGR aus

http://de.wikipedia.org/wiki/Byte-Reihenfolge

Sanschoo schrieb:

Ich bekommen aber gegen Ende dann immer nen Zugriffsfehler beim Lesen. Das passiert ca bei einem i=300000, also liegst nich am i hät ich gesagt.

Ist size die Länge des unsigned char-Arrays? Die musst du natürlich durch vier teilen, wenn du das als Array von 32-Bit-Werten interpretierst.

Sanschoo schrieb:

Dann ist mir augefallen das bytes[] vom Typ char ist
ILubyte * bytes = ilGetData();
mit typedef unsigned char ILubyte
dh meine Werte von OpenIL sind gar keine "zahlenwerte" sonder chars?

char ist ein Zahl-Datentyp.

Sanschoo schrieb:

Wenn ich dann nen cast mache auf ein integer array kann das doch nich gutgehn oder?

Doch, das ist ja der Sinn der ganzen Aktion. Du willst ja gerade den Inhalt des Speichers uminterpretieren.

Klasse! Das war der Clou! Warum durch vier teilen is mir nun auch klar somit kriege ich mit folgendem Code meinen formal gewollten Output:

//typecast byte array

	const int *intPtr = reinterpret_cast<const int*>( bytes ); 
	for( int i=0; i<(size/4); i++ ) 
	{ 
		fp_out << hex << showbase << ", " << intPtr[i];  // Hier wird unsigned int zu einem String konvertiert 
		//cout << hex << "\n" << intPtr[i];
	}

Ein Problem hab ich jetz noch (und wieder hab ichs versucht -> openGL noob )... Format jetz 0xFF000000. Ich bin mir ziemlich sicher das das ABGR ist, da ich ein Schwarz weiss bild geladen habe und der AlphaWert auf 255 sein müsste. Jetzt dachte ich mir ich lads mal in mein OpenGL Programm

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 1024, 512, 0, GL_RGBA, GL_UNSIGNED_BYTE, pointer_zum_32bit_array);

Mein PNG ist mit paint auf 1024*512 geändert mit einer 32bit-Farbtiefe.

Dann krieg ich nen Fehler mit Zugriffsverletzung versteh ich nich. Selbst wenns RGBA is, müsste ers doch trotzdem nehmen und halt dann falsche Farben anzeigen?!
Wenn ich GL_RGB ohne alphawert nehme macht ers, zeigt aber auch falsche Farben an (weil vermutlich BGR)... sorry wenn ich da so aufm Schlauch stehe

Und wieso drehts mir denn überhaupt meinen arrayinhalt?! Wenn ich mein bytes[] mit printf ausgebe hab ich 0,0,0,255 (also richtig). Und mit der for-Schleife schreibe ich sie nach dem reinterpret-cast der Reihe nach ins file...

Gruß Max

MFK

Sanschoo schrieb:

Mein PNG ist mit paint auf 1024*512 geändert mit einer 32bit-Farbtiefe.

Wie groß ist denn size?

Sanschoo schrieb:

Und wieso drehts mir denn überhaupt meinen arrayinhalt?!

Hast du den Wikipedia-Artikel gelesen?

size = 2 097 152

ja jetzt gleich nochmal gelesen. Mit Windows etc befinde ich mich ja auf little endian und hab nun offensichtlich big endian vorliegen. Aber warum das beim auslesen eines PNGs passiert konnte ich dem Text nicht entnehmen. Oder ist es sorum, dass RGBA eigentlich big endian ist, und der ichs dann umgekehrt interpretiert bekommen weil Windows little endian?!

edit: alles klar stimmt, PNG ist big endian

http://www.w3.org/TR/2003/REC-PNG-20031110/#7Integers-and-byte-order

damit ists erklärt woher der Dreher kommt...

Bleibt also noch warum mir OpenGL bei 32bit format per GL_RGBA nichts einlesen möchte...

MFK

Vielleicht fragst du da besser im Grafik-Forum.

Passt, ich habs hinbekommen indem ichs mit einer ByteSwap Function noch gedreht hab...

Wollte noch ein dickes Danke an euch, Decimad und MFK, sagen. Ihr wart damit wirklich eine große Hilfe bei meiner Diplomarbeit. Habe damit das Problem nicht nur lösen sondern auch wirklich verstehen können...
Werd das Forum öfters besuchen um auchmal was beitragen zu können!

Grüße Max