Farben im Rendite/Volatilität-Diagramm

Hallo,

mir ist eine Kleinigkeit im Rendite/Volatitlität-Diagramm aufgefallen. Ursprünglich waren die Punkte mal rosa/rötlich. Wenn ich jetzt die Datenreihen zurücksetze und eine neue Datenreihe hinzufüge sind sie in Blautönen. Testweise habe ich eine neue Datei angelegt, hier sind die Punkte wieder rosa. Ich habe mal versucht die prf_* Dateien zu löschen und in der xml die Definitionen der Dashboards gelöscht, aber ohne Erfolg. Wo wird die Info denn gespeichert?

Du kannst die Farben ändern, in dem Du in der Legende mit rechts auf die gewünschte Datenreihe klickst und dann den Menüpunkt “Farbe…” auswählst. Löst das Dein Problem?

Ja, das kenne ich schon. Es geht mir aber darum welche Farben standardmäßig verwendet werden, wenn Datenreihen zu einem leeren Diagramm hinzugefügt werden. In meiner PP-Datei fängt es mit blau an, in einer neuen, jungfräulichen Datei mit rosa.
Vielleicht etwas kleinlich, aber: Warum? :yum:

:laughing:

Automatisch Farben zu vergeben die auch noch passen stellt sich als schwer heraus. Im Prinzip wandere ich um den Farbkreis herum. Und je mehr mögliche Datenreihen es gibt (Wertpapiere, Klassifikationen, …) desto kleiner sind die Schritte. Darum kann das auch je nach Datei unterschiedlich sein.

Ich habe schon mal überlegt ob man dem Wertpapier eine Farbe hinterlegen können soll. Die könnte dann auch in den Diagrammen genommen werden. Aber will man sich wirklich den Aufwand geben, dass in den Einstellungen zu pflegen - oder im Diagram - wie von @Thomas beschrieben - per Rechtsklick ändern.

Hallo Andreas,

erst mal herzlichen Dank für die klasse Application!

Ich habe schon mal überlegt ob man dem Wertpapier eine Farbe hinterlegen können soll. Die könnte dann auch in den Diagrammen genommen werden.

Genau dieses Feature fände ich super hilfreich und Klasse. Aktuell muss man in allen Diagrammen die Farben neu auswählen wenn man Datenreihen hinzufügt/wegnimmt. Ich möchte aber gerne meinen paar Aktien feste Farben vergeben und diese dann in allen Diagrammen wiederfinden.

cu(lix)

je mehr mögliche Datenreihen es gibt desto kleiner sind die Schritte.

Das ist absolut richtig. Je mehr Punkte, desto subtiler die Farbenunterschiede. Deswegen auch mein Früherer Vorschlag mit den Formen. :wink:

Ah, danke, das ist die Erklärung!

Wäre es denn möglich die Schritte im Farbkreis zu vergrößern, so dass du zwei oder mehrmals den Farbkreis umwanderst (natürlich ohne, dass sich die Farben überlappen)?
In der Praxis habe ich immer das Problem, wenn ich drei Wertpapiere in ein Diagramm hinzufüge sind alle drei eine Schattierung von hellblau… :slight_smile:

In den Charts (z.B. Performance) werden die Farben ja zurzeit automatisch gewählt und zugewiesen.

Das ist einerseits gut, denn sobald man dort mal eine größere Menge (20+) Papiere vergleichen möchte, erspart das sehr viel manuelle Arbeit.

Andererseits funktioniert es nicht reibungslos. Bei mir liegen immer wieder zu viele der generierten Farben zu dicht beieinander. Da sind dann z.B. 5 Abstufungen von Lindgrün im Chart oder 3 von Violett, während z.B. keine einzige Kurve in Rot gezeichnet wurde, und ich muss manuell anfangen, Farben zu ersetzen.

Ich nehme an, dass alle Farben durch PP komplett zufällig generiert werden und die Streuung deswegen ebenfalls rein zufällig ist. Dann müsste das doch relativ leicht zu verbessern sein. Man könnte den gesamten Farbraum in gleich große Scheiben unterteilen und dann mit konstanten Abständen auf die Kurven verteilen.

In Pseudocode:

// Für R,G,B seien jeweils im Werte von 0 bis 255 zulässig.
// Der letzte Wert (255/255/255) fällt raus, weil Weiß auf Weiß unpraktisch wäre.

rgbMax = 255 * 255 * 255;
papiere = 27 // Beispiel

for (i = 0; i < papiere; i++) {
farbe[i] = decimalToRgb( (i / papiere) * rgbMax );
}

Falls die bisherige Verteilung reiner Zufall sein sollte, fände ich eine systematische Verteilung auch besser. Ich würde vorschlagen die Verteilung im HSV-Farbraum durchzuführen, da man damit wesentlich besser arbeiten kann. Bei Bedarf kann man dann immer noch von HSV zu RGB konvertieren.

Mein Beitrag wurde gerade hierhin verschoben. Mit der Information von @AndreasB oben hat sich der Vorschlag wahrscheinlich erledigt. Mich überrascht nur, dass die generierten Farbwerte bei mir so dicht beieinander liegen, wenn doch das Verfahren schon so ist wie ich vorhin vorgeschlagen hatte?!

Die Farben werden aus dem Farbkreis genommen:

class ColorWheel implements Iterator<RGB>
{
    private static final float HUE = 262.3f;
    private static final float SATURATION = 0.464f;
    private static final float BRIGHTNESS = 0.886f;

    private int index;
    private float[][] hsbColors;

    ColorWheel(int size)
    {
        hsbColors = new float[size][];
        float step = 360.0f / (float) size;
        for (int ii = 0; ii < size; ii++)
            hsbColors[ii] = new float[] { (HUE + (step * ii)) % 360f, SATURATION, BRIGHTNESS };
    }

Aber wenn ich über Deinen Post, @simpson, nachdenke, dann liegt der Unterschied vielleicht daran, dass ich beim Öffnen des Diagramms allen möglichen Datenreihen schon Farben zuordne. Und das können eine ganze Menge sein: für jedes Wertpapier, dann noch mal als Benchmark, dann Kombinationen von Konten und Depots, etc.

Ich muss mal ausprobieren ob ich das dahingehend ändern kann, dass die Farbe erst vergeben wird, wenn man eine Datenreihe dem Diagramm hinzufügt. Das sind deutlich weniger - also auch weniger “Konflikte”…

1 Like

Hallo @AndreasB, das mit der Reduzierung der Wertpapiere wäre eine Möglichkeit; wenn Du die RGB-Version oben mit Deiner vergleichst, unterscheiden sie sich aber auch dadurch, dass die RGB-Version auch durch die Brightness läuft, d.h. es könnte ein helles, ein mittleres und ein dunkles Rot geben, während bei der HSL-Implementierung ja die Brightness fix ist, so dass statt N*M dort nur N Farben zur Verfügung stehen, oder verstehe ich das gerade falsch? (Klar, ein ganz dunkles Blau und ein ganz dunkles Braun unmittelbar nebeneinander dienen auch nicht der Übersichtlichkeit; trotzdem sind es aber insgesamt einfach mehr Farben, d.h. die das Risiko, dass Farben nebeneinander liegen, müsste insgesamt sinken.)

1 Like