DIY Ambilight howto?

quote:

naftebakje schreef op dinsdag 10 januari 2006 @ 17:59:
[...]

Mooi gedaan. Maar wat wat bedoel je met die 4 sensoren? 4 A/D's die sync, R,G,B uitlezen?
Of heb je het over je geluidssensoren?

Bedankt, wel ik zou zeggen kleursensoren, maar als je eens een basissysteem hebt; dan maakt het niet uit wat de lamp gaat sturen. Er zijn heel wat toffe dingen te doen met een RGB CCFL! (ik spreek uit ervaring!)

Ik denk eigenlijk dat als je een mooie resultaat wilt behalen dat hele gemiddelde kleur maar eens op moet rotten (sorry om het zo te zeggen )
Neem bijvoorbeeld een groot ruimteschip in de lucht, ruimteschip rood, lucht blauw.
Omdat ruimteschip dan meer van het beeld vult, zal je "ambilight" dan lelijk rood worden -> wil je niet, want dat is erg in contrast met de randen.

Is het niet handiger om voor elke zijde van je TV een ander "gemiddelde" te berekenen?
Zo zou je voor links een soort gemiddelde van het linkerdeel van het beeld kunnen pakken, en hierbij elke "pixel" met een lagere x ook zwaarder laten tellen int gemiddelde ?

Misschien is het eerst eens tijd dat iemand iets schrijft dat van plaatjes, of misschien al videos, een soort klein videokijkertje maakt dat aan de zijkanten 96 pixels overhoud en hier een ambilight "simulatie" doet ? (als in gewoon een fade kleur)...
Ik zal zo ff kijken naar images of ik leuke algoritmes kan bedenken

Ik denk dat het het makkelijkste en meest haalbare is om eerst eens iets op de PC te doen, dan met MCE, daarna eens kijken naar de lichten, en DAN pas evt een PICtje dat composite signaal gebruikt...
Het heeft geen zin allemaal niet-haalbare dingen te verzinnen, dit zorgt alleen maar voor teleurstelling als het niet lukt...

Bij deze een programmaatje om wat te testen met filmpjes in software:
http://www.madwizard.org/extern/AmbiGL.zip (VS.NET source)

Het is lesson35 van NeHe (AVI's afspelen in openGL) zo snel mogelijk omgezet naar een ambilight-test dus heel ranzig, maar het gaat toch om het testen. Programma zoekt naar c:\test.avi (kun je in code wijzigen), toont dit in het midden van het scherm (pixelig, 256x256 en dan uitgerekt) en een rand met een te bepalen kleur eromheen. In Lesson35.cpp vind je een functie CalcColor, daar retourneer je een RGB struct met de kleur die de rand moet hebben. Daarbinnen heb je een functie ReadPixel(x, y) tot je beschikking, waarmee je pixels uit het huidige frame kunt lezen (x 0..255, y 0.255, ongeacht de resolutie van het filmpje!). Een (waardeloze) voorbeeldfunctie:
C++:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

RGB CalcColor() {     RGB out;     RGB leftTop = ReadPixel(64, 64);     RGB rightTop = ReadPixel(192, 64);     RGB leftBottom = ReadPixel(64, 192);     RGB rightBottom = ReadPixel(192, 193);     RGB center = ReadPixel(128, 128);          int red = leftTop.red + rightTop.red + leftBottom.red + rightBottom.red;     int green = leftTop.green + rightTop.green + leftBottom.green + rightBottom.green;     int blue = leftTop.blue + rightTop.blue + leftBottom.blue + rightBottom.blue;     red += center.red;     green += center.green;     blue += center.blue;     red /= 5;     green /= 5;     blue /= 5;     out.red = red & 0xFF;     out.green = green & 0xFF;     out.blue = blue & 0xFF;     return out; }

Heb niet serieus naar die functie nog gekeken maar daar gaat het dus om. Verzin wat, compileer het en test het. Bij mij pakte ie trouwens niet alle AVIs, zal wel iets met codecs zijn, zoek er gewoon eentje die werkt.

edit: xvid deed het niet bij mij, divx wel maar als toen ik met een hex-editor de avi inlas en aan het begin van de file 'xvid' en 'XVID' in 'divx' en 'DIVX' veranderde werkte het wel.

madwizard wijzigde dit bericht 10-01-2006 20:44 (8%)

Heb ondertussen al wel een leuke functie gemaakt, zie de nieuwe zip:
http://www.madwizard.org/extern/AmbiGL2.zip (source en exe deze keer)

Werkt best al aardig, soms gaan de kleuren een beetje te snel of wisselt ie tussen een paar kleuren maar over het algemeen werkt ie goed. Heb gewoon wat zitten klooien dus waarschijnlijk kan er nog veel aan verbeterd worden. Code is een zootje maar ik zal proberen uit te leggen wat ik gedaan heb:

Ik neem 64 beeldpixels (8 x 8 verspreid over het beeld). Er worden vervolgens 2 dingen bepaald: een aantal kleurensets en of er een scene-verandering is. Scene detectie wordt gedaan door elke pixel uit die 64 te vergelijken met z'n vorige waarde (euclidean distance, pythagoras op rgb zeg maar). Als een bepaald aantal pixels (45) een verschil boven de threshold heeft (10.0) is er blijkbaar een nieuw beeld op het scherm en wordt er een flag (sceneChange) geset.

De kleurensets is eigenlijk een array van kleuren met een aantal erbij. Bij elk frame begin je met een lege set. Voor alle 64 pixels wordt er dan gekeken of er in de kleurenset een kleur staat die redelijk lijkt op die pixel (threshold voor verschil). Zoja dan wordt de count van die kleur in de kleurenset met 1 verhoogd. Zoniet dan wordt de kleur toegevoegd aan de sets met count = 1. Uiteindelijk krijg je dus een soort van 'kleurenset'. Wat ik daar nu mee doe is het gemiddelde berekenen van die set, maar dan gewogen gemiddelde met count³ om de vaak voorkomende kleuren meer gewicht te geven.

Als laatste wordt de kleur bepaald door dat gewogen gemiddelde te nemen, maar voor 95% nog de vorige kleur (0,95 *oud + 0,05 * nieuw), zodat de kleur langzaam overvloeid. Tenzij de sceneChange flag geset is, dan wordt de kleur onmiddelijk omgezet.

Mijn oom heeft een Philips (ik geloof plasma) ambilight scherm. Enorm scherm, en dan bedoel ik ook enorm . Ik heb er eventjes naar gekeken maar het ambilight princiepe sloeg bij mij niet echt aan. Voor mijn gevoel zat er een vertraging in, en ik vond het schakelen eigenlijk alleen maar vervelend ( vooral tijdens een voetbal wedstrijd tussen groen en wit).

Ik kom daar helaas niet echt vaak, maar ik zal hem een mailtje sturen met de vraag of hij een videotje kan maken en opsturen.

http://www.rickard.gunee.com/projects/video/sx/howto.php
wellicht nuttige info
hier prutsen ze kleur video game's in elkaar met PIC's.

staat ook presies uitgelegd over RGB verzenden via pic
dat kan ook andersom dan natuurlijk.

Canule wou gelijk zijn eigen pacman maken toen hij voor het eerst zn PIC in handen kreeg en daarvoor dit gelezen had, maar hij bleek al moeite te hebben met het aansturen van een shift register en wacht tot hij meer skills heeft

Canule wijzigde dit bericht 10-01-2006 23:42 (67%)

had nog een filmpje van ambilight gevonden, misschien is het handig... http://www.philips.nl/abo...-13669/article-14437.html (staat direct onder het verhaaltje)
Als er een tutorial komt hoe je zoiets kan maken door iets aan te sluiten op je scart-out, zou dat echt COOL wezen, dan ga ik zeker zoiets proberen te maken

Shuisman wijzigde dit bericht 10-01-2006 23:38 (22%)

quote:

naftebakje schreef op dinsdag 10 januari 2006 @ 17:59:
[...]

Das allemaal goed en wel, zolang je het niet voor TV-kijken gebruikt. Met de PC kan je idd gemakkelijk een kleurtje berekenen onder windows, en uitsturen via usb. Maar wat als je linux daait, of in dos bezig bent, of met een apple, of je wilt de verlichting aan je televisie hangen?


[...]

Mooi gedaan. Maar wat wat bedoel je met die 4 sensoren? 4 A/D's die sync, R,G,B uitlezen?
Of heb je het over je geluidssensoren?

Hoeveel mensen draaien een mediacenter onder linux of dos? Televisie kun je met een media center gewoon prima kijken met A-R-E. Kwestie van een sateliet kaart, Videobewerkingskaart (voor DVB) of een tvkaart voor reguliere tv.

quote:

Icey schreef op dinsdag 10 januari 2006 @ 22:08:
Mijn oom heeft een Philips (ik geloof plasma) ambilight scherm. Enorm scherm, en dan bedoel ik ook enorm . Ik heb er eventjes naar gekeken maar het ambilight princiepe sloeg bij mij niet echt aan. Voor mijn gevoel zat er een vertraging in, en ik vond het schakelen eigenlijk alleen maar vervelend ( vooral tijdens een voetbal wedstrijd tussen groen en wit).

Er zijn verschillende instellingen om de snelheid en sfeer te bepalen. Maar het is in de praktijk ook niet iets wat je altijd aan wil hebben staan. Vooral bij films is het mooi.

[n00b]
Als je het "bliksem" effect even buiten beschouwing laat is het dan niet eenvoudig om per kleur met een gelijkrichter een condensator te voeden en op die manier een soort gemiddelde waarde te verkrijgen?

Op basis van die gestabiliseerde spanning zou je via een of meer opamps dan toch je rgb led/ccfl kunnen aansturen?
[/n00b]

quote:

Glewellyn schreef op woensdag 11 januari 2006 @ 09:45:
[n00b]
Als je het "bliksem" effect even buiten beschouwing laat is het dan niet eenvoudig om per kleur met een gelijkrichter een condensator te voeden en op die manier een soort gemiddelde waarde te verkrijgen?

Op basis van die gestabiliseerde spanning zou je via een of meer opamps dan toch je rgb led/ccfl kunnen aansturen?
[/n00b]

Zie hierboven, de figuurtjes van Xandrios. Grotendeel van de tijd zal het gemiddelde trouwens een vieze strontkleur zijn...

volgens mij is het sowieso handig om een gradient van de zijkanten naar het midden te gebruiken om de gemiddelde kleur uit te rekenen... anders krijg je van die knoepercontrasten als het midden even hard meetelt zegmaar. Dus dat de randen meer punten in de gemiddelde waarde geven dan het midden. Of, een inverse center-weighted voor de camera-liefhebbers.

Ik heb wat algoritmes bedacht en die in PHP geklopt.

Op deze pagina kan je de resultaten bekijken. Als voorbeeldfiles heb ik de plaatjes van Xandrios gebruikt. Straks zal ik nog wat andere plaatjes zoeken om er ook in te zetten.

Verder heb ik een zip-file gemaakt met de php-sources als iemand geinteresseerd is in de precieze algoritmes.

Even een overzichtje:

1 ) gemiddelde
2 ) gemiddelde, iedere kleur verhoogd met dezelfde waarde, zodat de hoogste 255 wordt.
3 ) gemiddelde, iedere kleur verhoogd met hetzelfde percentage, zodat de hoogste 255 wordt.
4 ) predominante kleur op originele waarde, de rest op 0.
5 ) predominante kleur op originele waarde, de rest gehalveerd
6 ) lineair gewogen gemiddelde, gebaseerd op afstand tot de rand van het scherm*.
7 ) exponentieel (tweede macht) gewogen gemiddelde, gebaseerd op afstand tot de rand van het scherm*.
8 ) exponentieel (derde macht) gewogen gemiddelde, gebaseerd op afstand tot de rand van het scherm*.

* dichterbij weegt zwaarder

edit:
Die pagina dus (linkje vergeten)

Glewellyn wijzigde dit bericht 11-01-2006 16:24 (7%)

Mooi gedaan, maar je moet niet vergeten dat het licht is... grijs is dus niet grijs licht, maar zwak wit. Dat komt in het echt heel anders over. Zwart is niet zwart.

quote:

MeMoRy schreef op woensdag 11 januari 2006 @ 16:24:
Mooi gedaan, maar je moet niet vergeten dat het licht is... grijs is dus niet grijs licht, maar zwak wit. Dat komt in het echt heel anders over. Zwart is niet zwart.

Dat is een duidelijk verhaal, maar daarmee had ik zelf ook al rekening gehouden.

Op deze manier krijg je in ieder geval een redelijk beeld welke resultaten en met een bepaald algoritme behaald kunnen worden. En een algoritme dat regelmatig in lichtsterkte varieert is dus ook niet geschikt voor een ambilight, dat moet namelijk altijd even fel branden om vermoeiing van de ogen tegen te gaan.

Inmiddels heb ik ook drie extra plaatjes geupload, de sample pictures van windows. Deze zijn wel geresized, anders vindt mijn provider het denk ik niet grappig, al die berekeningen.

Glewellyn wijzigde dit bericht 11-01-2006 16:54 (55%)

Ik denk dat je wel een beter id zal krijgen, als je echte plaatjes gebruikt. Volledige waarden voor RGB worden niet gebruikt, het wordt een beetje pastellerig (door beperking van de bandbreedte).

Het ziet er goed uit alleen er worden veel kleuren gebruikt die denk ik met licht moeilijk te realiseren zijn
kijk ook eens naar de verschillen in dit voorbeeld :
http://ambilight.100webcustomers.com/index.php?file=http://www.ndsu.nodak.edu/epscor/images/joan-lab.png

quote:

Koenzie schreef op woensdag 11 januari 2006 @ 16:53:
Het ziet er goed uit alleen er worden veel kleuren gebruikt die denk ik met licht moeilijk te realiseren zijn
kijk ook eens naar de verschillen in dit voorbeeld :
http://ambilight.100webcustomers.com/index.php?file=http://www.ndsu.nodak.edu/epscor/images/joan-lab.png

Ik ben het daarmee helemaal eens, zelf denk ik dat het derde algoritme het meest bruikbare is op dit ogenblik. Het vijde algoritme geeft voor mij de mooiste kleuren, maar ik heb daarin nog geen overwegend gele, cyane of magenta plaatjes geprobeerd.

Goed werk met dat PHP scriptje zeg! Erg netjes

Zelf vind ik de 4e het beste resultaat geven overigens (Alleen de meest aanwezige kleur weergeven). Dat is de enige die in princiepe altijd de kleur gelijkheeft met die op het beeld. De derde is vaak een stuk lichter qua kleur.

Ik vind 2 en 3 het beste, met een voorkeur voor 2, omdat 2 de lichtste (met meest wit) kleuren geeft, en dat zo niet teveel domineert. Al denk ik wel dat met 3 je misschien hetzelfde effect zal hebben eenmaal het met echte lampen gebeurt, die reflecteren op een witte muur.

quote:

Xandrios schreef op woensdag 11 januari 2006 @ 17:12:
Goed werk met dat PHP scriptje zeg! Erg netjes

Zelf vind ik de 4e het beste resultaat geven overigens (Alleen de meest aanwezige kleur weergeven). Dat is de enige die in princiepe altijd de kleur gelijkheeft met die op het beeld. De derde is vaak een stuk lichter qua kleur.

Ik zal je een overtuigend voorbleed geven waarom de 4e erg slecht is:
gold.jpg

offtopic:
Ik ga nu naar huis, ben vanavond weer online, als er nog andere ideeen zijn voor algoritmes hoor ik het wel

Glewellyn wijzigde dit bericht 11-01-2006 17:21 (11%)

ik ga trouwns voor de 3de

quote:

naftebakje schreef op zondag 08 januari 2006 @ 15:30:
[...]

Zo werkt het dus niet. Het beeld wordt intern bewerkt (pixelplus en dergerlijke), dus de beeldinformatie is al beschikbaar. Daaruit halen ze voldoende informatie om een kleur voor Ambilight te kunnen kiezen die past bij het beeld, en door die bewerkingen is er ook een vertraging (zet er een oude beeldbuisTV naast, je zal merken dat de nieuwe met ambilight, pixerplus,... ongeveer een seconde achterloopt).
Door die vertraging kan er ook gekeken worden of er korte intensiteitsflitsen zijn (bliksem), zolang die niet langer dan die ene seconde duren, kan er overeenkomstig geflitst worden (chip ziet veel helderheid, en snel weer weinig helderheid, dus de flits is gedaan nog voor het op het beeld getoond wordt. Dan kan er geflitst worden met de ambilight, omdat die natuurlijk evenveel vertraging als het beeld heeft.
Wordt er binnen de ene vertragingsseconde geen grote verschillen (springen naar andere waarde en weer terug) opgemerkt, dan wordt ambilight geleidelijk aan verschoven (denk ik).

Die vertraging, is dat dan de reden dat ik het beeld op een pixelplus/ander digitaal effect philips-tv er zo nep uit vindt zien? alsof het een home-video is (mist een beetje dat filmgevoel).

Ligt het nou aan mij, of klopt er iets niet ?
als ik het google logo erin wil doen, krijg ik nogal wat devide bij zero foutjes
http://ambilight.100webcu...ntl/nl_nl/images/logo.gif
Iemand ? Of moet je beslist vierkante plaatjes invoeren ofzo ?

quote:

headhunternl schreef op woensdag 11 januari 2006 @ 17:28:
[...]
Die vertraging, is dat dan de reden dat ik het beeld op een pixelplus/ander digitaal effect philips-tv er zo nep uit vindt zien? alsof het een home-video is (mist een beetje dat filmgevoel).

Nee, beeld en geluid worden evenveel vertraagd, je merkt er dus niets van, tenzij je er een CRT naastzet . Hoe het exact komt dat net jou ogen gecombineerd met net jou hersenen die pixelplus en dergerlijke in net die instellingen met net dat basissignaal minder eruit vinden zien, kan ik niet uitleggen. Das een kwestie van smaak, en vele andere factoren. Wel kan je wat instellingen veranderen, of zelfs pixelplus helemaal uitschakelen, als je dat mooier vind. Voor zover ik weet heeft vooral gewone tv over de kabel veel verbetering van die technieken, van een DVD heb je die verbeteringen nauwelijks nodig.

@SHuisman: heb ik ook gemerkt, met grotere plaatjes klopt het ook niet. Ook wordt er geen rekening gehouden met zwarte balken boven/onderaan (wat je in films regelmatig hebt). Het is om ff wat uit te testen, de afwerking is dus (nog) niet nodig.

naftebakje wijzigde dit bericht 11-01-2006 17:47 (12%)