RGB-LED-Panel für Ambilight - geeignete LEDs/Dimensionierung?

fishbonev · 28. August 2006

Hallo an alle,

@Simon: bin noch nicht zum testen gekommen. Werd heute abend mal testen.

was evtl. noch zu tun ist das weighting zu modularisieren, dass in zkunft sowohl edge als auch corner modes berechnet werden könne. bzw. müssen wir dann noch eine 2D gewichtungsfunktion für den center kanal implementieren.

Nur mal so kurz überschlagen sollte die so aussehen. w=(|x-xmax/2|^a)*(|y-ymax/2|^b) wobei a und b gewichte für horizontal bzw vertikal sind. (ist noch nicht wirklich ganz durchdacht

so long
Peter

samc · 28. August 2006

Hallo

@Peter:

nur kein Stress, wenn du eben dazukommst Kümmer dich mal lieber um wichtige Dinge...

Zitat

was evtl. noch zu tun ist das weighting zu modularisieren, dass in zkunft sowohl edge als auch corner modes berechnet werden könne. bzw. müssen wir dann noch eine 2D gewichtungsfunktion für den center kanal implementieren.

Oder wir berechnen eben gleich 9 RGB Kanäle, vielleicht läßt sich der Zeitaufwand noch redizieren indem anstatt mit double float oder sogar (aufgeblasenes) int verwendet wird.

README und HISTORY hab ich schon angepasst Hab entdeckt dass du da eingetragen hast.

Zitat

w=(|x-xmax/2|^a)*(|y-ymax/2|^b)

Damit komm ich noch nicht ganz klar, kannst du was dazu erklären ?

daniel:

Dass die Farben besser gefunden wird liegt an der Histogrammfensterung vom Peter!
Was meinst du mit 0x2000 ? Das EEPROM wird doch von 0 an gezählt, oder hab ich da was falsch verstanden?

Der Mehrkanal Raw Mode ist eine gute Idee, vielleicht ein bischen unübersichtlich, vielleicht kannst du ihn ja in Abhängigkeit von einer #define DEBUG oder sowas machen...

Wenn du Wiki anfangen könntest wär wunderbar, ich geb dann schon meinen Senf dazu

Grüße Simon

daniel_k · 28. August 2006

Hallo,

Zitat

Dass die Farben besser gefunden wird liegt an der Histogrammfensterung vom Peter!
Was meinst du mit 0x2000 ? Das EEPROM wird doch von 0 an gezählt, oder hab ich da was falsch verstanden?

Nee, aus Sicht des Controllers ist 0 richtig, nur PonyProg zählt das EEPROM ab 0x2000.

Zitat

Der Mehrkanal Raw Mode ist eine gute Idee, vielleicht ein bischen unübersichtlich, vielleicht kannst du ihn ja in Abhängigkeit von einer #define DEBUG oder sowas machen...

Mal schauen, wie ichs einbaue, da wird mir schon was einfallen...

Zitat

Wenn du Wiki anfangen könntest wär wunderbar, ich geb dann schon meinen Senf dazu

Hmm, zum Texten bin ich allerdings auch nicht geboren. Mal sehen, was ich hinbekomme...

Gruß,
Daniel

Jo5Jo · 30. August 2006

Hallo Zusammen,

jetzt muss ich doch nochmal was grundsätzliches fragen: Ist es möglich das VDR-Plugin zu nutzen wenn die Bildausgabe über das Xine- oder das Softdevice-Plugin läuft? Geht das am Ende garnicht? Gestern habe ich mall spasseshalber das (alte, CCFL-)Plugin übersetzt und mitgestartet, darufhin bekam Xine keine Bilddaten mehr ?
Ist das ein prinzipbedingtes Problem oder kann man das Atmo- oder Ausgabepluginseitig eventuell beheben?

Danke,

Jo

daniel_k · 30. August 2006

Hallo Jo,
das Plugin öffnet das Device /dev/videoX zum Lesen der Bilddaten.
Wahrscheinlich führt das dazu, daß Dein xine- oder softdevice-Plugin
nicht parallel an das device rankommt. Ich habe ähnliche Probleme
mit der Vorschau vom vdr-admin. Bei Gelegenheit werde ich mal
versuchen, per vdr-api-Befehl auf die Bilddaten zuzugreifen. Ob dann
ein paralleler Betrieb möglich ist, kann ich leider noch nicht sagen,
aber ich hoffe es.

Gruß,
Daniel

jogibear9988 · 30. August 2006

Lese nun auch schon seit ein paar Wochen aufmerksam diese Threads...

Meit Ihr dasman das ganze auch mit Mythtv realisieren kann???

Gibts den möglichkeiten Bildsignale (Digital oder Analog) nach dem ausgang der grafikkarte irgendwie zu analysieren (mit einem DSP oder so)??? Wäre doch auch viel universeller??

daniel_k · 30. August 2006

Hallo,

Zitat

Meit Ihr dasman das ganze auch mit Mythtv realisieren kann???

Klar, wenn Du es schaffst, auf der seriellen Schnittstelle die Wunschfarbe auszugeben...

Zitat

Gibts den möglichkeiten Bildsignale (Digital oder Analog) nach dem ausgang der grafikkarte irgendwie zu analysieren (mit einem DSP oder so)??? Wäre doch auch viel universeller??

Warum sollte man sowas tun? Die Daten liegen doch im Framebuffer der Grafikkarte schon digital vor?!? Warum von analog mit nem DSP wieder nach digital wandeln?

Gruß,
Daniel

xnalpf · 30. August 2006

Weil es dann universell einsetzbar wäre - mit jedem Videogerät. Das Interesse an einer solchen Lösung dürfte aber speziell in diesem Portal gegen Null tendieren. Ich denke mal die meisten user dieses Portals haben mindestens einen VDR...

daniel_k · 30. August 2006

Das eine universelle Lösung besser wäre, ist klar. Wenn man Lust (und das notwendige Wissen hat), kann man ja auch mit einem DSP universell von diversen Bildquellen die Daten analysieren und diese dann über eine RS232-Schnittstelle an unseren Controller senden. Mit ner CPU für 1,65€ und max. 16 MHz Takt wird das jedenfalls nix und ist auch nicht Ziel der Entwicklung.

Gruß,
Daniel

skobi · 30. August 2006

Zitat

Originally posted by daniel_k
das Plugin öffnet das Device /dev/videoX zum Lesen der Bilddaten [...]

Code

thread.c:  if ((fd=open("/dev/video0",O_RDWR)) == -1)

Wenn ich mir das so ansehe, öffnet er das Device unnötiger weise auch zum schreiben... Hier wäre O_RDONLY wohl sinnvoller, oder? Dann sollten alle anderen idR auch weiterhin lesen dürfen, oder?!

Gruß
Skobi

samc · 30. August 2006

Zitat

Wenn ich mir das so ansehe, öffnet er das Device unnötiger weise auch zum schreiben... Hier wäre O_RDONLY wohl sinnvoller, oder? Dann sollten alle anderen idR auch weiterhin lesen dürfen, oder?!

Hab ich mir auch mal gedacht und probiert..dann gings nicht mehr.

Folgendes macht das Plugin mit dem device:

ioctl(fd,VIDIOCGMBUF,&m_buf);
map=mmap(0,m_buf.size,PROT_READ | PROT_WRITE, MAP_SHARED,fd,0);

Wenn ich mich recht erinnere, dann klappt der mmap nicht mehr. Habs auch mal mit einem read() versucht, ging auch nicht.

Jemand eine Idee dazu? Wär schon praktisch wenn man ro öffnen könnte...

Grüße,
Simon

anbr · 30. August 2006

Zitat

Original von samc
Jemand eine Idee dazu? Wär schon praktisch wenn man ro öffnen könnte...

Vielleicht sollte gleich auf GrabImage - dvbdevice.c:530
uchar *cDvbDevice::GrabImage(int &Size, bool Jpeg, int Quality, int SizeX, int SizeY)
umgestellt werden. Der Code sieht zumindest ähnlich aus...

Edit:
Mit
GetPrimaryDevice()->GrabImage(...)
sollte recht einfach die Bilddaten holen lassen.

Andreas

skobi · 30. August 2006

Zitat

Originally posted by samc
[QUOTE]Wenn ich mir das so ansehe, öffnet er das Device unnötiger weise auch zum schreiben... Hier wäre
map=mmap(0,m_buf.size,PROT_READ | PROT_WRITE, MAP_SHARED,fd,0);

wenn da ein PROT_WRITE steht, dann muss er bei open auch ein RW haben, jedoch willst du ja gar nicht auf der page schreiben, oder? Wozu also das PROT_WRITE?

Skobi

skobi · 30. August 2006

Zitat

Originally posted by skobi

wenn da ein PROT_WRITE steht, dann muss er bei open auch ein RW haben, jedoch willst du ja gar nicht auf der page schreiben, oder? Wozu also das PROT_WRITE?

Skobi

Habe das gerade mal kurz getest, ohne das PROT_WRITE klappt bei mir mmap auf eine Textdatei.

Skobi

daniel_k · 30. August 2006

Zitat

Habe das gerade mal kurz getest, ohne das PROT_WRITE klappt bei mir mmap auf eine Textdatei.

So, habs auch mal kurz getestet:
Wenn ich das PROT_WRITE rausnehmen, geht leider ioctl(fd,VIDIOCMCAPTURE,&v_map) schief
Ich glaube, ich versuch mich mal lieber am Vorschlag von hulk...

Gruß,
Daniel

samc · 30. August 2006

Hallo,

Zitat

wenn da ein PROT_WRITE steht, dann muss er bei open auch ein RW haben, jedoch willst du ja gar nicht auf der page schreiben, oder? Wozu also das PROT_WRITE?

ups zu spät gelesen, hab das auch schon mal ausprobiert, -> siehe Antwort von Daniel

Es gab mal Aussagen das mit dem Grabimage würd den VDR zum Abstürzen bringen, wenns aber doch klappen sollte wärs super!
Daneil, probierst duds aus?

Wenn ja: beachte, das die Zeitsyncronisation über die fertiggestellten Captures funktionert, wenn du also immer "sofort" lesen könntest gäbs 100% CPU
->ein Delay einbauen

Grüße,
Simon

daniel_k · 30. August 2006

Hallo Simon,

Zitat

Es gab mal Aussagen das mit dem Grabimage würd den VDR zum Abstürzen bringen, wenns aber doch klappen sollte wärs super!
Daneil, probierst duds aus?

Ja, hab ich schon -> Absturz oder so
Werd das mit dem delay noch mal ausprobieren...

daniel_k · 30. August 2006

Simon, du bist klasse!
Das mit dem delay war der Trick! Nun nur noch den Farbdreher raus
und ich bin glücklich. vdradmin und atmolight laufen auf jeden Fall
schon mal parallel!

EDIT: Hmm, wohl zu früh gefreut: Gelegentlich hat der vdradmin wohl doch
keinen Zugriff

Gruß,
Daniel

samc · 30. August 2006

Hallo Daniel,

hört sich ja schon ganz gut an!
Wie lange ist denn dein delay?
Sollte wohl was im Bereich von 40ms sein.

Die Frage ist: wo nimmt Grabimage die Daten her??

Zeig doch mal deinen code...

Grüße,
Simon

daniel_k · 30. August 2006

Hallo Simon,
als delay habe ich 40ms genommen.

Die CalcColors habe ich wie folgt geändert:

Code

tColorPacket_new cAtmoThread::CalcColors(void)
{
tColorPacket_new ColorChannels;//TODO initialize with black //TODO COLOR PACKET Handling
// unsigned char *map;
int Imagesize;
unsigned char *map = cDevice::PrimaryDevice()->GrabImage(Imagesize, false, 0, 64, 48 );


//handle start problems ;-)
if (map == NULL)
return ColorChannels;


//Generate RGB Image
// RGB_Img[idx].b = (double)*map++/255.0f; // -> [0;1]
// RGB_Img[idx].g = (double)*map++/255.0f; // -> [0;1]
// RGB_Img[idx].r = (double)*map++/255.0f; // -> [0;1]
// fuer grabImage: andere Reihenfolge
RGB_Img[idx].b = (double)*map++/255.0f; // -> [0;1]
RGB_Img[idx].r = (double)*map++/255.0f; // -> [0;1]
RGB_Img[idx].g = (double)*map++/255.0f; // -> [0;1]
...

Alles anzeigen

Und hier kommen die Daten her:

Code

uchar *cDvbDevice::GrabImage(int &Size, bool Jpeg, int Quality, int SizeX, int SizeY)
{
  if (devVideoIndex < 0)
     return NULL;
  char buffer[PATH_MAX];
  snprintf(buffer, sizeof(buffer), "%s%d", DEV_VIDEO, devVideoIndex);
  int videoDev = open(buffer, O_RDWR);
  if (videoDev >= 0) {
     uchar *result = NULL;
     struct video_mbuf mbuf;
     if (ioctl(videoDev, VIDIOCGMBUF, &mbuf) == 0) {
        int msize = mbuf.size;
        unsigned char *mem = (unsigned char *)mmap(0, msize, PROT_READ | PROT_WRITE, MAP_SHARED, videoDev, 0);
        if (mem && mem != (unsigned char *)-1) {
           // set up the size and RGB
           struct video_capability vc;
           if (ioctl(videoDev, VIDIOCGCAP, &vc) == 0) {
              struct video_mmap vm;
              vm.frame = 0;
              if ((SizeX > 0) && (SizeX <= vc.maxwidth) &&
                  (SizeY > 0) && (SizeY <= vc.maxheight)) {
                 vm.width = SizeX;
                 vm.height = SizeY;
                 }
              else {
                 vm.width = vc.maxwidth;
                 vm.height = vc.maxheight;
                 }
              vm.format = VIDEO_PALETTE_RGB24;
              if (ioctl(videoDev, VIDIOCMCAPTURE, &vm) == 0 && ioctl(videoDev, VIDIOCSYNC, &vm.frame) == 0) {
                 // make RGB out of BGR:
                 int memsize = vm.width * vm.height;
                 unsigned char *mem1 = mem;
                 for (int i = 0; i < memsize; i++) {
                     unsigned char tmp = mem1[2];
                     mem1[2] = mem1[0];
                     mem1[0] = tmp;
                     mem1 += 3;
                     }
...

Alles anzeigen

RGB-LED-Panel für Ambilight - geeignete LEDs/Dimensionierung?

Jetzt mitmachen!

Teilen