Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (GNU/Linux, *NIX, *BSD und Co) » Gleitkomma-Ausnahme bei Graustufen-TGAs

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
15.07.2017, 18:36 Uhr
Yadgar



Hi(gh)!

Bin mal wieder mit meinem konsolenbasierten Bildverarbeitungsprogramm "YIP" zugange... und versuche jetzt erstmals, unkomprimierte Graustufen-TGAs zu verarbeiten. Das Einlesen klappt problemlos, sobald ich aber dann speichern will, bekomme ich (im Gegensatz zu unkomprimierten Truecolor-TGAs, wo der Fehler nicht auftritt) die Fehlermeldung "Gleitkomma-Ausgabe".

Mit manuellem Debugging glaube ich die Fehlerquelle auf diese Funktion eingegrenzt zu haben:


C++:
bool saveTGA(vector<vector<pixel> > &img, string filename)
{
  unsigned short width = img[0].size();
  unsigned short height = img.size();
  unsigned int c;
  unsigned char widthLo = width%256;
  unsigned char widthHi = width/256;
  unsigned char heightLo = height%256;
  unsigned char heightHi = height/256;
  unsigned char header[18] = { 0, 0, 2, 0, 0, 0, 0, 0, 0, 0 };

  header[10] = heightLo;
  header[11] = heightHi;
  header[12] = widthLo;
  header[13] = widthHi;
  header[14] = heightLo;
  header[15] = heightHi;
  header[16] = 24;
  header[17] = 32; // image origin in upper left corner!

  ofstream Destination;
  Destination.open(filename.c_str(), ios::binary);
  if (!Destination)
  {
    cerr << filename;
#ifdef DE
    cerr << " kann nicht ge" << ouml << "ffnet werden!\n";
#endif
#ifdef EN
    cerr << " cannot be opened!\n";
#endif

    return false;
  }

  c = 0;
    
  while(Destination.tellp() < 18+width*height*3)
  {
    while (Destination.tellp() < 18)
    {
      Destination.put(header[c]);
      c++;
    }
    if (Destination.tellp() == 18)
      c = 0; // couter set back to count solely color tripels
    switch(c%3)
    {
      case 0:
    Destination.put(img[(c/3)/width].at((c/3)%width).get_blue());
    break;
      case 1:
        Destination.put(img[(c/3)/width].at((c/3)%width).get_green());
    break;
      case 2:
    Destination.put(img[(c/3)/width].at((c/3)%width).get_red());
    break;
    }
    c++;
  }
  
  return true;
}



...was ich allerdings auch nicht so richtig verstehe, denn dort kommen nirgendwo Gleitkommavariablen oder -numerale vor!

Ratlos...

Bis bald im Khyberspace!

Yadgar
--
Flagmaker - ein Programmier-Blog
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
15.07.2017, 20:30 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


Hi,

meist kommt diese Ausnahme, wenn du durch 0 teilst. (auch wenn ich hier das auch nicht sehe)

Was sagt den der Debugger?

Warum schreibst du denn den header nicht im ganzen? du kennst die größe doch? Auch deine Vektoren kannst du lesbarer schreiben.

Meist gibt man in diesem Fall deiner "Pixel"-Klasse eine "serialize"-Methode, die dein "Pixel" passend in einen puffer/datei schreibt. Danach musst du nur über deine vector-größen laufen, um alle pixel in einen puffer/datei zu schreiben.

Du mischt außerdem die Vektorzugriffe: warum einmal mit [] und einmal mit "at" ?

mach doch einfach nur img[(c/3)/width][(c/3)%width] ?
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
15.07.2017, 22:03 Uhr
Yadgar



Hi(gh)!


Zitat von FloSoft:

Was sagt denn der Debugger?



Nichts, ich kann mit dem Ding sowieso nicht umgehen... ich bin ja auch gar kein richtiger Programmierer, sondern nur ein Manta-Schrauber, der sturzbesoffen mit seinen nicht weniger alkoholisierten Kumpels versucht, die Technik eines Formel-1-Rennwagens zu ergründen... so komme ich mir beim Herumwurschteln mit C++ jedenfalls vor!


Zitat von FloSoft:

Warum schreibst du denn den header nicht im ganzen? du kennst die größe doch? Auch deine Vektoren kannst du lesbarer schreiben.

Meist gibt man in diesem Fall deiner "Pixel"-Klasse eine "serialize"-Methode, die dein "Pixel" passend in einen puffer/datei schreibt. Danach musst du nur über deine vector-größen laufen, um alle pixel in einen puffer/datei zu schreiben.



Hä?!?


Zitat von FloSoft:

Du mischst außerdem die Vektorzugriffe: warum einmal mit [] und einmal mit "at" ?

mach doch einfach nur img[(c/3)/width][(c/3)%width] ?



Das habe ich mal versucht - aber wenn ich mit [] auf die zweite Dimension des Arrays zugriff, kam immer eine Fehlermeldung, mit at dagegen nicht!

Aber längerfristig werde ich sowieso die ganze Arrayverarbeitung auf einfache unsigned char-Arrays umstellen (wahrscheinlich mit "händischer" Speicherverwaltung), wie mir auf de.comp.lang.iso-c++ (für die Jüngeren: das ist eine Usenet-Newsgroup, so ähnlich wie ein Forum, aber ohne Bling-Bling!) empfohlen wurde - mit all dem Klassen- und Vektoren-Tschingbumm ist YIP (Yadgar's Image Processor) nämlich deutlich langsamer als nötig!

Das aktuelle Problem habe ich lösen können, indem ich einfach dafür sorgte, dass YIP auch wirklich nur 24bit-TGAs als Eingabe bekommt... vielleicht beschäftige ich mich irgendwann in fernerer Zukunft mit dem Problem, jetzt will ich erst einmal neue Funktionen (vorgefertigte Paletten laden und auf Bilder anwenden) implementieren!

Bis bald im Khyberspace!

Yadgar
--
Flagmaker - ein Programmier-Blog

Dieser Post wurde am 15.07.2017 um 22:20 Uhr von Yadgar editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
16.07.2017, 10:34 Uhr
ao

(Operator)



Zitat von FloSoft:
meist kommt diese Ausnahme, wenn du durch 0 teilst. (auch wenn ich hier das auch nicht sehe)

Ist es möglich, dass width == 0 ist? Zum Beispiel, weil beim Einlesen oder Bearbeiten des Bildes irgendwas nicht wie geplant geklappt hat? Dann käme es zu einer Division durch 0.

Dieser Post wurde am 16.07.2017 um 20:09 Uhr von ao editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
16.07.2017, 11:02 Uhr
ao

(Operator)



Zitat von Yadgar:
Hi(gh)!
quote Flosoft: Was sagt denn der Debugger?
Nichts, ich kann mit dem Ding sowieso nicht umgehen...


Argh. Ich kann mich erinnern, dass wir diese Diskussion vor ziemlich genau anderthalb Jahren hatten.


Zitat:
Aber längerfristig werde ich sowieso die ganze Arrayverarbeitung auf einfache unsigned char-Arrays umstellen (wahrscheinlich mit "händischer" Speicherverwaltung),

Wenn du meinst, dass du es besser kannst als Creme de la creme der C++-Programmierer ...


Zitat:
wie mir auf de.comp.lang.iso-c++ empfohlen wurde

Verlink doch mal bitte den Thread, die Diskussion würde ich gern nachlesen.


Zitat:
mit all dem Klassen- und Vektoren-Tschingbumm ist YIP (Yadgar's Image Processor) nämlich deutlich langsamer als nötig!

Immer glauben die Newbies, sie wären die einzigen, die "richtige" Perfomance-Anforderungen haben, und alles, was die Profis mit ihren Bibliotheken bauen, wäre mehr oder weniger Spielkram für Freaks. Was für eine Ahnungslosigkeit und Selbstgefälligkeit! Genau das Gegenteil ist der Fall, und ihr solltet froh sein, mit Libs wie der STL kostenlos arbeiten und lernen zu dürfen.

Wenn man mit dem Tschingbumm richtig umgeht, ist es nicht merklich langsamer als eine Eigen-Implementierung - wenn überhaupt. Und es ist so gut getestet und so fehlerfrei, wie eine Software überhaupt nur sein kann. Das ist etwas, was so gut wie allen Eigenbauten erst mal völlig fehlt. Und ich finde es immer sehr schade, wenn jemand so lernresistent ist und das nach Jahren des Rumwurschtelns noch immer nicht erkennt

Dieser Post wurde am 16.07.2017 um 11:04 Uhr von ao editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
16.07.2017, 12:27 Uhr
FloSoft
Medialer Over-Flow
(Administrator)



Zitat von ao:

Wenn man mit dem Tschingbumm richtig umgeht, ist es nicht merklich langsamer als eine Eigen-Implementierung - wenn überhaupt. Und es ist so gut getestet und so fehlerfrei, wie eine Software überhaupt nur sein kann. Das ist etwas, was so gut wie allen Eigenbauten erst mal völlig fehlt. Und ich finde es immer sehr schade, wenn jemand so lernresistent ist und das nach Jahren des Rumwurschtelns noch immer nicht erkennt



Da kann ich ao nur zustimmen. Wir haben z.B bei uns beim arbeiten diverse "selbstbau"-speicherverwaltungen, o.ä entfernt "die ja so schnell waren, darum hat man das selbst gebaut" und haben nur damit bis zu 30% mehr performance rausgeholt das wir standard STL verwendet haben - soviel zu "selbstbau ist schneller".


Zitat von Yadgar:

Nichts, ich kann mit dem Ding sowieso nicht umgehen...


Dann lern es - Es ist als würdest du deinen Rennwagen immer nur im ersten Gang fahren, weil du nicht weißt wie man mit der Schaltung umgehen soll. So schwer ist es nicht einen debugger zu benutzen.
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
16.07.2017, 14:40 Uhr
ao

(Operator)



Zitat:
Aber längerfristig werde ich sowieso die ganze Arrayverarbeitung auf einfache unsigned char-Arrays umstellen (wahrscheinlich mit "händischer" Speicherverwaltung), wie mir auf de.comp.lang.iso-c++ empfohlen wurde

Ernsthaft, das haben die dir empfohlen? Alle Errungenschaften der letzten paar Jahrzehnte über Bord schmeißen und sämtliche Räder nochmal neu erfinden?

C++-Objekte händisch verwalten wird genau so krampfig wie plain-old-C-Arrays in Klassen pressen. Entweder man vergisst alles, was man über C++ weiß und programmiert in C, oder man benutzt C++, dann sind C-Style-Arrays tabu (außer an Schnittstellen zu Bibliotheken, die das so verlangen).
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
007
16.07.2017, 20:42 Uhr
Hans
Library Walker
(Operator)


Hi,

Zitat von Yadgar:


Zitat:

Was sagt denn der Debugger?



Nichts, ich kann mit dem Ding sowieso nicht umgehen...

Hi,

zugegeben, mit gdb kann ich auch noch nicht umgehen, aber das liegt daran, dass ich mich damit noch nicht ersnthaft beschäftigt habe. Aber es gibt dafür auch GUI-Frontends, die einem die Kommandozeilenbefehle abnehmen.
Und die diversen IDEs unter Windows (jedenfalls jene, die ich kenne: Open Watcom, Visual C++ und alte Borland- bzw. Turbo-C(++) Varianten) haben sehr einfach zu bedienende Debugger, die auf Quelltextebene arbeiten. Da gibt es die schöne Möglichkeit, im Einzelschrittmodus zu arbeiten, d.h. jede Zeile wird erst auf Knopfdruck ausgeführt und ein weiteres Fenster zeigt Dir, welche Variablen sich wie verändert haben. Damit hab ich schon so manchen Flüchtigkeitsfehler in der Logik meiner Programme gefunden

Und Wikipedia hat u.a. diese Tutorial zu gdb verlinkt, das mir beim ersten überfliegen einen recht brauchbaren Eindruck machte.

Hans
--
Man muss nicht alles wissen, aber man sollte wissen, wo es steht. Zum Beispiel hier: Nachdenkseiten oder Infoportal Globalisierung.

Dieser Post wurde am 19.07.2017 um 21:47 Uhr von FloSoft editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ C / C++ (GNU/Linux, *NIX, *BSD und Co) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: