[ANNOUNCE] Atmolight - Release 0.1.1

Hi Samael,

verstehe. Ich dachte immer sowas in der Art würde es schon längst im VDR geben.
Na dann wird Klaus das ja bestimmt irgendwann mal einbauen. Ich kann damit auch erstmal gut leben, atmo ist wichtiger als anderer Schnickschnack Dank dir für die Infos.

Hi,

wenn ich mir das Plugin betrachte (mit TT 2300C als Input-Device), sind immer zwei Threads aktiv. Der erste ist cInputDeviceFFDVB::Action(). Dieser 'grabbt' alle 40ms ein neues Bild, rechnet die Farbräume um und kopiert alles nach ColorPacket. Die 40ms werden über die FF-DVB-Karte vorgegeben. Der zweite Thread ist cAtmoThread::Action(). Dort wird das ColorPacket vom ersten Thread geholt, die Farbwerte berechnet und ausgegeben. Dieser Thread läuft im 20ms Zyklus asynchron zum ersten Thread.

Ich sehe da zwei Probleme:

1.) Der zweite Thread kann sich ein ColorPaket vom ersten Thread holen, obwohl der erste es gerade kopiert. Es fehlt irgendein Verriegelungsmechanismus für gleichzeitige Zugriffe.

2.) Es macht eigentlich keinen Sinn, den zweiten Thread mit halber Zykluszeit laufen zu lassen. Es gibt nicht so häufig neue Daten. Ist es nicht sinnvoller, den zweiten Thread immer nur bei einem neuen Bild/Farbwerten vom ersten Thread zu triggern? Dies würde auch die CPU-Last reduzieren (CPU-Last ist nicht wirklich ein Problem).

Gruß
e9hack

Hi,

hab die aktuelle Version jetzt nicht im Kopf, aber eigentlich müsste es genau so laufen wie du es als "soll" bezeichenst. Die 20ms delay sollten nur in dem Fall greifen, wenn es Fehler beim Grabben gibt. Also ein "Not-Delay" da sonst die CPU-Last auf 100% geht...

Wenn das nicht mehr so ist, dann ist es falsch

Grüße,
Simon

Zitat

Original von Samael
Hallo,

Ja, ist unschön, macht bis jetzt so aber keine Probleme.

Ich habe den Verdacht, daß das gelegentliches Flackern davon kommt. Seit ich den Zugriff per cMutex schütze, ist das Flackern scheinbar nicht mehr da.

Zitat

Außerdem kann es ja auch Inputdevices geben, die nicht so langsam
wie eine FFDVB sind.

Ich habe ja extra auf die DVB-Karte verwiesen.

Mir ist noch mehr aufgefallen:
Der Weißabgleich erfolgt vor der Gammakorrektur. Er muß eigentlich danach erfolgen.

Gruß
e9hack

Hi,

Weißabgleich/Gamma:

die eigentlich benutzte Gamma-Korrektur erfolgt im Controller. Die Parameter im Plugin sind für Controller ohne Korrektur gedacht; genauso kann das Gamma im Controller damit leicht beeinflußt werden. Weiss aber nicht, wie man das Gamma genau kalibrieren könnte...
-> Gamma-Korrektur im Plugin wird im Moment wohl nicht benutzt

Ob der Weißabgleich vor oder nach dem Gamma erfolgt ist eigentlich unwesentlich.
Psychologisch günstiger ist vor der Gammak., der Weißabgleich entspricht so dem menschlichen Sehempfinden.

Mathematisch ist es egal, hab da auch mal eine Gleichung aufgestellt.

Die "eigentliche" Gamma-Korr. erfolgt ja sowieso erst im Controller -> Gammak. im Plugin liegt im Moment unmittelbar vor der Gammak. im Controller, und so halte ich das auch für sinnvoll...lass mich aber gern auch eines Besseren belehren.

PS: Den Filter mit 50Hz laufen zu lassen ist sicher nicht unsinnig, obwohl es doch am Anfang auch mit 25Hz gut lief, oder?

Eine Frage habe ich noch:
Das "gelegentliche Flackern" wie hast du das beobachtet? Die Filter ausgeschaltet oder flackert es _nach_ dem Filter? Wenn das so ist, kannst du an die entscheidende Stelle im Filter (Sprungerkennung) eine Debugmeldung ausgeben lassen. Kommt keine und es flackert, liegts nicht am Plugin.

Grüße,
Simon

Zitat

Original von Samael

Wie gesagt, die Art des Zugriffs ist weder von mir noch von Anderen
als Problem angesehen worden. Klar, Flackern läßt sich durch Filtern
"ausschalten" und ist vielleicht deshalb nicht beobachtet worden.
Flackern kann natürlich aber genausogut aus dem Fernsehbild entstehen.
Nichtsdestotrotz kannst Du mir gerne Deine Änderungen zukommen
lassen.l

Alles anzeigen

Ich hatte noch eine weitere Änderung in der Software drin, sodaß der Mutex möglicherweise nicht die Abhilfe war. Ich will die vom Atmo-Plugin gegrabbten Images an das Avards-Plugin durchreichen. Daher wird das Image in voller Auflösung gegrabbt. Ich bilde dann den Mittelwert über einen Bereich von ca. 11x10 Pixel und reiche das an die Farbanalyse weiter.

Gruß
e9hack

Zitat

Original von samc

Ob der Weißabgleich vor oder nach dem Gamma erfolgt ist eigentlich unwesentlich.
Psychologisch günstiger ist vor der Gammak., der Weißabgleich entspricht so dem menschlichen Sehempfinden.

Mathematisch ist es egal, hab da auch mal eine Gleichung aufgestellt.

Es ist nur dann egal, wenn die Gamma-Korrektur eine lineare Funktion ist. Da sie das nicht ist, gehört der Weissabgleich hinter die Gammakorrektur.

Ich denke darüber nach, die Farbinformationen als 16-Bit-Werte an den ATMega zu übertragen und alle Berechnungen im Atmo-Plugin zu machen.

Gruß
e9hack

Zitat

Original von Samael
Außerdem kann es ja auch Inputdevices geben, die nicht so langsam
wie eine FFDVB sind.

Wenn die eigentliche Quelle ein MPEG2-Stream im PAL-Format ist, liefert auch das Stream-Device nur alle 40msec neue Daten. Durch das 'runter-skalieren' wird nur ein Halbbild benutzt. Das wird nicht öffter aktuallisiert.

Gruß
e9hack

Hallo e9hack,

Zitat

Es ist nur dann egal, wenn die Gamma-Korrektur eine lineare Funktion ist. Da sie das nicht ist, gehört der Weissabgleich hinter die Gammakorrektur.

Wie samc bereits sagte: Psychologisch richtig ist die Gamma-Korrektur vor dem Weissabgleich.
Warum sollte er Deiner Meinung nach erst dahinter erfolgen?

Gruß,
Daniel

Zitat

Original von samc
Ob der Weißabgleich vor oder nach dem Gamma erfolgt ist eigentlich unwesentlich.

Mathematisch ist es egal, hab da auch mal eine Gleichung aufgestellt.

Hast recht, wenn man es nachrechnet, ist es egal:

y = (w*x)^k = w^k * x^k

und w^k ist konstant. Mathe war halt vor langer Zeit mal...

Gruß
e9hack

Hi,

mach dir nix draus, war damals auch 2 Wochen unsicher obs was ausmacht, bis ichs dann eben doch mal ausgerechnet hab, so wie du

Grüße,
Simon

Hallo
Wenn ich im wiki alles richtig verstanden habe, dann läuft dieses Plugin nicht mit dem Plugin Xineliboutput. Wenn es technisch generell möglich ist, ist ein update in dieser Richtung geplant? Ich plane gerade einen neuen VDR ohne FF Karte, und hatte mich gerade mit Xineliboutput angefreundet. Bis ich dieses Plugin gefunden habe.

doe

Hallo zusammen.

Ich habe mir das Atmolight nun auch gebaut, allerdings mit einem AT-Mega64. Ich weiss, ist oversized, aber den hatte ich noch... Zur Inbetriebnahme hab' ich mir ein kleines Windows-Prog geschrieben, das das Protokoll aus COM1 raushämmert. Hat jemand interesse? Oder kann man das vielleicht in das AtmoLight-Package integrieren?

Zitat

Original von MegaNobbi
Ich habe mir das Atmolight nun auch gebaut, allerdings mit einem AT-Mega64. Ich weiss, ist oversized, aber den hatte ich noch...

Wenn Dein Atmolight nur zwei Kanäle hat, dann benutzt Du hoffentlich die Hardware-PWM von Timer 1 und 3 ...

Gruß
e9hack

Nö, ich hab die Quellen des Mega8 genommen, ein paar Register angepasst (UART1) und schon lief es. Faulheit siegt

@ MegaNobbi

Wegen Atmo und Windows gibt es schon was hier im Forum...

Schau mal hier:
[atmocontroller] Betrieb unter Windows

Etwas weiter unten geht es los...

HI,

ich habe das Atmolight ja nun erfolgreich im Betrieb, ich habe heute alles verkabelt, löcher gebohrt und angeschlossen.

Nun wollte ich mich dran machen einen Weißabgleich durchzuführen und finde den Menüpunkt nicht..

Ich habe diesen eigentlich unter Moduseinstellungen erwartet dort gibt es aber nur Livebild, Standardfarbe und statische farbe. Ich nutze easyvdr und habe das Pugin bereits neu runtergeladen und kompiliert...

Bei mir funktioniert auch die Farbkalibrierung nicht, sobald ich den punkt aufrufe, beendet sich das setup sofort. Im Logread steht nichts.

Ich nutze zulus ext-32 mit dem setup-plugin-patch...

MfG
KRis