DIY Ambilight howto?

Ambilight 2, instellingen:

- een permanent te selecteren kleur
- de relaxed mode (rustige kleurwisselingen)
- de actie mode (zeer snelle wisselingen)
- de film mode (een beetje er tussenin)
- de lichtintensiteit incl. helemaal aan of uit

Even een kleine vraag tussendoor,
Ik ben erg blij dat mensen alvast op mijn idee van eerst qua programmeren eens wat te testen zijn ingegaan, vooral die Ambilight Colour Calculator met verschillende methodes vind ik erg mooi. Had zelf teveel aan mn hoofd recently...
Echter vrag ik mezelf nu af:
Willen we 1 kleur over de hele rand, willen we net als Ambilight 2 andere kleur links-rechts, of gaan we Ambilight 2 verslaan en voor elke rand van het beeld (4x dus) een andere kleur doen ?
Ik denk eerlijk gezegd dat 4x het mooiste is, maar erg duur. 1x vind ik voor meeste scenes te weinig, en 2x zou net een compromis zijn...

quote:

SHuisman schreef op woensdag 11 januari 2006 @ 17:42:
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 ?

Het probleem is dat je plaatje een .gif bestand is, dat werkt niet. Ik heb het wel geprobeerd in te bouwen, maar het is nog niet gelukt.

Inmiddels geeft de pagina wel een nette foutmelding.

Verder is er geen beperking in de grootte van de bestanden in de scripts, maar de provider heeft een max_execution_time ingesteld en dan blijft een aantal berekeningen achterwege.

Als iemand anders deze scripts kan hosten zodat we ook met grotere plaatjes kunnen testen, graag!

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

Gaaf script, ik heb even gezocht naar kenmerkende plaatjes die je vaak op tv voorbij ziet komen:

explosies:

http://ambilight.100webcu...50px-Nuclear_fireball.jpg

Huidskleur:
http://ambilight.100webcu...elebs/83_cameron_diaz.jpg

TV beeld talkshow

http://ambilight.100webcu...s/debra.messing.oprah.jpg

Ik denk dat je hier het ontwerp op moet realiseren, dit zijn veel voorkomende tv / film fragmenten ( en zo zijn er vast nog 10-tallen meer te bedenken).

Pietjuh wijzigde dit bericht 11-01-2006 20:38 (14%)

Even afgezien van de algorithmen: hoe willen we dit in hardware uitvoeren? Een FPGA/DSP is natuurlijk wel de mooiste manier, die zou meteen composite kunnen ontleden in RGB, maar daar is voor een normale sterveling niet echt aan te komen. We zullen dus zowiezo een aparte composite->RGB-omzettert moeten hebben, of werken met eventueel aanwezige RGB-outputs op een TV. Verder kunnen alle algoritmes in principe wel in analoge electronica uitgevoerd worden, maar in de praktijk is dit bewerkelijk en inflexibel.

Hmmm... Net even gekeken naar de LPC21xx-ARM-controllers van Philips, die zouden het in principe aankunnen: ze kunnen met een snelheid van ongeveer 1MHz A/D-conversies uitvoeren en dat naar het geheugen toedumpen. Het berekenen van de waarde zou dan in de blanking periods van het signaal kunnen. Je zou dan eens per 3 pixels een sample nemen, wat vrij nauwkeurig is.

Een ATMega88 zou het misschien ook nog net kunnen redden: op z'n rapst kan dat ding met 500KHz samplen, dat zou betekenen (met 3 kanalen) dat je eens per 10 pixels een sample kan nemen, waardoor je kleine details misschien meer waarde geeft dan het zou moeten hebben.

Met externe A/D-converters kan dit natuurlijk een stuk sneller, maar dat voegt wel weer extra kosten en moeilijkheid toe aan het verhaal.

Ik zit nog even druk te denken over andere manieren om aan een soort van framegrabber te komen, maar mijn hersenen laten me tot nu toe in de steek...

Als je de invloed van sample rates wil bekijken heb ik een kleine aanpassing gedaan aan het meest populaire algoritme (nummer 3, procentueel gelijke verhoging van de 3 RGB waarden zodat de hoogste waarde 255 krijgt).

Door met de samplerate GET variable te spelen kan je het effect zien van de verschillende sample rates.
1 betekent ieder pixel, 10 betekent het eerste, elfde, eenentwintigste etc. pixel.

Sample rate test

Glewellyn wijzigde dit bericht 11-01-2006 22:28 (4%)

Het zou mooi zijn als je het beeld een beetje kunt middelen over een bepaalde gebied zodat je niet elke pixel (of elke 3, 10) hoeft te samplen maar bijvoorbeeld totaal 100 gemiddelden van het beeld ofzoiets. Horizontaal kan dat misschien nog wel met een condensator of wat analoog spul, maar verticaal is een stuk lastiger omdat dat verspreid is over de beeldlijnen. Dus waarschijnlijk zit je toch wel vast aan het beeld samplen in detail en daarna verwerken. edit: Hoewel als je verticaal zou kunnen middelen in software als je toch maar iets van 10 samples per beeldlijn doet.

madwizard wijzigde dit bericht 11-01-2006 22:41 (13%)

quote:

Sprite_tm schreef op woensdag 11 januari 2006 @ 22:04:
Hmmm... Net even gekeken naar de LPC21xx-ARM-controllers van Philips, die zouden het in principe aankunnen:

Oeh wat evil, een controller van Philips gebruiken
De meeste tv's hebben toch ook wel een scart-out? In een scartaansluiting zit voor R G en B elk een signaal, kun je die niet gebruiken ?
http://nl.wikipedia.org/wiki/SCART
Zowiezo kloppen algoritme 4 en 5 niet echt:
http://ambilight.100webcu...l/sghuisman/load/logo.JPG
Ze worden rood, terwijl het plaatje grotendeels wit is.




@Dajan:
Ik bedoel; de algoritmes kloppen wel, alleen ze geven niet het gewenste resultaat

Shuisman wijzigde dit bericht 11-01-2006 22:47 (28%)

quote:

SHuisman schreef op woensdag 11 januari 2006 @ 22:37:
[...]


Oeh wat evil, een controller van Philips gebruiken
Zowiezo kloppen algoritme 4 en 5 niet echt:
http://ambilight.100webcu...l/sghuisman/load/logo.JPG
Ze worden rood, terwijl het plaatje grotendeels wit is.

offtopic:
raad mijn naam eens...

Het algoritme klopt wel, Het streept namelijk de laagste 2 RGB waardes weg. Wit is RGB in de verhouding 1:1:1 (en telt dus niet echt mee), en schijnbaar zijn de rode letters qua oppervlakte het grootst, dus wordt het rood.

Omdat wit niet meegenomen wordt dus nu al geen geschikte methode.

Jan wijzigde dit bericht 11-01-2006 22:45 (10%)

quote:

SHuisman schreef op woensdag 11 januari 2006 @ 22:37:
[...]


Oeh wat evil, een controller van Philips gebruiken
Zowiezo kloppen algoritme 4 en 5 niet echt:
http://ambilight.100webcu...l/sghuisman/load/logo.JPG
Ze worden rood, terwijl het plaatje grotendeels wit is.

offtopic:
raad mijn naam eens...

Het algoritme klopt wel, maar het resultaat is niet wat we zoeken. In die twee algoritmes ga ik uit van predominant color. En color moet je zien als rood, groen of blauw. Van die 3 is in jouw plaatje rood overheersend, en dus wordt de "ambilight" rood-achtig van kleur.

Zelf heb ik dit al eerder in deze thread aangegeven met als voorbeeld gold.jpg

edit: te laat

edit2: Ik denk wel dat ik pixels naar een "nearest color" kan terugleiden in een kleiner pallet, met daarin de "web-safe" colours. Is zoiets nuttig?

Glewellyn wijzigde dit bericht 11-01-2006 22:51 (11%)

Hmmmmmm... Ik bedenk me net dat een samplerate die zo laag is dat je om de 10 pixels een sample kan nemen helemaal niet erg is: je pakt gewoon de eerste run de 1e, 11e, 21e, ... pixel; de 2e run de 2e, 12e, 22e.... pixel etcetera. Je moet later de uitgangskleur toch enigszins over de tijd middelen (omdat je anders wel hele snelle overgangen krijgt; voor flitsen etc kan je natuurlijk altijd nog 'handmatig' een uitzondering maken) dus elk beeld 100% correct samplen boeit toch niet.

In andere woorden: in principe zou dit met behulp van een atmega88 gedaan kunnen worden

quote:

Sprite_tm schreef op woensdag 11 januari 2006 @ 23:12:
Hmmmmmm... Ik bedenk me net dat een samplerate die zo laag is dat je om de 10 pixels een sample kan nemen helemaal niet erg is: je pakt gewoon de eerste run de 1e, 11e, 21e, ... pixel; de 2e run de 2e, 12e, 22e.... pixel etcetera. Je moet later de uitgangskleur toch enigszins over de tijd middelen (omdat je anders wel hele snelle overgangen krijgt; voor flitsen etc kan je natuurlijk altijd nog 'handmatig' een uitzondering maken) dus elk beeld 100% correct samplen boeit toch niet.

In andere woorden: in principe zou dit met behulp van een atmega88 gedaan kunnen worden

Zo werkt mijn algoritme nog niet, die neemt nu nog vertikale lijnen, maar dar zal ik morgen even fixen.

quote:

DaJaN schreef op woensdag 11 januari 2006 @ 22:44:
[...]


Het algoritme klopt wel, Het streept namelijk de laagste 2 RGB waardes weg. Wit is RGB in de verhouding 1:1:1 (en telt dus niet echt mee), en schijnbaar zijn de rode letters qua oppervlakte het grootst, dus wordt het rood.

Omdat wit niet meegenomen wordt dus nu al geen geschikte methode.

Ben ik de enige die de onderste het mooiste vind?

quote:

Glewellyn schreef op woensdag 11 januari 2006 @ 20:19:
Als iemand anders deze scripts kan hosten zodat we ook met grotere plaatjes kunnen testen, graag!

Ik heb waarschijnlijk wel een servertje waar hij op kan; maar dan wil ik wel de code iets aanpassen: Maximale grootte op 1024x768 (oid), en even heel zeker zijn dat het onmogelijk is om met ?file=/path/blaat geen andere files in te lezen zijn

Als je me morgen even mailt met de laatste versie, dan kan ik bovenstaande fix er nog wel even overheen gooien...dan moet het geen probleem zijn

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, dat komt door de interlacing-mode. Als je deinterlacing niet op blend maar op bob zet in bijv VLC (wel een interlaced bron gebruiken, HD materiaal is daar erg goed voor) heb je exact hetzelfde effect. Progressive scan homevideo-cams hebben er dan ook geen last van. Raar dat ze dat de-interlacing algorithme gebruiken bij pixelplus, maar het is mij ook opgevallen (lang genoeg in de mediamarkt gewerkt ).

quote:

Xandrios schreef op donderdag 12 januari 2006 @ 00:11:
[...]

Ik heb waarschijnlijk wel een servertje waar hij op kan; maar dan wil ik wel de code iets aanpassen: Maximale grootte op 1024x768 (oid), en even heel zeker zijn dat het onmogelijk is om met ?file=/path/blaat geen andere files in te lezen zijn

Als je me morgen even mailt met de laatste versie, dan kan ik bovenstaande fix er nog wel even overheen gooien...dan moet het geen probleem zijn

Ik heb de laatste versie weer op http://www.xs4all.nl/~glew/ambilight.zip gezet.
De aanpassing om de sample rate niet meer verticaal te doen moet ik nog uitwerken, op zich een kleine fix, maar het is even druk op mijn werk. is nu ook klaar.

quote:

Sprite_tm schreef op woensdag 11 januari 2006 @ 23:12:
Hmmmmmm... Ik bedenk me net dat een samplerate die zo laag is dat je om de 10 pixels een sample kan nemen helemaal niet erg is: je pakt gewoon de eerste run de 1e, 11e, 21e, ... pixel; de 2e run de 2e, 12e, 22e.... pixel etcetera. Je moet later de uitgangskleur toch enigszins over de tijd middelen (omdat je anders wel hele snelle overgangen krijgt; voor flitsen etc kan je natuurlijk altijd nog 'handmatig' een uitzondering maken) dus elk beeld 100% correct samplen boeit toch niet.

In andere woorden: in principe zou dit met behulp van een atmega88 gedaan kunnen worden

Is het ook niet te doen een analoog voorschakelingetje te maken, dat het rechter/linker deel van het beeld samplet (en hold). Dit door telkens vlak na de lijnterugslag (blanking) of vlak voor de lijnterugslag te samplen. Dan kan je bijvoorbeeld het gemiddelde van de rechtse/linkse 10% van het beeld op een Ctje zetten. Elk (half)beeld lees je de condensator uit met je µP, die dus maar met 50Hz moet kunnen A/D'en.
Het probleem zit hem dan vooral in het vlak voor de blanking impuls samplen (om de linkerkant van het beeld te nemen), om dat netjes te kunnen synchroniseren moet er nog een (liefst goedkope) oplossing gevonden worden.

Voordelen van deze methode:
-met de voorschakeling kan iedereen zijn eigen toepassing maken (naar eigen godsvrucht en vermogen)
-Enorm flexibel, lage eisen aan de µP
-misschien goedkoper te maken? (wat analoge componentjes kosten niets)
-als je de voorschakeling weglaat, en potmeters zet, kan je dezelfde schakeling als schemerlampje gebruiken
-Als je het goed opbouwt, kan je ook sneller meten, om bijvoorbeeld bovenaan en onderaan een ander kleurtje te bepalen
-...
Nadelen:
-is een goedkoop schematje hiervoor mogelijk?
-neemt alleen de randen van het beeld, dat kan misschien nadelig zijn
-...

ik denk dat het juist goed is als alleen de randen worden gepakt,

bijvoorbeeld het gemiddelde van de linker rand van 50 pixels breed ofzo.
en dan voor links en rechts apart.

(lees overigens al een tijdje mee, maar heb nog nix nuttigs in te brengen gehad IMO

Zelf heb ik geen RGB CCFL's kan iemand uitleggen hoe deze aangestuurd worden? Een spec-sheet zou helemaal fantastisch zijn.

quote:

Extera schreef op donderdag 12 januari 2006 @ 13:46:
ik denk dat het juist goed is als alleen de randen worden gepakt,

bijvoorbeeld het gemiddelde van de linker rand van 50 pixels breed ofzo.
en dan voor links en rechts apart.

(lees overigens al een tijdje mee, maar heb nog nix nuttigs in te brengen gehad IMO

Maar als in de rest van het beeld een heel andere kleur overheerst, dan wordt het toch heel storend.

Als je bijvoorbeeld een shot hebt waarin je door een deur kijkt en de kozijnen van die deur nog net in beeld zijn, zal het beeld die kleur aannemen ipv de kleur van hetgene wat je door die deur ziet...

quote:

Glewellyn schreef op donderdag 12 januari 2006 @ 17:22:
Zelf heb ik geen RGB CCFL's kan iemand uitleggen hoe deze aangestuurd worden? Een spec-sheet zou helemaal fantastisch zijn.

Men neemt 3 CCFL, nen Rooien, nen Blauwen en ne Groentje.
Men verbind de invertors met een IRF530 (dat heb ik toch gedaan, misschien is een ULN2003 al goed genoeg, ik zal dat nog uitmeten).
De IRF'en verbind je met een PIC microcontroller waar je 3 softwarematige PWM uitgangen programmeert.
Voila!, dat is wat je nodig hebt!!!

quote:

Extera schreef op donderdag 12 januari 2006 @ 13:46:
ik denk dat het juist goed is als alleen de randen worden gepakt,

bijvoorbeeld het gemiddelde van de linker rand van 50 pixels breed ofzo.
en dan voor links en rechts apart.

Volgens mij is de kleur die het meeste voorkomt een belangrijkere factor dan de randen. Als je een groen grasveld hebt met aan de randen publiek is het volgens mij mooier om gewoon groen te hebben als licht, en zo zijn er wel meer voorbeelden.

Ik heb mijn programma wat gewijzigd zodat ie donkere kleuren minder laat meetellen, dat scheelt ook wel. Als je bijvoorbeeld in een donkere auto zit met lichte ramen (gefilmd van de binnenkant) wil je liever de kleur van buiten (door de ramen) dan het donker van de auto.

Maar analoog voorbewerken is volgens mij wel een goed idee, zoals ik al zei zou je dat kunnen gebruiken om horizontaal te middelen zodat je minder samples hoeft te nemen. Toch moet je dan nog voor de verticale lijnen wel elke lijn een sample nemen omdat je die niet even met een condensator kunt afvlakken. Maar met bijvoorbeeld 10 samples per lijn is dat te doen. Je zou ook het berekenen kunnen scheiden van het samplen zodat je tijdens het samplen van 1 beeld de kleur van het vorige beeld berekend. Omdat je standaard toch 2 frames per beeld hebt (interlacing van PAL, 5 halve beelden per seconde) merk je daar als het goed is geen vertraging in (en het is maar 1/50e seconde ook). Als het samplen weinig tijd kost zou je het als interrupt kunnen doen, en anders in een 2e microcontroller. Dan heb je 1/50e seconde om de kleur te bepalen, wat best lang is voor een microcontroller.

Ik zat trouwens ook nog te denken dat je misschien een neuraal netwerk zou kunnen gebruiken om de kleur te bepalen. Die zou je kunnen trainen met een zooi beelden + gewenste kleur. Voordeel daarvan is dat je niet echt een algoritme hoeft te bedenken, je leert het netwerk gewoon het gewenst effect. Nadeel is dat het flink wat berekeningen kost, maar ik denk dat het nog wel te doen is als je bijvoorbeeld 64 samples hebt en een netwerk van een paar lagen. De mega AVRs hebben een hardware 8-bit multiplier van 2 clockcycles dus die kunnen best wat berekenen. En de uitkomst van een gedefinieerd netwerk is niet heel lastig uit te rekenen, als je wat exponentiele functies vereenvoudigt. Trainen hoeft niet in de micocontroller natuurlijk.

Als ik tijd heb zal ik eens gaan klooien met zo'n netwerk, kijken of dat een beetje een goed effect geeft en of de uiteindelijke kleurbepaling met een NN haalbaar is in een microcontroller.

edit: Hmm nadeel van een NN (een feed-forward neural network dan) is wel dat je enorm veel geheugen nodig hebt, misschien is een Self Organizing Map beter, daar kun je ook leuke dingen mee doen voor kleuren: http://davis.wpi.edu/~matt/courses/soms/

madwizard wijzigde dit bericht 12-01-2006 19:59 (5%)

quote:

Glewellyn schreef op donderdag 12 januari 2006 @ 13:13:
[...]


Ik heb de laatste versie weer op http://www.xs4all.nl/~glew/ambilight.zip gezet.
De aanpassing om de sample rate niet meer verticaal te doen moet ik nog uitwerken, op zich een kleine fix, maar het is even druk op mijn werk. is nu ook klaar.

http://ambilight.xandrios.net/ (Max 1280 * 1024 pix). Die machine serveert verder alleen wat downloads, dus kan wel een stootje hebben qua load

---

We hebben het hier overigens over microcontrollers. Opzich een goed idee, zo te zien zijn die nog relatief simpel aan te sturen (Niet al te veel extra electronica nodig).
Maar ookwel belangrijk, wat kost zoiets? Is dat in de range van enkele euros tot enkele tientjes, of enkele tientjes tot enkele honderden euro's?

Xandrios wijzigde dit bericht 12-01-2006 21:31 (36%)

quote:

Xandrios schreef op donderdag 12 januari 2006 @ 21:28:
[...]


http://ambilight.xandrios.net/ (Max 1280 * 1024 pix). Die machine serveert verder alleen wat downloads, dus kan wel een stootje hebben qua load

Je hebt de code dus nog iets aangepast? In mijn code kon hij maximaal 1280*800 aan, de resolutie van mijn laptop's tft...

Oh en over die processoren, SpriteTM heeft had een inkoopactie lopen: inkoopactie

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

quote:

Xandrios schreef op donderdag 12 januari 2006 @ 21:28:
[...]


http://ambilight.xandrios.net/ (Max 1280 * 1024 pix). Die machine serveert verder alleen wat downloads, dus kan wel een stootje hebben qua load

<hr>
We hebben het hier overigens over microcontrollers. Opzich een goed idee, zo te zien zijn die nog relatief simpel aan te sturen (Niet al te veel extra electronica nodig).
Maar ookwel belangrijk, wat kost zoiets? Is dat in de range van enkele euros tot enkele tientjes, of enkele tientjes tot enkele honderden euro's?

Is het niet makkelijk die standaard voorbeelden gewoon static te maken? Beetje zonde nu?

Zit ik heel erg verkeerd als ik (afhankelijk van de exacte specs en benodigdheden) zo rond de 30 á 40 euro denk?

Clock wijzigde dit bericht 12-01-2006 21:42 (9%)