LED-Farbspektrum Analyse

    5 nm Schritte sind auch ausreichend.
    Die Test Color Samples für die CRI Berechnung hab ich auch in 5 nm Schritten vorliegen und sie dann auf 1 nm interpoliert.
    Von daher ist das kein Problem.


    1 nm wäre halt im Bezug auf die Datenblätter schön, da die Daten ja meißtens schon sehr genau vorliegen und es ja kein sonderlichen Mehraufwand ist die dann auch in 1 nm Schritten zu extrahieren.
    Die anderen Kurven wie die V-Lambda Kurve oder die Tristimuluskurven hab ich auch in 1 nm Schritten.

    Ich hab gestern noch mithilfe eines VB-Makros eine Funktion eingefügt, mit der es nun einfach ist Daten zu interpolieren.


    Jetzt ist es prinzipiell so gut wie egal wie die Spektren vorliegen.
    Es kann also zB auch bei 381,541 nm anfangen und eine sich ändernde Schrittweite haben.
    Also bei gleichbleibender Schrittweite reichen die Infos über die Schrittweite, Startwellenlänge und dann der Datensatz.
    Oder direkt in der Art als x:y Tabelle.

    Hallo,


    super Lösung! An der Excel-Datei wäre ich auch interessiert...


    Ich hatte vor einigen Monaten so etwas ähnliches auch vor und hatte mit der Extraktion aus PDF-Dateien begonnen. Ich war allerdings über das Experimentierstadium nie hinaus gekommen.


    Testweise hatte ich aus dem Cree-XM-L-Datenblatt die Seite mit dem Graphen nach SVG konvertiert und die entsprechenden Path-Anweisungen vereinzelt. Das sieht dann so aus:


    <path d="M163.77,517.77 L163.79,517.78 L163.82,517.8 L163.84,517.81 L163.86,517.82 L163.91,517.85 L163.93,517.87 L163.95,517.88 .../>


    Daraus kann man sicher was machen. SVG ist ja relativ trivial und man kann recht simpel die Koordinaten (zur Not mit VBA) parsen. Dann noch die richtige Transformation anwenden und man hat seine x/y-Koordinaten...


    Vielleicht bekomme ich ja doch noch Deckenlampen per DMX in WW und KW mit hohem Cri hin :)


    Grüße
    Christoph

    Freut mich, das Interesse steigt. :)
    Ab mitte April hab ich wie gesagt wieder mehr Zeit und dann dauert es hoffentlich nicht mehr lange um eine erste Version fertig zu haben.


    Die Extraktion der Daten ist momentan bei mir auch das größte Problem. Hab mich bis jetzt aber auch nicht nochmal damit beschäftigt.
    Wollte mich erstmal um die Berechnungen kümmern um mal eine erste Version fertig zu haben. :)
    Hatte es auch mal so wie du ausprobiert. Erst in svg gewandelt und dann nach dem Datensatz geschaut. Ich vermute auch mal, dass es ja prinzipiell nicht so schwer sein kann die Daten in x/y-Koordinaten umzuwandeln. Das svg Format ist ja gut dokumentiert. Wäre schön die Extraktion so automatisiert wie möglich zu machen.


    Für Ideen oder Vorschläge von Funktionen oder ähnlichem bin ich wie gesagt offen. Wäre ja schön wenn das Tool nach und nach so umfangreich wie möglich wird.

    Ich habe inzwischen muPDF analysiert,
    Es ist wirklich schön strukturiert und man kann relativ leicht einen Vektorfilter drum herumbauen.
    Man kommt an die Transformationsmatrix und die Vektordaten, Strichstärke und Farben relativ leicht heran.
    Die Cree Spektren enthalten übrigens ca. 5700 Datenpunkte pro Spektrum.
    Ich hoffe ich habe Zeit und kann ein Tool fertig stellen mit dem man nicht nur die Spektralen Daten sondern auch alle
    anderen Diagramme extrahieren kann. So dass man die elektronischen Charakteristika auch berücksichtigen kann.
    lg Sol.

    Das klingt ja super mit muPDF! Die anderen Diagramme gleich mit zu extrahieren finde ich auch gut.
    Hätte nicht gedacht, dass es doch so viele Datenpunkte am Ende sind. Prinzipiell könnte man dann ja gleich alle extrahieren und muss die Beschränkung auf 1 nm nicht machen. Schaden tuts ja eigentlich nicht.


    Wäre auf jedenfall toll, wenn da am Ende ein Tool rauskommt.
    Aber das mit der Zeit kenne ich momentan zu gut. :D

    Mein damaliges Problem war die richtige "Linie" automatisiert in der .svg-Datei zu finden. Als Mensch sieht man so etwas recht schnell, aber automatisiert? Da gibt es viele path-Elemente in einer solchen Datei. Man könnte es Anhand der Farbe machen, aber auch da gibt es auch mal andere Linien auf einer solchen Seite, die die gleiche Farbe haben. Dazu kommt, dass die Linie zumindest bei den von mir konvertierten Cree-Diagrammen in mehrere path-Elemente (ich glaub zwei oder drei) zerbröselt. Die müsste man dann zusammenführen.


    Alles machbar, aber eine komplette Automation wird schwierig werden... vielleicht mit ein bisschen "Augen zu und durch" (alle path-Elemente mit einer gewissen Länge und gleichen Farbe werden schon irgendwie zusammen gehören...)?


    Gruß
    Christoph

    Oft besteht eine Kurve aus mehreren Pfaden.


    Man kann die Pfade gemäß Farbe und Liniendicke vorselektieren. Dann beginnt man mit dem Pfad, der die meisten Segmente enthält und sucht dann links und rechts die Anschlusspfade. Also die Pfade, deren End- und Anfangspunkte mit diesem Pfad zusammenfallen.


    Auf diese Weise fallen dann nicht verbundene Pfade automatisch heraus (z.B. Legende des Diagramms).


    Man kann als zusätzliches Kriterium nur solchen Pfaden folgen, die sich links und rechts entlang der x-Achse entwickeln. Es lohnt sich hierbei die Pfadbeschneidung aufzuheben, da die meisten Diagramme zustätzliche Daten enthalten.


    Wenn man jetzt alle Pfade hat, die zu einer Kurve gehören, ist dies meist eine Mischung aus Linien- und Bézier-Segmenten.
    Wenn man den Diagrammbereich und die Skala festgelegt hat, berechnet man die Transformationsmatrix, die die Punkte der Pfade auf die Zielskala abbildet.


    Man hat nun Linien und Bézier-Segmente und noch keine Datenpunkten!


    Das ist aber einfach: Man berechnet nun entlang der x-Achse jeden gewünschten y-Wert aus den Pfaddaten. Hierbei gibt man die gewünschte Schrittweite vor als 5nm, 1nm oder was auch immer...


    lg Sol

    Life results from the non-random survival of randomly varying replicators

    Einmal editiert, zuletzt von sol ()

    Hallo,


    also die Prüfungszeit ist vorbei und jetzt ist endlich wieder Zeit für die schöneren Sachen. :)


    Die nächsten Tage werde ich mich dann endlich wieder mit der Analyse beschäftigen.
    Bzw. genauer gesagt ist jetzt der Teil zur Optimierung des Mischungsverhältnisses nach
    verschiedenen Gesichtspunkten dran.


    Bei Fortschritten werde ich mich hier wieder melden.


    Gruß
    Nils

    Es gibt mehr oder weniger ein paar Fortschritte.


    Die Möglichkeiten von Excel sind zwar nicht wenig, aber es gibt immer mehr Sachen die mich mittlerweile daran stören.
    Was mich momentan am meißten stört ist, dass es ein riesen Aufwand ist wenn man ein Problem iterativ lösen möchte.
    Möglich ist es zwar schon, aber man muss jede Menge Zellen mit Formeln füllen. Das Problem könnte man natürlich lösen
    indem man sich ein Makro schreibt das dann die Berechnung übernimmt, aber dann könnte man es ja auch gleich anders machen
    und auch die anderen Einschränkungen von Excel umgehen. Außerdem hat Excel immer das komplette Blatt neu berechnet,
    inklusive der Zellen in denen es keine Änderung gab. Das könnte man zwar auch umgehen, aber das ist mir dann doch zu aufwendig,
    vor allem wenn ich weiß, dass es anders leichter geht.


    Deswegen hab ich mich dazu entschlossen das ganze in Java zu machen. Zu zeigen gibt es momentan noch nicht sonderlich viel,
    da es noch kein GUI gibt. Allerdings habe ich gestern bereits alle Funktionen zu Berechnung der einzelnen Werte, wie CRI, usw.,
    implementiert. Das heißt jetzt beschäftige ich mich wieder mit der Mischungsverhältnisberechnung.
    Was ich bereits erfolgreich getestet habe ist, die Berechnungen parallel über mehrere Threads zu verteilen. Bei der Berechnung von
    den Werten zu einem einzelnen Spektrum ist das zwar nicht unbedingt notwendig, aber wenn man das Mischungsverhältnis über einen
    Bereich der Schwarzkörperkurve im Bezug auf CRI berechnen will, dann ist es denke ich schon sinnvoll dies auf mehrere Threads und
    CPU-Kerne zu verteilen.

    Zur Motivation kann ich auch mal beitragen...


    Ich habe jetzt zwei Programme angefangen:


    Das erste (muvec.exe) wandelt .pdf in .vec Dateien um, die nur noch die Zeichenanweisungen für Vektoren enthalten. Es basiert auf der mupdf.lib.


    Das zweite Programm (leddex.exe) liest beide Dateien ein, wobei es den Acrobat Reader benutzt, um PDF Seiten zu rendern und die passende .vec Datei, um auf die Zeichenoperationen, Seitenausrichtung, Transformationsmatrix usw. zuzugreifen


    Über dem eingebetten Adobe Reader liegt ein unsichtbares Fenster welches die Nutzerinteraktion mit dem eingebettet Acrobat Reader unterbindet (so dass er Fehlerfrei ferngesteuert werden kann) und eine zweites unsichtbares Fenster liegt nochmals darüber, welches die Nutzerinteraktion zur Datenextraktion abwickeln wird. In diesem Fenster ist z.B. der Crosshair - Cursor oben im Bild gezeichnet. Man kann im PDF schon Seiten blättern und Zoomen...


    Leider komme ich immer nur in kleinen Schritten weiter aber wenn es fertig ist, möchte ich ein komplettes Modell einer LED aus dem Datenblatt vorliegen haben, um alle wesentlichen Aspekte zu simulieren.


    Die Programme sollten sich dann ziemlich gut ergänzen und jeder hat dann nur einen Teil der Arbeit ...


    Frohe Ostern


    sol.

    Life results from the non-random survival of randomly varying replicators

    Einmal editiert, zuletzt von sol ()

    bower1988
    Keine Angst, ich mach mir schon keine negativen Gedanken oder ähnliches.
    Hab mich aber trotzdem über deine Antwort gefreut. :)


    sol
    Sieht sehr interessant aus was du bereits gemacht hast. Vor allem was mich interessiert ist, wie für den Anwender am Ende die Datenextraktion abläuft, da die Datenblätter ja von Hersteller zu Hersteller unterschiedlich sind.
    Weißt du schon wie du das komplette Modell einer LED am Ende speichern möchtest bzw. was du für am sinnvollsten hälst? Ein kurzer Gedanke war grad alle Modelle zB in einer .csv Datei oder ähnlichem zu speichern, auf die man dann mit java zugreift. Aber war wie gesagt nur ein kurzer Gedanke und für den Datenaustausch zwischen den Pogrammen gibt es ja mehrere Möglichkeiten.
    Ich denke auch, dass sich die Programme ziemlich gut ergänzen und ich bin schon darauf gespannt wenn alles fertig ist. :)


    @all
    Fortschritte gibt es auch wieder ein paar. Nachdem ich mir einige Gedanken über eine möglichst optimale Mischungsverhältnisberechnung gemacht und einiges getestet habe, habe ich jetzt eine meiner Meinung nach sehr gute Methode gefunden. Momentan kann man in Abhängigkeit der Farbtempertur auf den Gesamt-Farbwiedergabeindex oder auch auf einzelne hin optimieren.
    Das gute daran ist, dass die Rechenzeit im Bezug auf die Anzahl der LEDs nicht exponentiell sondern linear steigt. Getestet habe ich es gerade mit 6 LEDs, die
    auf einen bestmöglichen Gesamt-CRI optimiert wurden. Ein anderes Mal kann ich gerne nochmal mehr drüber schreiben.


    Wie gesagt, ich bin für Ideen und Vorschläge von Funktionen oder ähnlichem offen.
    Man könnte die hier ja dann sammeln und dann mal schauen wie, wann und ob man die implementieren kann.

    Von mir auch nochmal ein Lob für die tolle Arbeit. Und gleich auch eine Idee, was man noch machen könnte... Wie wäre es mit einem .led-Dateiformat auf XML-Basis? Vielleicht bekommt man ja irgendwann mal einen Hersteller dazu, seine Daten direkt in diesem Dateiformat anzubieten? (Man darf wohl noch träumen....)


    Grüße
    Christoph

    Das wäre natürlich das Non plus ultra wenn Hersteller die Daten direkt in so einem Dateiformat anbieten würden. Dabei sollte das für die sogar weniger Aufwand sein als die Daten extrahieren zu müssen. Aber das bleibt wohl wie du schon geschrieben hast ein Traum.


    Bei der Berechnung des Mischungsverhältnis mit einem bestmöglichen CRI gibts auch immer mehr Fortschritte. Dabei bin ich mittlerweile schon so weit, dass es eigentlich keinen Sinn machen würde das beste Verhältnis zu berechnen. Die Rechenzeit über einen größeren Bereich der Schwarzkörperkurve ist mittlerweile sogar um einiges geringer als ich anfangs erwartet habe.


    Die Funktionen, die ich mir bis jetzt vorgestellt habe, hab ich jetzt weitesgehend implementiert. Der nächste größere Schritt wäre jetzt das Interface. Kommt drauf an wie das am Ende ausfallen soll, ist es ein kleinerer oder größerer Aufwand.



    Mir selber würde die Bedienung und die Funktionen schon reichen wie sie jetzt größtenteils sind. Momentan geht es über Kommandozeile und die Daten kopiere ich in Excel zwecks Anzeige. Schön wäre es natürlich alles in einem mit einem schönen GUI zu haben.


    Deswegen jetzt mal eine Frage an das Forum, wie dabei das Interesse besteht.
    Wenn es viele gibt, die für ein GUI wären, wäre es natürlich sinnvoll noch eins zu machen.
    Deswegen würde ich jetzt erstmal gerne in Erfahrung bringen wie groß das Interesse hier im Forum am Programm allgemein sowie an einem GUI wäre.
    (Bitte nicht falsch verstehen oder so, aber ich würde gerne einschätzen können ob sich der Aufwand für eine GUI lohnt.)