Technix Posted November 5, 2009 Report Share Posted November 5, 2009 Graphiken kann man z. B. mit den R-Paketen pixmap (.ppm .pgm .ppm) oder caTools (.gif) direkt einlesen. Damit man nicht zig Artefakte gesondert behandeln muß, kann man die gegebenenfalls mit einer Graphik-Filter-Sprache (z. B. Filter Factory Plus weg machen, das war hier aber nicht nötig. Ich habe es aber mit einem awk-Skript aus dem .pgm-Format gemacht. Eine Zwischen-Stufe der Verarbeitung habe ich mal als impressive ASCII-Graphik gespeichert, die von einem originalen Graphik-Format kaum zu unterscheiden ist (geht nicht mit Opera!). In der Graphik sind nur die drei relevanten Farben übrig geblieben ' ' für Hintergrund, '+' für Kerzen-Rahmen und -dochte und 'x' für die Füllung von Down-Candles. Der Rest ist einfaches Iterieren in X- und Y-Richtung. @ joshsmi: Daher war auch die Zeitzone überall richtig, weil die vorgegeben war und nicht gelesen wurde. Die originalen Graphiken von titanfx schnitten den gleichen Zeitraum mit, unabhängig von der je nach Anbieter unterschiedlichen Beschriftung der Zeitachse. Ansonsten ist der von Dir gezeigte Effekt in allerhöchstem Maße erklärungsbedürftig, da sich die Kurse ja schließlich durch das Ausdrücken der gleichen Zeit in einer anderen Zeitzone nicht ändern, wenn diese nur nominell um gerade Stunden umbenannt wird. Ansonsten kann es wirklich zu verfälschenden Effekten durch die unterschiedliche Zuordnung an den Intervall-Grenzen kommen, je nach Software wird nicht mal die Zeit für die Kurse übertragen (z. B. bei Interactive Brokers), daher muß die Uhr mit einem NTP-Server fortlaufend abgeglichen werden. Tools und Einstellungen dazu sind in diesem Post beschrieben. Es ist aber nicht möglich, daß diese Effekte immer nur bei FXD 24 auftreten und in sehr vielen Intervallen. awk war dafür übrigens nicht die beste Wahl, der interpretierte Skript lief über eine Minute auf einem Atom-Netbook (was ich natürlich erst wußte, als er fertig war), aber die gleiche Lösung in C würde in Sekunden gehen und auch PHP wäre schneller, weil es trotz Interpretation intelligenter den Zwischen-Code vorhält. Ich nehme bloß für viele schnelle kleine Konvertierungen gerne den sehr einfachen awk (PERL ist wesentlich mächtiger und wer ohnehin PHP kann, kann für die gleichen Aufgaben auch den PHP-Batch-Prozessor (ohne Web-Server) nehmen, ohne eine neue Sprache zu lernen. Der PHP-Code sieht meist sogar besser aus als in AWK oder PERL. Die Formate .ppm (Portable Pixel Map), .pgm (Portable Gray Map) und .pbm (Portable Bit Map) stellen die primitivsten Formate dar, mit dem Graphiken über alle System-Grenzen hinweg ausgetauscht werden können. Nach einem Header, der die Größe und die Anzahl der Farben angibt, werden einfach die Farbwerte für alle Pixel hintereinander ins File geschrieben. Dabei gibt es für jedes der drei Formate eine platzsparende binäre Variante und eine Variante mit menschen-lesbarem Text, der auch mit allen üblichen Unix-Kommandozeilen-Tools weiter bearbeitet werden kann. Diese Formate sind mangels Kompression nicht für Bandbreiten- und Speicherplatz-sparende(n) Transport und Speicherung ausgelegt, sondern für den einfachst-möglichen Zugriff überhaupt. Die portablen File-Formate sollte jede vernünftige Bild-Verarbeitungs-Software lesen und schreiben können. Ein Top-Tool für schnelle Bild-Konvertierungen ist der kostenlose IrfanView, der sogar Photoshop-Plugin-tauglich ist. Auch für das Lesen von Graphiken im Original-Format gibt es genügend Bibliotheken, die unter anderem auch in PHP verfügbar sind. Dort wird ein einzelner Bildpunkt mit der GD2-Funktion ImageColorAt ausgelesen. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.