Problem bei Dateieinlesen (VC++)

N

niedriger noob

0
Hallo,
Ich schreibe gerade an einem kleinen Bildbetrachtungsprogramm. Als Bildformat nutze ich das RAW-Format. Da stehen alle RGB Werte in Hex-Form drinnen. Das Format ist zwar nicht gerade platzsparend, aber sehr einfach, und damit für den Anfang geeignet.
Mein Sourcecode zum Zeichnen des Bildes sieht im Moment so aus:

class Pixel
{
public:
int R;
int G;
int B;
};

Pixel Pixel;

int i=100;
int x = 20;
int y = 20;
FILE *pfile;
pfile = fopen("Test.raw","r");
CClientDC dc(this);

while(i>0)
{

Pixel.R = fgetc(pfile);
if(Pixel.R == EOF)
{
break;
}
Pixel.G = fgetc(pfile);
Pixel.B = fgetc(pfile);

if(x==220)
{
y++;
x=20;
}
dc.SetPixel(x,y,RGB(Pixel.R, Pixel.G, Pixel.B));

x++;
}

fclose(pfile);
Leider hört mein Programm bei bestimmten Stellen einfach zu zeichnen auf ;( ;( ;( . Ich habe schon herrausgefunden, dass es nur aufhört, wenn das Zeichen 1A (dez. 26) eingelesen wird X( .
Hat dieses Zeichen irgendeine besondere Bedeutung und kann ich irgendwie umgehen, dass er dann zu Zeichen aufhört??

mfg und thx im Vorraus
Noob

P.S. Das EOF Zeichen ist es nicht, denn wenn ich das if(...==EOF) weglassen, zeichnet er zwar weiter, aber nur noch unendlich oft weisse Pixel, obwohl die ganz andere Farben hätten.
 
Bin mir nicht sicher, aber es wäre möglich, dass das be-
sagte Zeichen eine Art Zeilenumbruch ist und daher nicht
gezeichnet wird, sondern dass an dieser Stelle die Pixel
eine Zeile weiter unten begonnen werden müssen.

KA, ob das stimmt, wäre aber meine Vermutung.


so long, gruß mcrack

P.S.: Wenn du verhindern willst, dass er aufhört, bau doch
einen Check ein. Wenn der Inhalt der eingelesenen Va-
riable 1A ist, dann soll er das Zeichnen überspringen.
 
Der Zeilenumbruch hat mit dem Pixel Zeichnen glaube ich nichts zu tun, da das eine eigene Funktion ist.
Die Idee mit dem Check ist nicht schlecht, aber hat nur einen Haken: Das Zeichen 1A selbst kann nicht mehr eingelesen werden, deshalb kann ich auch leider keinen Check machen.
Ich hab mal in der ASCII Tabelle nachgeschaut, da ist Zeichen 1A (dez 26) ein Pfeil nach rechts. Schaut -> so aus, nur halt in einem Zeichen.
 
Also ich hab die Erfahrung gemacht, dass z.B. bei bmp's,
wenn sie kleiner sind, als der gesamte Bildschirm, 3
bytes als zeilenumbruch fungieren.
Hab gedacht, dass das möglicherweise etwas ähnliches
ist...

Wo ist das Problem, mit dem Einlesen. Bricht er schon ab,
sobald es eingelesen ist, oder wie? Ansonsten musst du
doch nur die Variable mit dem Zeichen vergleichen...


so long, gruß mcrack
 
Wenn er die Stelle einliest, an der es steht einliest bricht er ab, und kann es nichtmehr in eine Variable speichern, ergal ob ich was zeichne oder nicht, auch wenn ich es in einer DOS-Anwendung einlese

mfg
Noob
 
Das mit "rb" funktioniert leider auch nicht, aber dafür auf eine andere Variante nicht. Wenn er jetzt zu besagtem Zeichen 1A kommt, wird es zwar richtig eingelesen und richtig angezeigz, nur werden dann unendlich oft die 3 vorhergehenden Zeichen eingelesen.
Was hat dieses 1A an sich, dass es nicht richtig gelesen werden kann? Ist das irgendein Systemzeichen oder sonst was gemeines??? X(

mfg
Noob

--Nachtrag--
Wenn ich im nicht-Binary Mode gelesen habe, kam es oft im Bild zu "Farbverschiebungen", wie als würde ein Farbkanal fehlen. Da mein Prog das nicht herausfinden konnte, waren alle Farben dann um einen Kanal (R,G,B) verrutscht. Aus R wurde G, aus G wurde B, usw. Wenn ich im Binary Mode lese, passiert das nicht. Ich bin sicher, das hängt auch mir irgend so einem gemeinem Zeichen zusammen, habe allerdings noch nicht herrausgefunden, welches. Es scheint aber nicht soooo gemein wie 1A zu sein, da ich es durch "rb" umgehen kann
--Nachtrag aus--
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben