Gathering of Tweakers

Moet volgens mij prima kunnen. Snel zat ook, sneller waarschijnlijk dan je met de meeste PICs kunt lezen. En snelle ADCs kosten nou eenmaal veel geld, 40MHz is niet niks.

Ik heb er trouwens wat onderdelen bij, zoals de eerder genoemde THS10064 ADC, een tripple video buffer (LMH6739) en een YPbPr -> RGBHV converter / 2:1 video switch (LMH1251). En natuurlijk de nodige AVRs. Heb voorlopig alleen andere dingen te doen dus zal wel even duren voordat ik er mee kan werken maar de spullen voor een prototype zijn er in ieder geval.

madwizard wijzigde dit bericht 07-03-2006 00:01 (78%)

Er werd gevraagd of we Ambilight 2 gaan verslaan. Ik zou zeggen van wel. Het kost mischien meer, maar om hoeveel meer praten we hier dan?

Of het beter wordt weet ik niet, die TVs hebben natuurlijk het voordeel dat ze alles digitaal kunnen verwerken, wij zullen het moeten doen met simpelere spullen. Goedkoper denk ik wel, maar hoe vergelijk je dat? Want je kan niet ambilight los kopen ofzoiets. Ik schat dat je met 50 euro voor een zelfbouw iets wel een eind komt, hangt ook een beetje af van de LEDs (of buizen) die je gebruikt.

Ik vraag me alleen af of de twee verschillende kleuren van ambilight 2 een verbetering zijn. Als ik zo naar het bovenste plaatje daar kijk lijkt het me persoonlijk eerder storend. Een kleur lijkt me rustiger, maar goed ik heb het niet werkend gezien. En om te maken moet het niet veel moeilijker zijn dan met 1 lamp.

quote:

madwizard schreef op dinsdag 07 maart 2006 @ 10:33:
Of het beter wordt weet ik niet, die TVs hebben natuurlijk het voordeel dat ze alles digitaal kunnen verwerken, wij zullen het moeten doen met simpelere spullen. Goedkoper denk ik wel, maar hoe vergelijk je dat? Want je kan niet ambilight los kopen ofzoiets. Ik schat dat je met 50 euro voor een zelfbouw iets wel een eind komt, hangt ook een beetje af van de LEDs (of buizen) die je gebruikt.

Vergelijk een Ambilight plasma met een plasma met dezelfde specs, zonder ambilight. Natuurlijk vragen ze voor deze optie Xmaal meer dan bouwprijs, en daarnaast nog een leuk bedrag daarop omdat het zo'n unieke gadget is...

quote:

Ik vraag me alleen af of de twee verschillende kleuren van ambilight 2 een verbetering zijn. Als ik zo naar het bovenste plaatje daar kijk lijkt het me persoonlijk eerder storend. Een kleur lijkt me rustiger, maar goed ik heb het niet werkend gezien. En om te maken moet het niet veel moeilijker zijn dan met 1 lamp.

Daarnaast kan het ook mogelijk zijn dat er dan 2 kleuren worden gegenereerd die verschrikkelijk met elkaar lopen te vloeken denk k.

Zullen we dan met z'n allen voor ambilight 1 gaan?

quote:

eXistenZ_NL schreef op dinsdag 07 maart 2006 @ 23:50:
Zullen we dan met z'n allen voor ambilight 1 gaan?

Dat lijkt me zowiezo een eerste stap, eenmaal dat werkt is Ambilight 2 puur een software issue.

Inderdaad, ik heb wat verder geexperimenteerd met software (op de PC nog dan) en heb al een redelijk idee voor de hardware, maar zoals gezegd zal het nog even moeten wachten.

Ik heb zelf de Philips 42PF9966/10, een 42" plasma scherm met Ambilight. Een aantal dingen vallen me op:

- Hoe dichter een minderheidskleur bij de rand is, hoe meer voorrang deze krijgt op de "algemene" kleur. Dit lijkt op het oog een linear verloop te hebben. Bijvoorbeeld een grote gele bal op een blauwe achtergrond zal (met de bal gecentreerd) een blauwe gloed geven. Zodra de bal richting de zijkant verplaatst zal de intensiteit steeds meer geel worden. De maximale factor waarop de zijkanten invloed hebben op de kleur schat ik op zo'n 75%, d.w.z. de dominerende kleur zal nooit voor 100% overruled worden door een vlak met een afwijkende kleur aan de zijkant.

- Sommige combinatiekleuren mengen veel minder sterk naar een mengkleur dan andere combinaties. Het lijkt erop alsof bij sommige kleurcombinaties een bepaalde kleur voorrang krijgt. Wellicht heeft dit met het algoritme te maken en met complementerende of aanhangende kleuren. Het lijkt erop alsof het algoritme de "vloekende" kleuren eruit probeert te filteren

- Er is geen linear verloop en/of relatie van "algemene" helderheid en ambilight helderheid. Het ene donkere beeld geeft een grotere ambilight intensiteit dan de andere (bij dezelfde ambilight instelling). Dit heeft waarschijnlijk te maken met de beelden direct voorafgaand aan de donkere scene.

- Vlakken met een grote kleurscheiding krijgen voorrang boven vakken met een kleine kleurscheiding. (Veel/weinig onderscheid tussen de onderliggende R-G-B waarden). Als het hele scherm grijs is met een klein blauw vlakje, dan zal ambilight dermate veel blauw produceren dat ik niet de indruk heb dat het een gemiddelde is van alle kleuren van het scherm, maar dat het kleine blauwe vlakje voorrang krijgt op het massale grijze vlak.

Over de lampen zelf, deze zitten achter een plastic melktransparante kap die geribbeld is en een licht bochtje maakt. Het doet me een heel klein beetje denken aan een sterk uitvergroot verticale fresnel lens. Dit hebben ze vast gedaan om het TL licht zo optimaal mogelijk te projecteren op de achterwand. De beste positie is trouwens ook 10-12 cm van de muur volgens de handleiding.

Al met al denk ik dat het algoritme dermate moeilijk is dat dit met analoge techniek (bijna) niet op te lossen is. Natuurlijk kun je gaan voor een simpelere oplossing, maar het effectieve effect zal hoogstwaarschijnlijk minder zijn.

Ik wil de eerste filmpjes wel eens zien van de zelfbouw ambilight van de doorgewinterde tweaker in dit topic

quote:

DexterDee schreef op woensdag 08 maart 2006 @ 16:52:
....

Al met al denk ik dat het algoritme dermate moeilijk is dat dit met analoge techniek (bijna) niet op te lossen is. Natuurlijk kun je gaan voor een simpelere oplossing, maar het effectieve effect zal hoogstwaarschijnlijk minder zijn.

Ik wil de eerste filmpjes wel eens zien van de zelfbouw ambilight van de doorgewinterde tweaker in dit topic

Het algoritme zal digitaal uitgevoerd worden (met een microcontroller), dus we kunnen wel zo'n filtering maken (gezien de verlopen relatief traag zijn, mogen het gerust relatief zware berekeningen zijn). En bedankt voor de info over specifieke gevallen, erg interessant.

Ja analoog had ik meteen al opgegeven. Digitaal zal evengoed wel z'n beperkingen hebben vanwege de hoge snelheid van videobeelden, maar 64 gemiddelden uit elk frame halen moet naar mijn idee lukken, het algoritme wilde ik eigenlijk ook in 1 frame doen, misschien 2. Wel handig inderdaad om te weten hoe ambilight er mee om gaat, al is het soms ook goed gewoon zelf een beetje te proberen omdat dat vaak makkelijker is dan een bestaand iets namaken (ookal gaat het hele topic juist daarover ).

Die trage verlopen, is dat in het echt ook zo dat het ambilight duidelijk een vertraging (~1 seconde) heeft ten opzichte van het beeld? Natuurlijk wel makkelijk om beter de kleur te bepalen maar het lijkt mij irritant dat het licht steeds net even te laat is.

quote:

madwizard schreef op woensdag 08 maart 2006 @ 19:59:...Die trage verlopen, is dat in het echt ook zo dat het ambilight duidelijk een vertraging (~1 seconde) heeft ten opzichte van het beeld? Natuurlijk wel makkelijk om beter de kleur te bepalen maar het lijkt mij irritant dat het licht steeds net even te laat is.

Ik kan met 100% zekerheid bevestigen dat er geen vertraging optreedt bij de reactiesnelheid van ambilight t.o.v. het beeld. De vertraging zit al in de voorbewerking op het beeld, die is zo ongeveer 1 seconde ten opzichte van een analoge TV. De ambilight reageert instant of vrijwel instant (vertraging niet merkbaar) op wijzigingen in het beeld. Het lijkt ook wel alsof het algoritme zo is ingesteld dat de kleurenfade veel sneller gaat als het beeld plosteling van overwegend blauw (bijv. onderwater) naar groen (bijv. voetbalwedstrijd) switcht. Overgangen waarbij het beeld gradueel verandert gaan merkbaar langzamer. Het ligt ook natuurlijk aan de instelling van Ambilight.

Aha dat is handig om te weten. Het algoritme wat ik nu heb werkt ook direct, maar dat betekent ook dat je de kleur alleen aan de hand van het huidige beeld en vorige beelden kunt bepalen. Je hebt niet de luxe het beeld een seconde te cachen zoals de philips TV. Overspringen bij verschillende kleuren is ook vrij eenvoudig, ik had al een simpele sceneverandering-detectie zodat de kleur direct overspringt bij veel verandering. Flitsen en dergelijk werken ook zonder problemen.

Het originele idee van dit topic is veel te moeilijk voor mij.
Daarom ben ik soortgelijk projectje begonnen, volledig in software.

Ik ben begonnen met een directshow filter te schrijven die de gemiddelde RGB waarden berekent.
Deze RGB waarden worden via de seriële poort naar een microprocessor gestuurd die op zijn beurt het PWM sturen van rode, groene en blauwe LED voor zijn rekening neemt.
Voorlopig is het het zuiver rekenkundig gemiddelde. Ik weet wel dat ik er beter een algoritme achtersteek, maar het gaat hier voorlopig om een prototype.
Mijn bedoleing is om dit eerst uit te breiden naar 3 kleuren (links, rechts en boven).
Ik neem aan dat dan het algoritme minder belangrijk wordt.

Het prototype in werking ziet eruit als volgt :

(het vierkant linksonder geeft de gemiddelde kleur weer. Ik gebruik 3 afzonderlijke LEDS voor rood, groen en blauw. Ik geef toe dat ze nog wat beter op mekaar moeten afgesteld worden).

Je kan het prototype ook in werking zien in volgende filmpjes, maar deze zijn van zeer slechte kwaliteit (ze zijn gemaakt met een digitaal fototoestel). Op de achtergrond is er een irritant geluid dus zorg ervoor dat je geluid niet te hard staat

Een RGB kleurentest (1,3Mb) :
http://users.skynet.be/Ra.../MoMoLight/colourtest.mpg

Een film intro (5Mb) :
http://users.skynet.be/RafkeP/tutorials/MoMoLight/movie.mpg

Rafke P.

Heel gaaf Ik zal deze thread eens aan mijn huisgenoot pasen, die heeft deze week toch niets te doen Wordt de source van je directshow filter ook beschikbaar?

BCC wijzigde dit bericht 09-03-2006 21:31 (22%)

Dat is inderdaad een leuk alternatief als je niet alles met hardware wil doen, alleen laat het filmpje niet echt goed zien hoe het werkt, de intro van films zijn niet de beste voorbeelden. Neem bijvoorbeeld een trailer of een stukje film.

quote:

RafkeP schreef op donderdag 09 maart 2006 @ 13:55:
[afbeelding]

Uhm ligt het aan mij of is er iets gigantisch mis met skynet.be? Ik krijg elke keer een andere foto bij dit plaatje sinds een paar minuten, heb ook al mp3s voorbij zien komen en de halve collectie van Julian Beever's straattekeningen (die staan ook op skynet, had ze toevallig in m'n favorieten). Echt heel raar

edit: sorry dat had wel bij m'n vorige post gekund natuurlijk

edit2: Hmm het lijkt weer gefixt ondertussen, dat was raar:
Plaatje op imageshack (popups!)

en hij is weer stuk...

madwizard wijzigde dit bericht 09-03-2006 22:04 (30%)

Je kan toch ook heel simpel een tweede monitor aansluiten (oude CRT 19" bak) en deze softwarematig aansturen? Of is lichtopbrengst van zo'n monitor te laag? (splitter -> 2 19" bakken )

BCC wijzigde dit bericht 10-03-2006 09:22 (14%)

quote:

BCC schreef op vrijdag 10 maart 2006 @ 09:22:
Je kan toch ook heel simpel een tweede monitor aansluiten (oude CRT 19" bak) en deze softwarematig aansturen? Of is lichtopbrengst van zo'n monitor te laag? (splitter -> 2 19" bakken )

Dat lijkt me een vrij dure en lompe manier om een RGB gloed ergens te projecteren . En die 19" schermen zijn zo lastig weg te werken achter een platte monitor/TV

@RafkeP, Zou je misschien de source en het schema online kunnen zetten zodat we hiermee verder kunnen klussen, ik heb namelijk wel intresse in computer gestuurd systeem.

Zou het ook mogelijk zijn om de gemiddelde kleur van de buitenste randen te berekenen?

quote:

madwizard schreef op donderdag 09 maart 2006 @ 21:43:
Uhm ligt het aan mij of is er iets gigantisch mis met skynet.be?
....
en hij is weer stuk...

HAHAHA, lol... vooral die vent met die baard

@ BCC & Mr GAmba : of ik de source beschikbaar ga stellen weet ik nog niet: ik ben namelijk niet zo trots op de troep die ik bij mekaar heb gecodeerd en ik heb zoveel SDKs en dergelijke geïnstalleerd dat ik er zelf niet meer wijs uit geraak hoe ik de filter op een andere PC kan compileren

Zodra ik een iet of wat deftige setup bij mekaar heb, zorg ik er zeker voor dat op zijn minst de binaries online komen met een mooie how-to.
Ik hoop tegen het einde van volgende week de "3-weg" versie in orde te hebben.
Verder wacht ik nog op RGB leds (waarvan ik hoop dat ze beter mengen).

Aangezien het de eerste keer is dat ik met een PIC werk, ben ik vertrokken van William's Site (URL terug te vinden in het moodlight topic van Ferry). Mijn schema is bijgevolg ook identiek aan dat van de RGB led van William. Die site is trouwens een must voor iedereen die met PICs wil beginnen.
Het programma dat in de PIC zit, is een samenraapsel van code die ik links en rechts heb gevonden, aangevuld met wat eigen creativiteit.

@madwizard: ik heb die intro maar genomen omdat hij vrij goed aantoont hoe goed de leds het beeld volgen. Aangezien ik voorlopig het zuiver rekenkundig gemiddelde gebruik, neem ik aan dat tijdens een normale film de leds voornamelijk wit/grijs gaan schijnen. Mijn prototype setup is ondertussen ontmanteld dus ik kan even geen filmpjes meer maken.

Ik heb verder nog klachten gehad van vrienden die ook verkeerde foto's op hun scherm kregen
en die net als ik aangesloten zijn bij Skynet. Ik neem dus aan dat de fout helemaal bij Skynet ligt.

http://www.a-r-e.nl/index.php?page=info

Hmmm?

quote:

Lampie1979 schreef op dinsdag 21 maart 2006 @ 04:16:
http://www.a-r-e.nl/index.php?page=info

Hmmm?

Die werd hier ook al genoemd, was geloof ik rond de 200 euro. Wat vrij veel geld is aangezien het gewoon op software werkt. Als je de handleiding leest zie je zelfs een FTDI usb-serieel driver voorbij komen, en moet je software installeren (overlay werkt niet). Het kastje is dan alleen nog maar een LED driver, eigenlijk wat RafkeP precies zo heeft gemaakt. En ze hebben RJ-45 connectors gebruikt om de LED strips aan te sluiten .

Of het een beetje werkt weet ik niet, er staan wel twee filmpjes maar die zijn beiden van gerenderde of getekende films, wat echt het simpelste is om goed te laten werken.

Wat misschien een makkelijkere manier is, is dit te doen via een FPGA. samen met een video decoder (philips SAA....) kun je heel gemakkelijk video bewerken en dingen uit berekenen. Daar sluit je een AVR-etje op aan, of een softcore voor de liefhebbers. en je hebt ambilight zoals ook philips het doet.

En als je het helemaal goed wil doen, kun je zelfs je video bufferen, maar dan moet je wel een andere tuner gebruiken dan van de TV (VCR of DVR bv.) Dan sluit je het ambilight aan tussen de tuner en de Tv, en buffer je zelf gewoon een deel.

'k denk dat ik binnenkort wel een klein voorbeeldje zal maken (als ik er aan toe kom)