Hallo zusammen,

ich möchte gerne aus JPEGs und GIFs Informationen auslesen. Nun möchte ich nicht auf Bibliotheken zurückgreifen, sondern selbst lernen, wie man so eine Datei ausliest und wieder schreibt.

Gehe ich da recht in der Annahme dass man einen Stream verwendet?
Gibt es ein Beispiel wie ein Ansatz aussieht?

Es geht mir mehr um den "Lerneffekt" als um ein sofortiges produktives Ergebnis

Danke!

Metapher: Du kannst ein Dateiformat mit einem Buch mit einer Inhaltsangabe vergleichen.
Meistens sind bei Daten zu Beginn Informationen über die Struktur der Datei vorhanden (meistens - weil das z.B. bei mp3. nicht unbedingt der Fall sein muss...). Diese muss dein Lesealgorithmus verstehen können (parsen, anwenden).

Weiters ist es so, dass wenn man ein Buch lesen können will, man das Alphabet beherrschen muss. Bei JPG Bildern ist es so, dass ein verlustbehafteter Kompressionsalgorithmus verwendet wird. Genauer kann ich dir auch nichts sagen - dazu empfehle ich dir aber folgendes:
http://www.wotsit.org/
Such dort nach JPG Header

Aber nach deinem Beitrag zu Folge schätze ich mal, dass die Grundlagen bei dir evt. noch nicht ausgereift sind, um evt. damit umgehen zu können. "Geht es mit Streams" ist dasselbe wie "Brauche ich meine Hände fürs Lesen" (Ja, zum Halten, aber nicht unbedingt direkt zum Lesen, das Buch kann man ja letzendlich auch auf einen Tisch legen - Daten müssen nicht unbedingt mit Streams geladen werden) EDIT: Damit meine ich, dass die Frage irrelevant ist...

MfG und viel Spaß ^^

Danke für Deine Antwort.

Im Prinzip geht es mir darum, dass ich wissen will WIE man am besten anfängt das Ganze zu verstehen
Das Anwenden vorgefertigter DLL-Dateien empfinde ich als nicht immer gewinnbringend....

Schließlich musst du einem "Grundschüler" auch beibringen in welche Richtung er lesen soll ^^

Ich muss nichts machen =P

Aber ich finde es gut, dass du - auch wenns nur eine leichte ist - Kritik vertragen kannst.
Also ich würds - wenn ich es ernst meine - so machen:
-Delphi Grundlagen perfektionieren
-Windows API lernen
-Einfache Dateiformate einlesen / bzw. selber erstellen

Die einzige Hürde an dem Ganzen ist Punkt 1. Alles Andere ist nur Lesestoff und Nachlagewerksarbeit~.
Und an einem gesunden Menschenverstand sollte es auch nicht fehlen.

Für den Anfang würde ich dir mal vorschlagen - so als Übung - eine beliebige Bitmap Datei manuell einzulesen. Dann wirst du auch sehen, wo du hängen bleibst und kannst daran arbeiten und daraus lernen.

Edit: "...WIE man am besten anfängt das Ganze zu verstehen..."
Ich finde, dass man am besten lernt, indem man einfach drauf losprobiert und soviele Fehler wie nur möglich macht... Aber belasse es dabei nicht. Lerne draus. Ein Meister ist jemand, der beinahe alle Fehler begannen hat und es nicht mehr (so oft) tut. Durchaltevermögen ist das Einzige was man dazu braucht.
Puh, bin echt vom Thema abgedrifted und ich mags eigentlich kaum, SOLCHE Tipps zu geben aber was solls xD

MfG

Hi,

während ich aphton zustimme, dass die Frage ob man einen Stream nimmt oder nicht nebensächlich für den Kern Deiner Frage ist, möchte ich an anderer Stelle auch wiedersprechen. Natürlich lernt man aus Fehlern, dass heißt aber nicht, dass man alle Fehler machen muss. Letztlich gibt es geradde in der SW-Entwicklung nur zu häufig den Hinweis, dass man das Rad nicht neu erfinden muss.

Wichtig ist hier deshalb auch die Erkenntnis, dass Du "normalerweise" lieber eine fertige Bibliothek verwenden solltest. Das heißt nicht, dass Deine Frage hier nicht beantwortet wird, aber im Arbeitsalltag hast Du nicht die Ressourcen um eine Bibliothek neu zu schreiben (ganz so pauschal ist's auch falsch). Tatsächlich kostet das Zeit und Du benötigst Erfahrung. Eine fertige Lösung ist hier häufig günstiger und muss immer noch an das Zielsystem angepasst werden. Du kannst hier davon ausgehen, dass die Entwickler schon "auf die Fresse gefallen" sein werden, natürlich kannst Du das auch selbst tun, aber das ist halt ein hohes Risiko und tut weh.

Natürlich gibt es auch die Situation, dass es noch keine oder keine ausreichend gute/ Deinen Bedürfnissen genügende Bibliothek gibt, schon deshalb ist wie gesagt, Deine Frage auch gerechtfertigt. Wenn Du jetzt einfach drauf los probierst, dann sind Deine Kenntnisse wirklich bescheiden und Du hättest etwas ganz wichtiges noch nicht gelernt, dass Denken viel günstiger ist als Ausprobieren!

Deshalb sollte man sich (wie Du es mit der Frage ja schon tust) Gedanken machen. Was die bekannten Dateien wie z.B. Tiff, GIF, PNG oder JPEG (natürlich auch andere) ausmacht ist ein bestimmter Aufbau. Man hält diesen in einer Spezifikation fest, hier wird Dir google ein guter Freund sein. Natürlich kannst Du auch bei Wikipedia immer Dein Glück versuchen,
Die ganzen Formate sind erstmal nur eine Ansammlung von Bytes. Das heißt ein Stream ist schon mal ein guter Anfang. Der innere Aufbau macht dann den Unterschied. Das ist schon mal eine Wichtige Erkenntnis, Du kannst Dir ein Grundgerüst bauen, dass eine Datei öffnet (und z.B. prüft ob die existiert, wie groß die ist, ob Du Lese-/Schreibrechte hast, ...) und Fehler abfängt und dieses Gerüst kannst Du für alle Dateiformate verwenden.

Wie jetzt die Daten interpretieren musst, sagt Dir die Spezifikation. Hier wirst Du sehen ob Du einen Header hast, der das File als solches Kennzeichnet (wie durch Aphton erwähnt ist das häufig der Fall), einige Dateien haben einen Footer (also etwas am Ende) und manche eine Mischung aus Beidem (z.B. bei PDF möglich).
Hier musst Du einfach schauen, welchen Aufbau die Datei hat und einen geeigneten Algorithmus entwickeln, der so eine Datei effizient auswerten kann. Wie man das am Besten macht hängt stark von dem Format ab. Ein Tiff verwendet mehrere verkettete "Inhaltsverzeichnisse" die ihrerseits wieder eine Menge Einträge unterscheiden, ein Bitmap hingegen umfasst nur einfache Metainfromationen und ein Feld, dass eben die Pixel umfasst.
Es bietet sich hier einfach an zu schauen, was hier gleich ist und was sich vollständig unterschiedlich verhält. Z.B. macht es Sinn das Auslesen von Einträgen in eine eigene Methode zu packen, da hier in der Regel ein festes Format vorliegt (z.B. 4 Byte die die Länge angeben, die nächsten 2 Byte den Typ usw.). Da solltest Du Dich an DRY (Don't Repeat Yourself) halten und den Code entsprechend strukturieren.
An sich bietet es sich dann an, dass Du mit den einfachsten Informationen anfängst, z.B. den Header auswertest und schaust, ob Du die Datei als solche korrekt erkennst oder ob die angegebene Länge in Byte der Dateigröße entspricht. Eine Sache die auch wichtig ist, wunder Dich nicht, wenn Du eine Datei findest, die dem Standard nicht 100%ig entspricht. Das passiert häufiger als man glaubt und auch wenn einige Reader mit solchen Dateien umgehen können, man sollte es nicht nachmachen! Vor allem solltest Du Deinen Reader robust gegen solche Fehler machen. Werden z.B. 500 MByte Nutzdaten angegeben, bleiben aber vom Zeiger aus nur 480 MByte in der Datei übrig (selbst ein Byte zu viel wäre schon schlecht), dann sollte Dein Reader an dieser Stelle ruhig eine Ausnahme auslösen, der Standard sieht sowas nicht vor!

Ich denke hier hilft es, wenn Du Dir einfach ein Format Deiner Wahl nimmst und mit dem mal anfängst. Lies Dir den Aufbau durch und versuche die Ideen zu verstehen. Hinter jedem Format steckt immer mindestens eine Person, die sich auch was dabei gedacht hat. Hast Du dazu fragen, ist die DP sicher hilfsbereit. Ansonsten kannst Du Dir dann überlegen, wie Du einen Reader aufbauen würdest (auch hier kannst Du natürlich ein Review durch die DP einholen). Zu guter letzt bleibt dann die Umsetzung und auch hier werden die Fragen sicher konkreter sein, so dass Dir leichter/ gezielter geholfen werden kann.

Ich stimme meinem Vorgänger voll und ganz zu obwohl ich mich mit der Philosophie "Das Rad neu erfinden ist böööösseee" nicht so vertrage.

Klar ist es um einiges schneller und einfacher, einen perfekten Kreis mit einem Zirkel günstig (eben schnell und mit wenig Arbeitsaufwand) hinzubekommen, aber solange man keinen Kreis als Künstler richtig zeichnen kann, ist das sehr schlimm (ok, hab jetzt nicht direkt darüber nachgedacht, wie schlimm das ist - aber gut ist es hingegen nicht).
Ich mein wenn man später einmal in der Lage ist, einen Kreis in beliebig verzerter Form zu zeichnen, so kann man dann aus diesem Repertoir der Kreise (Fähgikeiten) einen für die Aufgabe raussuchen und verwenden. Schwerer wirds, wenn man sich dafür extra Zirkel "kaufen" muss. Und es gibt kein Zirkel für alle beliebigen, verzerrten Kreise...

Mit dem "das Rad neu erfinden" ist man unabhängiger.

Ganz analog dazu ist das Programmieren.

Aber ganz egal wie ich dazu stehe, in der Industrie kommt man, wie es aussieht, damit nicht weit. Ist ja auch verständlich. Zumal keiner alles wissen kann.
Aber solange du dich daran interessierst, solltest du das tun, was du tun willst.
Erfinde das Rad neu!

Edit: Und das willst du ja xD
Übrigens, sorry für so viel Offtopic Talk...

=P

Zitat:

Ich stimme meinem Vorgänger voll und ganz zu obwohl ich mich mit der Philosophie "Das Rad neu erfinden ist böööösseee" nicht so vertrage.

Kommt darauf an. Das als Ausrede für eine nicht gemachte Aufgabe käme nicht so gut.

Zitat von mkinzler:

Zitat:

Ich stimme meinem Vorgänger voll und ganz zu obwohl ich mich mit der Philosophie "Das Rad neu erfinden ist böööösseee" nicht so vertrage.

Kommt darauf an. Das als Ausrede für eine nicht gemachte Aufgabe käme nicht so gut.

Ich schätze mal, dass du damit meinen Vorredner meinst?! (der, der gerne Räder neu erfindet, wirds sich doch bei Aufgaben ned scheuen xD)

Ja es ging um

Zitat:

"Das Rad neu erfinden ist böööösseee"