003
11.11.2015, 10:01 Uhr
ao
(Operator)
|
| Zitat von Yadgar: |
Um den TGA-Header überspringen ...
da ich zum Zurückschreiben der Farbdaten gerne die praktische fstream-Notation nutzen würde ...
|
Ich möchte diesen Ansatz mal ein bisschen in Frage stellen.
1. Was spricht dagegen, im ersten Schritt das ganze TGA-File inklusive Header in den Speicher zu holen? Das macht seekg überflüssig, und es ist immer einfacher, sich im Speicher zu bewegen als auf Dateien.
2. fstream beherrscht Schreiben und Lesen und ist daher ein vergleichsweise kompliziertes Objekt. Wenn du die Aufgabe so auf einzelne Schritte runterbrechen kannst, dass du zuerst die ganze Datei einliest, dann die Daten im RAM bearbeitest und am Ende alles zurückschreibst, dann kannst du die wesentlich schlankeren Implementierungen ifstream und ofstream benutzen.
Vorteile davon:
a. Der Code wird modularer. Du kannst für die Teilaufgaben "Datei lesen" und "Datei schreiben" wiederverwendbare Bausteine programmieren. Wenn alles miteinander verzahnt ist, ist das nur schwer möglich.
b. Jede Teilaufgabe fordert nur die Rechte und Resourcen an, die sie zur Erledigung braucht. Die Leseroutine muss z.B. keinen Schreibzugriff auf die Datei haben, d.h. sie wird auch auf Read-Only-Medien und geschützten Dateien funktionieren.
c. Die Bearbeitung der Pixeldaten findet komplett im Speicher statt, deshalb muss währenddessen überhaupt keine Datei geöffnet sein. Es ist "nett", Ressourcen nur so lange zu belegen, wie sie tatsächlich gebraucht werden.
Mir fällt nur ein Szenario ein, das ein Design wie deins notwendig machen würde: Blockverarbeitung. Wenn die Pixeldaten blöckchenweise durchgeschleust werden müssen, entweder weil die Software mit wenig Speicher auskommen muss oder weil die zu verarbeitenden Bilder extrem groß sind oder weil sie gar nicht als Dateien vorliegen, sondern als Datenströme über Netzwerk o.ä. rein- und rausgehen. Solche "Schmerzen" sollte man sich aber nur zufügen, wenn es sein muss.
Dieser Post wurde am 11.11.2015 um 10:03 Uhr von ao editiert. |
