DIY Ambilight howto?

[DarthPlastic]

Ik kom dit topic net tegen en moet zeggen dat het een heel mooi idee is!

Een tijdje geleden ben ik op bezoek geweest bij Philips ivm een profielwerkstuk over TL-verlichting.
Het blijkt dat in de grote LCD/Plasma-TV's van Philips ook met TLs wordt gewerkt.

Het AmbiLight systeem bestaat uit een controller die het beeldsignaal 'analyseert' welke kleur er dominant is (moeilijk uit te leggen, maar over werking hiervan werd niet veel over verteld ivm patenten),
deze stuurt de kleurniveaus van het rood/groen/blauw door naar een PWM-controller, die mini-TL-buizen aanstuurt.
Hierin zit een vertraging van (ruw geschat ) 1 seconde, voor een rustige overgang.
Van het 'knippereffect' bij PWM zie je niets ivm de gebruikte soort TL

De buizen zijn meestal aangebracht aan de linker-en rechterzijde van de TV, achter een soort matglas, en het gaat hierbij om de TL5-buis van 36W (of bij de grotere de 54W uitvoering).
Met LEDs zou het ook wel kunnen, maar bij Philips is dit niet gekozen aangezien je dan hele balken met LEDs nodig zou hebben, en een TL dus rustiger licht geeft.
Hele hordes LEDs zouden ook duurder zijn dan een TL-balkje per kleur

Hoe dan ook, ik zal het topic even blijven volgen.
Als iemand nog typenummers etc van de buizen nodig heeft hoor ik het wel (heb daar zelf TL5 gegoten, heb alle onderdelen ervoor)

Su6!

edit @naftebakje hierboven: Het 'vertragen' van de overgang gaat idd precies zo! Om dit van een normale tv af te halen wordt lastig, maar als je een schakeling kan maken die dit doet, en de gemiddelde RGB kleurniveaus doorstuurt naar een PWM-controller, heb je Philips' uitvinding nagebouwd

[ Voor 11% gewijzigd door DarthPlastic op 08-01-2006 15:36 ]

[naftebakje]

Yeehaa, ik heb goed gegokt, het is inderdaad 1 seconde vertraging . Ik ben zelf ook in Philips Brugge (Belgie) geweest, toen hadden ze net een prototype met werkende ambilight, en wilden ze er helemaal niets over vertellen (je kon er ook niet zoveel van zien omdat die tv niet tegen een muur stond in het labo, dan verlies je het hele concept).

Het probleem om dit te maken is dus het volgende: hoe vertraag je het beeld / geluid 1 seconde, op een betaalbare manier? Iemand een id?
(je kan natuurlijk enkele 1000den opampjes, als spanningsvolger geschakeld, na elkaar plaatsen, maar dat is niet echt te doen vrees ik.)

_{Bij PWM aansturing merk je geen knippering in verlichting door de hoge frequentie van de PWM, de soort TL doet er niet toe (moet wel geschikt zijn voor dimmen ivm levensduur) Een standaard witte TL aan het plafond werkt trouwens het best aangestuurd met 600V met een frequentie van 600Hz, das wat ze in de moderne electronische ballasten gebruiken (geen starter meer nodig, lamp licht direct op, veel zuiniger en een beter cosinus phi). Op die 600Hz kan je PWM gaan toepassen, dan zie je zeker helemaal geen flikkering meer (itt de oude ballasten met starters, die 50 Hz kan je net merken).}

[ Voor 34% gewijzigd door naftebakje op 08-01-2006 15:58 ]

[DarthPlastic]

Had ik dus ook, ze hadden wel tv's staan maar ze wilden eigenlijk niets vertellen snap ik ook wel, maar toch...Omdat ik voor onderzoek met TL-buizen daar was kreeg ik uiteindelijk wel zo'n ding 'open' te zien, en werd me uitgelegd hoe het werkte. (Philips Lighting Eindhoven)

Het beste om zoiets aan te pakken is toch met een PIC (heb ik dat goed?), die een programma draait om de videosignalen uit te lezen, kijkt hoeveel % van alle pixels bv rood zijn, en die uitgangswaarde in de vorm van een PWM signaal afgeeft.
Daarna zou je met enkele sterke transistors in de moderne elektro-ballasten de TL-buizen hun licht kunnen geven.

Maar wat is eigenlijk de bedoeling van de kleuren? Moet er echt één enkele kleur uitkomen, of moet het gewoon een 'vage weerspiegeling' van het beeld zijn (zoals het effect van een tv omgedraaid tegen de muur zetten)

Ik heb die demo-ballast van mij ook eens nagekeken, en er zit een PWM-ingang op, dus je zou die zonder extra onderdelen op een PIC kunnen aansluiten.
Een programma om een PIC zulke informatie te laten uitlezen zou ik echter niet helemaal kunnen bedenken, ik weet wel hoe het globaal zou moeten werken, en wat je met zo'n ding kan doen, maar niet hoe je dingen 'uit' het videosignaal uitleest.

Was het eigenlijk niet zo dat je vroeger BNC-ingangen op je monitor had, met 1 aansluiting per kleur? Zoiets zo denkik wel geschikt zijn, als je de spanning van zo'n uitgang meette (mat?) dan was die gemiddelde waarde die je zag om te zetten naar hoe veel die kleur in beeld is.

We kunnen altijd nog Philips bellen hoe ze dit gedaan hebben

[Xandrios]

Simpelweg een vertraging inbouwen kan gemakkelijk dmv condensatoren op de kleur-lijnen. Die 'cachen' dan de kleur voor enkele (mili?) seconden, waardoor een vloeiende overloop ontstaat. Nadeel is dus dat je bij een bliksemflits geen 'flits' kunt genereren.

Dat is overigens sowieso een lastig punt: De een zegt dat dat wel werkt bij het originele ambilight systeem, de ander zegt dat dat niet gebeurd om de 'rust' te behouden. Iemand die zo'n ding in het echt werkende heeft gezien / in huis heeft?

Het 'simpele' idee om van het RGB (rood, groen, blauw) signaal de gemiddelde waarde te nemen zal niet het best werkende zijn, het liefst wil je een goede analyse van het beeld. Maar stel, enkele voorbeeldjes:

Beeld op TV	Kleur lamp

De uiteindelijke kleur komt wel redelijk in de buurt van de meest aanwezige kleur op het beeld. Probleem zal zijn dat je op TV nooit kleuren van deze sterkte en hoeveelheid zal hebben....ik gok dat het inderdaad een stuk minder zal zijn 'in het echt'.

Groot probleem van met een microcontroller werken, is (naast de hoge kosten en _veel_ werk) dat het niet gemakkelijk zal zijn daar software voor te schrijven. Rood is niet altijd rood namelijk...als in: Een grote rode auto op je scherm, zijn mischien wel duizend verschillende kleuren rood. Hoe gaat je programma daar 'rood' in herkennen?

[naftebakje]

Die aansluitingen bestaan nog steeds, het is eigenlijk een erg goeie versie van de oude VGA poort, de horizontale en verticale synchronisatie en de RGB signalen worden apart via een coax-kabeltje verzonden. Dat wordt echter niet gebruikt voor TV's, want je hebt dan een aparte tuner nodig.

Met een PIC kan je idd (via een ingebouwde A/D) de waarden uitlezen, en dan 3 PWM uitgangen maken, das allemaal nog niet zo moeilijk (ik wil gerust een progje maken, na mijn examens, 27 januari heb ik tijd om wat te experimenteren). Het probleem is dat je de RGB signalen moet hebben, dus als je dit voor TV wilt doen moet je eigenlijk 3/4 van een TV maken, ofwel binnenin gaan aftakken op de RGB lijnen. Maar die vertraging heb je dan niet, meer dan een light Ambilight versie kan je niet maken.

Als je met een computerscherm met VGA werkt ben je gemakkelijker, daar kan je aftakken op de eigenlijke signaallijnen, die kloppen denk ik meer met het eigenlijke beeld, want bij een TV moet je eigenlijk rekening houden met de synchronisatie en meetsignalen die meeverzonden worden in de RGB signalen (High en lowlightparameters, ultrazwart en superultrazwart, superzandkasteelimpuls, al die shit zit in meer en mindere mate op het signaal in een TV, en het signaal moet dan ook nog op het juiste DC niveau gebracht worden, tenzij je op de exact juiste plaatsen kan aftakken).

@ Xandrios: das idd het probleem. Om goed te zijn, moet je eigenlijk elk beeld apart gaan bekijken, en het grootste vlak met ongeveer gelijke kleur als hoofdkleur gebruiken. Die vertraging die je zegt, die heb je zowiezo, omdat je moet aan het rekenen gaan met je signalen, de vertraging waar ik het probleem in zie, is die van het beeld dat weergegeven wordt, de Ambilight zal achterlopen op het beeld, en das eigenlijk niet ideaal. Dus moet het beeld zelf vertraagd worden.

@hieronder: 4 CCFL's die samen zitten in een ronde buis, wit, rood groen blauw lijkt me.

[ Voor 19% gewijzigd door naftebakje op 08-01-2006 17:20 ]

[DarthPlastic]

Hier staat een beetje het effect van Ambilight afgebeeld:




Zo zit de TL gemonteerd:

(dus toch een TL5 mini 36W)
Wel lijkt het dat er maar één TL in zit, die dus verschillende kleuren kan weergeven.
Dit is echter onmogelijk (poeder 'verf' aan de binnenkant v buis bepaalt de kleur), dus er moet iets anders achter zitten...
Misschien is de voorste wit, en zitten er extra buizen binnenin...

[ Voor 2% gewijzigd door DarthPlastic op 08-01-2006 17:20 . Reden: oeps... grote foto's.. en een sessie-id, dus ze zullen misschien verlopen... iemand idee waar ik ze kan uploaden? ]

[ken536]

Ik ga is proberen een PICtje te programmeren.

Wie kan me even helpen met de weerstandjes?
Ik wil gewoon van elke RGB kanaal direct aan de PIC hangen, maar wel met goede weerstanden
En waar kan ik de rgb kanalen vanaf halen?

Van een scart kabel ofwat?

En kan de grond van elke kanaal gewoon aan elkaar worden geknoopt?

[Xandrios]

naftebakje schreef op zondag 08 januari 2006 @ 17:13:
Het probleem is dat je de RGB signalen moet hebben, dus als je dit voor TV wilt doen moet je eigenlijk 3/4 van een TV maken, ofwel binnenin gaan aftakken op de RGB lijnen.

Dat is het mooie: Elke TV geeft de RGB signalen op de SCART-poort gewoon weer. Je kunt die info dus direct van de scrart-poort 'pakken'

DarthPlastic schreef op zondag 08 januari 2006 @ 17:17:

Misschien is de voorste wit, en zitten er extra buizen binnenin...

Ik denk dat het 1 (melkwit) glazen buis is, waar drie afzonderlijke TL lampjes in zitten?

ken536 schreef op zondag 08 januari 2006 @ 17:53:
Ik ga is proberen een PICtje te programmeren.

Wie kan me even helpen met de weerstandjes?
Ik wil gewoon van elke RGB kanaal direct aan de PIC hangen, maar wel met goede weerstanden
En waar kan ik de rgb kanalen vanaf halen?

Van een scart kabel ofwat?

En kan de grond van elke kanaal gewoon aan elkaar worden geknoopt?

Mischien dat dit verduidelijking kan brengen:
http://utopia.knoware.nl/...on/Engineering/SCART.html

[ Voor 29% gewijzigd door Xandrios op 08-01-2006 18:23 ]

[ken536]

Xandrios schreef op zondag 08 januari 2006 @ 18:22:

Mischien dat dit verduidelijking kan brengen:
http://utopia.knoware.nl/...on/Engineering/SCART.html

Kijk aan..

Ik denk dat de return de grond is.
Kunnen die aan elkaar gehangen worden?

En hoe weet een tv, dat ie klaar is met zenden met het beeld op dat moment?

[naftebakje]

@ken536: returns zijn massa idd, mogen in principe gewoon aan elkaar. Ik begrijp niet helemaal wat je bedoelt met klaar zijn van zenden beeld, maar kijk eens naar synchronisatiesignalen (blanking zit op die RGB lijnen, mss wordt de superzandkasteelimpuls op sync gezet ofzo, google zal je vriendelijk te woord staan).

Xandrios' linkje: (ben je er trouwens zeker van dat die signalen er altijd op staan?)

code:

Signal         |      AC level                   | DC level | Impedance
Red, green, blue | Peak to blanking: 0...0.7 V ±3 dB |  0...2 V | 75 Ohm

Je moet dus bufferen (zodat je nog wat signaal overlaat voor de TV), en je buffer moet een ingangsimpedantie van 75 Ohm hebben. Met 0 tot 0.7V ben je niet zoveel, best kan je dit meteen wat versterken naar 0 tot ongeveer 5V.

Schema (snel in elkaar geflanst): gebruik het basisschema van een inverterende versterker:

Aan Vin komt het signaal (R,G,B), aan Vout heb je het inverse van het signaal (inverterende versterker). De versterking wordt bepaald door de verhouding van de weersanden, Rf/Ri, terwijl de ingangsimpedantie gelijk is aan Ri, neem dus beide weerstanden 75 ohm.
Nu zit je nog wel met een geinverteerd signaal, plaats daarna nog eens hetzelfde schema, maar nu met de weerstandswaarden zo gekozen dat je de gewenste versterking hebt (om van 0 .. 0.7V naar 0 ... 5V te gaan), nu kan je de weerstanden in de orde van 10tallen kiloOhms nemen (standaard bij opamps), bijvoorbeeld 1K en 6.8K.

[ Voor 56% gewijzigd door naftebakje op 08-01-2006 20:09 ]

[HunterPro]

Xandrios schreef op zondag 08 januari 2006 @ 16:38:
Simpelweg een vertraging inbouwen kan gemakkelijk dmv condensatoren op de kleur-lijnen. Die 'cachen' dan de kleur voor enkele (mili?) seconden, waardoor een vloeiende overloop ontstaat. Nadeel is dus dat je bij een bliksemflits geen 'flits' kunt genereren.

Dat is overigens sowieso een lastig punt: De een zegt dat dat wel werkt bij het originele ambilight systeem, de ander zegt dat dat niet gebeurd om de 'rust' te behouden. Iemand die zo'n ding in het echt werkende heeft gezien / in huis heeft?

Het 'simpele' idee om van het RGB (rood, groen, blauw) signaal de gemiddelde waarde te nemen zal niet het best werkende zijn, het liefst wil je een goede analyse van het beeld. Maar stel, enkele voorbeeldjes:

Beeld op TV	Kleur lamp
[afbeelding]	[afbeelding]
[afbeelding]	[afbeelding]
[afbeelding]	[afbeelding]

De uiteindelijke kleur komt wel redelijk in de buurt van de meest aanwezige kleur op het beeld. Probleem zal zijn dat je op TV nooit kleuren van deze sterkte en hoeveelheid zal hebben....ik gok dat het inderdaad een stuk minder zal zijn 'in het echt'.

Groot probleem van met een microcontroller werken, is (naast de hoge kosten en _veel_ werk) dat het niet gemakkelijk zal zijn daar software voor te schrijven. Rood is niet altijd rood namelijk...als in: Een grote rode auto op je scherm, zijn mischien wel duizend verschillende kleuren rood. Hoe gaat je programma daar 'rood' in herkennen?

ik denk dat het meer dit moet zijn:

uit:

beeld 1:

beeld 2:

beeld 3:

[Verwijderd]

Mijn ouders hebben sinds een week zo'n philips tv ,en ik moet zeggen dat het inderdaad een leuk concept is. Mag hem alleen helaas niet open maken van ze (spelbrekers )

De onze heeft verschillende modes voor ambilight ,zo kun je hem op omgeving zetten ,op rustig ,en actie enzovoorts. Waarschijnlijk dat dit met de eerder genoemde reactietijd te maken heeft. Ook een echte philips (in omgevingsstand) reageerd laat op het bliksemflits effect viel mij op. Hier zit zoals eerder gezegt ongeveer een seconde vertraging in. Het lijkt dan als de flits komt wel alsof ie afgezwakt is ,dus misschien is het een verstoptruukje ofzoiets. De omgevingsstand heeft ongeveer het gedrag dat jullie hier zeggen. Het lijkt dat hij de kleur pakt met de hoogste waarde uit blauw groen en rood ,en daar wat mee doet waardoor een subkleur komt. Even voor de duidelijkheid bij Ambilight komt er aan alle kanten van de tv dezelfde kleur uit. Ik heb hieronder nog een toevoeging gedaan waar wat staat over ambilight 2 ,daarbij heb je onderscheid tussen rechts en links. Het voorstel van Hunterpro is dus bij de echte ambilight niet het geval. (zou wel mooi zijn overigens maar kost een fortuin) Als jullie wat willen weten van het gedrag van de ambilight van philips wil ik wel even kijken ,dit is namelijk een topinitiatief

Edit 9 januari:
Nog even gezocht en ik vond het volgende stukje over ambilight 2 (er is dus al een opvolger zelfs ). Het grootste verschil is volgens mij dat bij deze de lampen voor links en rechts apart zijn aan te sturen. Bij de gewone ambilight is dit niet zo. Even een quote van een gegoogled stukje tekst:

Ambilight 2 is the second key feature in Philips's PF9830 series, and the second generation of this backlight technology. Ambilight 2 provides a "two-channel facility which independantly projects colours from the left and the right of the screen, allowing the colour and intensity to more accurately match on-screen content." Ambilight 2 comes with four, instead of two, viewing modes (dynamic, relaxed, action and ambiance). Ambilight can be left on even when the TV is off in order to "create a unique ambiance in a room."

bron

Jammer dat ik weinig van elektronica weet. Ik zie dit idee echt wel zitten voor achter mijn tftje

[ Voor 46% gewijzigd door Verwijderd op 09-01-2006 17:00 ]

[naftebakje]

Ok remczero, dit is interessant. Ik dacht dat ze ervoor zorgden dat die Ambilight en het beeld gelijk lopen, maar blijkbaar is dit niet zo (en dat leek me ook het moeilijkste).
Zou het kunnen dat het grootste helderste oppervlak de ambilight verlichting bepaalt? Of gewoon het grootste oppervlak?

De mogelijkheden naar detectie (en dus uitkiezen van Ambilight-kleur) toe zijn volgens mij:
-helderste oppervlakken (piekdetectie op RGB signalen)
-grootste oppervlakken (soort tabbelletje maken, 100 onderverdelingen ofzo, voor elke tint van RGB. Telkens die tint passeert, eentje bijvoegen in de tabel. En dan de grootste waarde gebruiken)
-rechter/linkerkant (na elke lijn moet er normaal een blanking zijn, die telkens detecteren, vlak na de blanking heb je links, ervoor zit je rechts)
-Algemeen gemiddelde (C'tje vullen)
-Combinaties (75% grootste oppervlakte + 25% algemeen gemiddelde)
-Als je een krachtige (dure) µC gebruikt: per beeld kijken, en een beeldbewerking erover gooien (lijkt me niet echt haalbaar)
-...
Wie dit lijstje verder kan aanvullen, met dingen die in een betaalbaare µP haalbaar zijn, post gerust. Ik denk trouwens dat "kleur grootste oppervlak" bepaalt "kleur achtergrondverlichting" het beste is, maar wat met 2 even grote vlakken in totaal andere kleuren?

@ HunterPro: dat zou het ideale zijn, maar zelfs in massaproductie is dit te duur. Ambilight nu gebruikt 1 kleur, rechts en links van de TV. Xandrios toont met zijn figuurtjes het probleem dat je hebt als je gewoon het gemiddelde van het volledig beeld neemt, het moet iets slimmer (maar niet te slim zoals jou voorstel, want dat is niet te betalen).

[ Voor 21% gewijzigd door naftebakje op 09-01-2006 01:24 ]

[ken536]

Ik heb even een simpele site opgezet: http://www.project11.nl/ambilight/

Hier is de eerste versie van mijn code te bekijken (nog niet getest)

Aanvullingen en opmerking natuurlijk altijd welkom.

Hij gaat nog uitgebreider worden

[naftebakje]

ken536 schreef op maandag 09 januari 2006 @ 20:58:
Ik heb even een simpele site opgezet: http://www.project11.nl/ambilight/

Hier is de eerste versie van mijn code te bekijken (nog niet getest)

Aanvullingen en opmerking natuurlijk altijd welkom.

Hij gaat nog uitgebreider worden

Dat gemiddelde nemen van 10 punten is wel goed gevonden, maar heeft als nadeel dat je helemaal niet weet waar je eigenlijk de punten meet. Als je toevallig 5 van de 10 keer meet tijdens de blanking, meet je maar de helft van de eigenlijke waarde (erg onwaarschijnlijk, i know). Dit is ook afhankelijk van de snelheid van de meting, heb je enig id om de hoeveel tijd de metingen gebeuren?

Als je dat gemiddelde van 10 punten voor RGB nu eens zou gebruiken om rechtstreeks de LED's (duty-cycle van PWM) aan te sturen, dan kan je beter zien of je meting een geschikte waarde geeft of niet.

En nog een laatste punt: om de kleurovergangen geleidelijker te maken, kan je volgens mij best je gemiddelde waarde steeds terugkoppelen. Dus 80% rekening houden met de vorige gemiddelde waarde, en 20% met de nieuwe gemeten waarde.

[ Voor 23% gewijzigd door naftebakje op 09-01-2006 22:49 ]

[madwizard]

Om de metingen op vaste punten te doen moet je ze synchroniseren met het sync signaal. In een SCART aansluiting zit dat volgens mij allemaal samen met het composite signaal, maar met een LM1881 ICtje kun je die eruithalen.

[Exirion]

Met analoge schakelingetjes zul je Ambilight nooit echt kunnen benaderen omdat het grotendeels gebaseerd is op de digitale beeldverwerking die in hedendaagse TV's zit. De algoritmen die gebruikt worden vallen onder intellectual property en zullen niet bekend gemaakt worden. Vast staat wel dat een digitale analyse van het beeld, en daaruit afgeleide aansturing van de TLs, essentieel is om het effect goed na te bootsen.

[Verwijderd]

2 witte lampen
3 rode
3 blauwe
3 gele

dit zit erin volgens mij
of 2 wiite tl's
2 buisjes die verschillende kleuren kunnen weergeven en ook gemixt.
vriendin van mijn moder had er 1 thuis staan dus heb hem eens goed bekeken

[ken536]

Verwijderd schreef op dinsdag 10 januari 2006 @ 10:09:
2 witte lampen
3 rode
3 blauwe
3 gele

dit zit erin volgens mij
of 2 wiite tl's
2 buisjes die verschillende kleuren kunnen weergeven en ook gemixt.
vriendin van mijn moder had er 1 thuis staan dus heb hem eens goed bekeken

Geel gebruik je alleen bij verf. Bij licht is het groen

[naftebakje]

madwizard schreef op dinsdag 10 januari 2006 @ 00:31:
Om de metingen op vaste punten te doen moet je ze synchroniseren met het sync signaal. In een SCART aansluiting zit dat volgens mij allemaal samen met het composite signaal, maar met een LM1881 ICtje kun je die eruithalen.

Is die syncronisatie op SCART geschikt? Ik had ook al gedacht aan een 1881, maar ik vind geen info over hoe de sync in scart opgebouwd is.
Nog even ter info (voor wie het niet weet, zij die het wel kennen, gelieve dit na te lezen/aan te vullen als er fouten/tekorten inzitten):
Op het eerste blad in die datasheet zie je onder het chipje enkele lijnen, dat zijn de beeldsignalen (composite video input). Die rare krul in het begin stelt een beeldlijn voor, de hoogte ervan bepaalt de helderheid (kleur wordt daarin gestoken door een wisselstroompje op die varierende "helderheids"spanning te steken, niets van aantrekken). Die piekjes naar beneden, die dan op het einde piekjes naar boven worden, zijn "blanking"impulsen, die zeggen dat de lijn gedaan is (en de volgende begint). Eigenlijk hebben al die lange stukken, tussen de blankingsignalen, een kromme lijn die de helderheid voorstelt, maar dat zetten ze er niet op (teveel werk ).
Die odd/even is omdat ze geinterlineeerd werken, eerst worden de oneven, en dan de even lijnen "getekend" op het scherm. Dus telkens de helft van het beeld.
Met die even/oneven (odd/even) moet je geen rekening houden, want (volgens mij) worden de RGBsignalen die hier al voor gecompenseerd zijn op de SCART gezet (als ze op de scart worden gezet, wat ik niet zeker ben). Die RGB signalen hebben ook die piekjes naar beneden (de blanking), eigenlijk kan je dan meten vlak na de blanking (links deel van beeld), of vlak voor de blanking (rechts deel).

[madwizard]

naftebakje schreef op dinsdag 10 januari 2006 @ 14:24:
Is die syncronisatie op SCART geschikt? Ik had ook al gedacht aan een 1881, maar ik vind geen info over hoe de sync in scart opgebouwd is.

Voor zover ik weet zit er ook composite video in SCART (je hebt van die convertor plugs van SCART naar composite+audio), daar zit een sync signaal in (en video uiteraard). Je hebt ook zoiets als sync-on-green, dus het sync met het groene signaal mee maar volgens mij is dat meer voor losse componenten-video (3 stekkertjes) dan voor SCART. Maar goed zeker weet ik het allemaal niet, als je een scope hebt zou je het eens kunnen bekijken. De 1881 werkt vast wel. Hsync kun je er ook uithalen trouwens, door een bepaalde bewerking op de verschillende uitgangen van die 1881 (staat hier), kan ook in software.

Anders kun je het ook met VGA proberen, daar zitten volgens mij de sync signalen apart (H en V) en zonder verdere videosignalen.

[mabarto]

Xandrios schreef op zondag 08 januari 2006 @ 16:38:
Dat is overigens sowieso een lastig punt: De een zegt dat dat wel werkt bij het originele ambilight systeem, de ander zegt dat dat niet gebeurd om de 'rust' te behouden. Iemand die zo'n ding in het echt werkende heeft gezien / in huis heeft?

Femme

[Verwijderd]

Je kunt ook een beknopte versie kopen bij http://shop.rightthing.nl...o&cPath=15&products_id=82. Ik gebruik er 4 in mijn woonkamer voor bij mijn beamer. Smartbytes levert ook maatwerk voor bij projectie opstellingen en videowall's

[SIMPY.be]

Aan iedere kant 3 CCFL's verbinden met een PIC die aan 4 sensor gangen. De PIC die PWM... RGB
Ikzelf heb een RGB ccfl trillingsgestuurd, en muziekgestuurd al gemaakt. Hier zie je alle kleurmogelijken; http://mct.simpy.be/portfolio/ccfl.html

[naftebakje]

Verwijderd schreef op dinsdag 10 januari 2006 @ 15:01:
Je kunt ook een beknopte versie kopen bij http://shop.rightthing.nl...o&cPath=15&products_id=82. Ik gebruik er 4 in mijn woonkamer voor bij mijn beamer. Smartbytes levert ook maatwerk voor bij projectie opstellingen en videowall's

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?

SIMPY.be schreef op dinsdag 10 januari 2006 @ 16:58:
Aan iedere kant 3 CCFL's verbinden met een PIC die aan 4 sensor gangen. De PIC die PWM... RGB
Ikzelf heb een RGB ccfl trillingsgestuurd, en muziekgestuurd al gemaakt. Hier zie je alle kleurmogelijken; http://mct.simpy.be/portfolio/ccfl.html

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?

[SIMPY.be]

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!)

[TheBlasphemer]

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...

[madwizard]

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++:

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.

[ Voor 8% gewijzigd door madwizard op 10-01-2006 20:44 ]

[madwizard]

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.

[Icey]

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.

[Verwijderd]

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

[ Voor 67% gewijzigd door Verwijderd op 10-01-2006 23:42 ]

[Shuisman]

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

[ Voor 22% gewijzigd door Shuisman op 10-01-2006 23:38 ]

[Verwijderd]

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.

[Exirion]

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.

[Glewellyn]

[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]

[naftebakje]

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...

[HunterPro]

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.

[Glewellyn]

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)

[ Voor 7% gewijzigd door Glewellyn op 11-01-2006 16:24 ]

[MeMoRy]

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.

[Glewellyn]

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.

[ Voor 55% gewijzigd door Glewellyn op 11-01-2006 16:54 ]

[naftebakje]

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).

[Koenzie]

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

[Glewellyn]

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.

[Xandrios]

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.

[naftebakje]

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.

[Glewellyn]

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

[ Voor 11% gewijzigd door Glewellyn op 11-01-2006 17:21 ]

[Koenzie]

ik ga trouwns voor de 3de

[Technicality]

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).

[Shuisman]

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 ?

[naftebakje]

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.

[ Voor 12% gewijzigd door naftebakje op 11-01-2006 17:47 ]

[Icey]

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

[TheBlasphemer]

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...

[Glewellyn]

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!

[ Voor 26% gewijzigd door Glewellyn op 11-01-2006 21:02 ]

[Pietjuh]

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).

[ Voor 14% gewijzigd door Pietjuh op 11-01-2006 20:38 ]

[Sprite_tm]

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...

[Glewellyn]

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

edit:
komma vergeten

[ Voor 4% gewijzigd door Glewellyn op 11-01-2006 22:28 ]

[madwizard]

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.

[ Voor 13% gewijzigd door madwizard op 11-01-2006 22:41 ]

[Shuisman]

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.

offtopic:
raad mijn naam eens...

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

[ Voor 28% gewijzigd door Shuisman op 11-01-2006 22:47 ]

[Verwijderd]

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.

[ Voor 10% gewijzigd door Verwijderd op 11-01-2006 22:45 ]

[Glewellyn]

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?

[ Voor 11% gewijzigd door Glewellyn op 11-01-2006 22:51 ]

[Sprite_tm]

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

[Glewellyn]

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.

[Skaah]

Verwijderd 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?

[Xandrios]

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

[HunterPro]

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 ).

[Glewellyn]

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.

[naftebakje]

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
-...

[Extera]

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

[Glewellyn]

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

[gambr0]

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...

[SIMPY.be]

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!!!

[madwizard]

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/

[ Voor 5% gewijzigd door madwizard op 12-01-2006 19:59 ]

[Xandrios]

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?

[ Voor 36% gewijzigd door Xandrios op 12-01-2006 21:31 ]

[Glewellyn]

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

[ Voor 17% gewijzigd door Glewellyn op 12-01-2006 21:41 ]

[Clock]

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?

[ Voor 9% gewijzigd door Clock op 12-01-2006 21:42 ]

[Sprite_tm]

Xandrios & Clock: Als het inderdaad met een ATMega88 op de manier die ik in gedachten heb kan (dus zonder voorschakelpruttel, geen lijnversterkers) ben je voor een tientje, misschien 2, aan onderdelen klaar. Daar komen dan nog de LEDS/CCFLs en de voeding bij/

[Xandrios]

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


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

Ja, 'k heb het aangepast tot 1.32 miljoen pixels maximaal (1280 x 1024)....veel plaatjes/wallpapers zijn op dat formaat

Als die "Nr. 7 - LPC2132" van 28 euro het zou aankunnen, dat is idd best wel betaalbaar Mooi

Sprite_tm schreef op donderdag 12 januari 2006 @ 21:50:
Xandrios & Clock: Als het inderdaad met een ATMega88 op de manier die ik in gedachten heb kan (dus zonder voorschakelpruttel, geen lijnversterkers) ben je voor een tientje, misschien 2, aan onderdelen klaar. Daar komen dan nog de LEDS/CCFLs en de voeding bij/

Dat is helemaal goed te doen, super

[ Voor 26% gewijzigd door Xandrios op 12-01-2006 21:52 ]

[naftebakje]

Sprite_tm schreef op donderdag 12 januari 2006 @ 21:50:
Xandrios & Clock: Als het inderdaad met een ATMega88 op de manier die ik in gedachten heb kan (dus zonder voorschakelpruttel, geen lijnversterkers) ben je voor een tientje, misschien 2, aan onderdelen klaar. Daar komen dan nog de LEDS/CCFLs en de voeding bij/

Kan je die niet samplen? Het gaat uiteindelijk om een educatieve oplossing, we leren gezamenlijk om toepassingen in elkaar te knutselen met µP, waardoor meer mensen met µP kunnen werken, en er ook meer gebruik van wordt gemaakt in bedrijven (daar waar ze hun geld halen).

PIC's kan je perfect samplen (20% van de omzet van Microchip zit in samples), werken ook op 20MHz, en kunnen gemakkelijk geprogrammeerd/in een print gezet worden, misschien handig? (Misschien zijn PIC wat moeilijker te programmeren, of wat minder krachtig?)
Edit: ik heb ff een datasheet bekeken van die ATMega88, enige verschil lijkt me dat die ATM een grotere instrucieset heeft (PIC heeft 35 instructies, is dus gemakkelijker te begrijpen), en als voordeel ook hardwarematig kan vermenigvuldigen (kunnen we nodig hebben, in PIC's moet je daarvoor een compiler gebruiken of zelf het vermenigvuldigen maken).

Nuja, de µP zelf doet er ws niet toe, het systeem waarmee we werken des te meer (werk kleurkiesalgoritme, hoe data inlezen).

[ Voor 23% gewijzigd door naftebakje op 12-01-2006 22:26 ]

[madwizard]

naftebakje schreef op donderdag 12 januari 2006 @ 22:15:
Kan je die niet samplen? Het gaat uiteindelijk om een educatieve oplossing, we leren gezamenlijk om toepassingen in elkaar te knutselen met µP, waardoor meer mensen met µP kunnen werken, en er ook meer gebruik van wordt gemaakt in bedrijven (daar waar ze hun geld halen).

Tja zo kun je samplen ook goedpraten natuurlijk AVRs zijn prima te verkrijgen, de zwaardere misschien wat minder maar futurlec heeft bijvoorbeeld een hele serie AVRs voor prima prijzen.

PIC's kan je perfect samplen (20% van de omzet van Microchip zit in samples), werken ook op 20MHz, en kunnen gemakkelijk geprogrammeerd/in een print gezet worden, misschien handig? (Misschien zijn PIC wat moeilijker te programmeren, of wat minder krachtig?)
Edit: ik heb ff een datasheet bekeken van die ATMega88, enige verschil lijkt me dat die ATM een grotere instrucieset heeft (PIC heeft 35 instructies, is dus gemakkelijker te begrijpen), en als voordeel ook hardwarematig kan vermenigvuldigen (kunnen we nodig hebben, in PIC's moet je daarvoor een compiler gebruiken of zelf het vermenigvuldigen maken).

Ik geloof dat PICs meestal meer clockcycles nodig hebben voor instructies, de AVRs kunnen er veel in 1 clockcycle doen. Maar misschien dat het bij nieuwe/zwaardere PICs anders is. Ik gebruik altijd AVRs.

[ Voor 6% gewijzigd door madwizard op 13-01-2006 14:03 ]

[madwizard]

Heeft er iemand trouwens nog ideeën over het verwerken van composite (of s-video) als aansturing, aan de hardware kant? RGB is natuurlijk lekker makkelijk maar een SCART aansluiting (of los RGB/Component) heb je meestal niet 'over', terwijl er vaak naast zo'n aansluiting nog wel een composite of s-video aansluiting over is. Die zou je mooi kunnen gebruiken om je ambilight aan te sturen, scheelt ook een hoop losse / 1 dikke kabel. Vervelende is dat composite zeker niet direct te verwerken is. Ik heb al flink gezocht naar ICs die hier iets mee kunnen. Er zijn wel wat ICs die composite omzetten naar analoog RGB maar deze zijn uit de jaren 80 en worden al lang niet meer gemaakt. Van de nieuwere ICs is zijn er veel PAL decoders te vinden maar deze hebben allemaal een digitale output met een dusdanige kloksnelheid dat je daar niet even makkelijk mee kunt werken in een microcontroller. Je kunt waarschijnlijk wel met een aantal ICs de boel weer in analoog RGB omzetten maar dan zit je alleen maar analoog naar digitaal naar analoog te converteren met een paar ICs van 10 euro per stuk en dat is ook weer wat overdreven. Weet er iemand nog ICs die hiervoor geschikt zijn? Of is er alleen nog maar digitaal spul te krijgen tegenwoordig?

[Sprite_tm]

Kom op, die AVRs kosten EUR2,17 (geen spam, afaik is dit gewoon de goedkoopste shop), je mag natuurlijk altijd free samplen als je dat wilt, maar imo kan je het voor die prijs net zo goed kopen.

madwizard: Da's inderdaad een leuke... Vroegah had Elektuur hier wel een schakeling voor, maar die kan ik zo 123 niet terugvinden... Nja, je kan altijd nog een sortta scart-tussenstekker maken die het RGB-signaal aftapt en een extra female scartstekker heeft waar je dan je andere apparaat aan kan hangen.

[madwizard]

Sprite_tm schreef op woensdag 11 januari 2006 @ 22:04:
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.

Volgens mij haal je nog veel minder pixels. Weet niet hoe je het aantal pixels hebt uitgrekend (hangt van je resolutie af) maar ik als volgt: Een beeldlijn is 64uS, waarvan 52uS zichtbaar. Op 500KHz samplen betekent 2uS per sample. Dat is 52/2=26 samples per beeldlijn. De ATmega's (iig de 88 en 8) kunnen niet alle kanalen tegelijk samplen, er wordt er steeds een geselecteerd. Dus die 26 moeten ook nog eens verdeeld worden over 3 kleuren, zodat je er max ~ 8 overhoud per beeldlijn.
Op zich genoeg als je het signaal eerst analoog middelt, dan heb je 8 gemiddelden per lijn. Alleen zit er dus wel een redelijke tijd tussen de samples waardoor het gemiddelde misschien te veel verschoven tussen de kleuren.

Als ik een beetje werkend iets heb wil ik het eigenlijk testen op VGA, omdat dat nou eenmaal (extra) uit m'n videkaart komt En het zou wel leuk zijn als het op zowel VGA als RGB uit SCART zou werken. VGA is alleen normaal gesproken 60Hz wat dus nog sneller gesampled moet worden.

Het beste is volgens mij toch een aparte ADC, bij voorkeur een die meerdere kanalen tegelijk kan samplen.

[ Voor 4% gewijzigd door madwizard op 18-01-2006 11:52 ]

[Sprite_tm]

madwizard: krek, je hebt gelijk Nja, dan zullen we inderdaad toch aan de externe AD-converter(s) moeten.

[Dukey]

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).

Heeft ook te maken met de beelden die er tussen worden berekend, het geheel wordt dan "vloeiender" waardoor het lijkt als of je een homevideo bekijkt. Ik ben der persoonlijk ook geen fan van, omdat het soms bij snelle pan/scan camerabewegingen dan nep uit ziet (lastig uitleggen, maar je ziet gewoon dat er wat tussen wordt gefantaseerd...)

[Glewellyn]

Sprite_tm schreef op woensdag 18 januari 2006 @ 12:17:
madwizard: krek, je hebt gelijk Nja, dan zullen we inderdaad toch aan de externe AD-converter(s) moeten.

Toch denk ik dat je prima kan werken met 8 samples per line... Je hebt 288 beeldlijnen per interlaced beeld dat geeft je denk ik een representatief genoeg gemiddelde.

Verder lijkt het mij verstandig om met een voortschrijdend gemiddelde te werken van de laatste 50 (halve) frames, op die manier fade je in een seconde van blauw naar geel bijvoorbeeld. Door te spelen met het aantal historische waarden kan je dan relatief makkelijk je reaktiesnelheid varieren.

Het effect van een kleinere steekproef op 1 frame kan je uitproberen met mijn php scriptje:
http://ambilight.100webcu...le=gold.jpg&samplerate=20

[ Voor 13% gewijzigd door Glewellyn op 18-01-2006 14:33 ]

[naftebakje]

Is het id van een samplende voorschakeling echt geen goeie oplossing? Als je met een PLL bijvoorbeeld de lijnfrequequentie *3 doet, kan je het gemiddelde van rechts, midden en links gemakkelijk maken (3 buffers, wat logica, sample-and-hold, moet te doen zijn). Dan heb je de 3 delen van het beeld, voor de 3 kleuren, dus 9 waarden die je inleest. Door de snelheid van op/ontladen te regelen van de sample-and-hold's, kan je dan nog regelen welke horizontale strook je meet.
Zo voorkom je (dure) externe A/D's, ik heb echter niet de tijd om nu schema's te bedenken, eerst mijn examens doen.

[madwizard]

Glewellyn schreef op woensdag 18 januari 2006 @ 14:31:
Toch denk ik dat je prima kan werken met 8 samples per line... Je hebt 288 beeldlijnen per interlaced beeld dat geeft je denk ik een representatief genoeg gemiddelde.

Ik ging in mijn algoritmes steeds al uit van 8 samples per lijn, alleen is mijn doel om 8x8=64 gemiddelden per beeld te berekenen, in plaats van 1 gemiddelde wat jij nu hebt in je script. Over het hele beeld genomen zal het wel loslopen met de volgorde van de R, G en B samples maar als je per lijn 8 gemiddelden wil is het lastiger, groen zou dan dichter bij de volgende sample zitten dan bij de rode waar ie bij hoort.

Verder lijkt het mij verstandig om met een voortschrijdend gemiddelde te werken van de laatste 50 (halve) frames, op die manier fade je in een seconde van blauw naar geel bijvoorbeeld. Door te spelen met het aantal historische waarden kan je dan relatief makkelijk je reaktiesnelheid varieren.

Dat ook, alleen bij mij zou dat dan in de uiteindelijke waarde gedaan worden omdat ik meerdere gemiddelden heb.

naftebakje schreef op woensdag 18 januari 2006 @ 14:50:
Is het id van een samplende voorschakeling echt geen goeie oplossing? Als je met een PLL bijvoorbeeld de lijnfrequequentie *3 doet, kan je het gemiddelde van rechts, midden en links gemakkelijk maken (3 buffers, wat logica, sample-and-hold, moet te doen zijn). Dan heb je de 3 delen van het beeld, voor de 3 kleuren, dus 9 waarden die je inleest. Door de snelheid van op/ontladen te regelen van de sample-and-hold's, kan je dan nog regelen welke horizontale strook je meet.
Zo voorkom je (dure) externe A/D's, ik heb echter niet de tijd om nu schema's te bedenken, eerst mijn examens doen.

Voor 3 kleurensamples is dat nog te doen, voor 64 is het wat minder

[ Voor 26% gewijzigd door madwizard op 18-01-2006 14:54 ]

[H!GHGuY]

de optie die xandrios aanhaalt was ook wat ik in gedachten had tijdens het lezen van dit topic.
capacitor opladen met signaal (versterkt signaal/gebufferd signaal/whatever) en dan de leds/lampen aansturen adhv de spanning over de condensator.

dat is de goedkoopste en doeltreffendste oplossing imo.
Wil je het geavanceerder, dan kun je zorgen voor een systeem die links/rechts boven/onder kan onderscheiden door het voltage te "delen" door een factor afhankelijk van de locatie die je uit het sync-signaal haalt. dit vereist op z'n minst wat meer logica.

ik wil echter wel nog een andere aanmerking maken:
hetzelfde grijs is donkerder tov wit en lichter tov zwart. maw: kleurgewaarwording is afh van de omgeving. als je dus lichten/leds met eht foute spectrum gebruikt kan je serieus je beeldkwaliteit om zeep helpen. Ideaal zou dus zijn om je spectrum te meten met rood/groen/blauw beeld en dan lampen/leds te kopen met een overeenkomstig spectrum. natuurlijk is de doe-het-zelf test met lampen/leds + R/G/B-beeld ook wel voldoende.

[naftebakje]

madwizard schreef op woensdag 18 januari 2006 @ 14:51:
[...]
Voor 3 kleurensamples is dat nog te doen, voor 64 is het wat minder

64 kleursamples per horizontale lijn lijken me erg duur en ook enigzinds overkill.

[madwizard]

naftebakje schreef op woensdag 18 januari 2006 @ 15:31:
64 kleursamples per horizontale lijn lijken me erg duur en ook enigzinds overkill.

Niet per lijn, in totaal per beeld. 8 horizontaal en 8 verticaal. Horizontaal analoog gemiddeld, verticaal over de lijnen heen digitaal.

[TweakPino]

madwizard schreef op woensdag 18 januari 2006 @ 11:51:
[...]

Volgens mij haal je nog veel minder pixels. Weet niet hoe je het aantal pixels hebt uitgrekend (hangt van je resolutie af) maar ik als volgt: Een beeldlijn is 64uS, waarvan 52uS zichtbaar. Op 500KHz samplen betekent 2uS per sample. Dat is 52/2=26 samples per beeldlijn. De ATmega's (iig de 88 en 8) kunnen niet alle kanalen tegelijk samplen, er wordt er steeds een geselecteerd. Dus die 26 moeten ook nog eens verdeeld worden over 3 kleuren, zodat je er max ~ 8 overhoud per beeldlijn.
Op zich genoeg als je het signaal eerst analoog middelt, dan heb je 8 gemiddelden per lijn. Alleen zit er dus wel een redelijke tijd tussen de samples waardoor het gemiddelde misschien te veel verschoven tussen de kleuren.

Als ik een beetje werkend iets heb wil ik het eigenlijk testen op VGA, omdat dat nou eenmaal (extra) uit m'n videkaart komt En het zou wel leuk zijn als het op zowel VGA als RGB uit SCART zou werken. VGA is alleen normaal gesproken 60Hz wat dus nog sneller gesampled moet worden.

Het beste is volgens mij toch een aparte ADC, bij voorkeur een die meerdere kanalen tegelijk kan samplen.

Volgens mij haalt zo'n atmel slechts 200kHz, en niet 500kHz. Je houdt dan nog maar 10 samples per beeldlijn over, dus 3 per kleur.
Omdat de atmel zo goedkoop zijn (E2,17) zou je ook 1 atmel voor elke kleur kunnen nemen. Deze kunnen elk dan één kleur voor hun rekening nemen. Een vierde atmel zou de drie kleuren weer kunnnen combineren en de ledjes / lampen aansturen. Als je dit alles in een doosje propt zou je het zelfs een quad-core atmel systeem kunnen noemen

[madwizard]

TweakPino schreef op donderdag 19 januari 2006 @ 16:03:
Volgens mij haalt zo'n atmel slechts 200kHz, en niet 500kHz. Je houdt dan nog maar 10 samples per beeldlijn over, dus 3 per kleur.

200kHz voor z'n volledige resolutie ja, maar z'n maximum ligt geloof ik op 1MHz. Dan heb je minder resolutie maar ik denk nog wel voldoende. Er staat in de datasheet van de atmega8 '3 LSB' bij de specificaties op 1MHz, weet iemand wat dit precies inhoud? Betekent het dat de 3 laagste bits dan niet nauwkeurig genoeg zijn?

Omdat de atmel zo goedkoop zijn (E2,17) zou je ook 1 atmel voor elke kleur kunnen nemen. Deze kunnen elk dan één kleur voor hun rekening nemen. Een vierde atmel zou de drie kleuren weer kunnnen combineren en de ledjes / lampen aansturen. Als je dit alles in een doosje propt zou je het zelfs een quad-core atmel kunnen noemen

Tja dat is een idee maar het mooist is natuurlijk alles in 1. Ik ben toevallig een tentamen parallel programmeren aan het leren, dan krijg je vanzelf al ideeën over meerder controllers combineren

Ik denk trouwens dat als je de analoge schakeling zo maakt dat ie kan switchen tussen 2 buffers (condensators) het misschien wel haalbaar is met de interne A/D converter. Je zit dan niet met het probleem dat het meten van R, G en B te ver uit elkaar ligt. Qua tijd verandert er dan niets natuurlijk maar in ieder geval meet je de kleuren dan juist. Desnoods kun je nog per beeldlijn 4 samples doen om en om, en dan combineren tot 8.

Daarnaast zou het nog leuk zijn als ook HDTV ondersteund werd. Bij 720p zit je bijvoorbeeld met beeldlijnen van 27uS wat het allemaal nog lastiger maakt

Er is trouwens op IA.net een animocheck opgezet voor een digikey inkoopactie, dus als je nog ICs nodig hebt voor dit project is het handig even te kijken.

[madwizard]

Hmm als ik het datasheet nog eens beter bekijk zie ik dat die 200kHz (of 500, max 1MHz) de klok is van de A/D converter maar het samplen minimaal 13 clockcycles duurt. Op 1MHz dus zelfs al 13uS .

[M-ThijZ]

Erg interessant project, ik vroeg me eigenlijk af wat de beste lichtbron was, en wat gebruikt Philips zelf eigenlijk?
CCFL's lijken me op het eerste gezicht het meest geschikt, maar in hoeverre zijn deze te dimmen. Het gebruik van LED's icm PWM lijkt me het makkelijkste, maar daar heb je weer veel LED's voor nodig, wat prijstechnisch gezien niet de beste oplossing is.

[naftebakje]

M-ThijZ schreef op donderdag 19 januari 2006 @ 21:43:
Erg interessant project, ik vroeg me eigenlijk af wat de beste lichtbron was, en wat gebruikt Philips zelf eigenlijk?
CCFL's lijken me op het eerste gezicht het meest geschikt, maar in hoeverre zijn deze te dimmen. Het gebruik van LED's icm PWM lijkt me het makkelijkste, maar daar heb je weer veel LED's voor nodig, wat prijstechnisch gezien niet de beste oplossing is.

Philips gebruikt CCFL's, deze zijn perfect te dimmen (PWM op de 12V voeding van de inverter). De eerste bedoeling lijkt me hier om ledjes (via PWM) aan te sturen, omdat die rechtstreeks op de meeste microcrontrollers kunnen gehangen worden. Als je die PWM ipv een ledje een FET laat aansturen, kan je er CCFL's mee aansturen.

[madwizard]

Dit lijkt me wel een geschikt ding:
Texas Instruments THS10064

• 4 analoge inputs
• 10 bits
• Gelijktijdige sample & hold!
• 6 MSPS op 1 input, 2 MSPS op 3 inputs (6 / #inputs)
• Interne referentie van 1.5V of 3.5V.
• Parallele digitale output
• Ingebouwde 16 word FIFO buffer

Kost € 8,36 (digikey), valt op zich nog mee en dan heb je ook wel wat.

Denk trouwens dat er zowieso 2 controllers nodig zijn, een voor het aansturen van de A/D en het berekenen van de gemiddelden en 1 voor het algoritme dat de kleur bepaald. Dacht eerst dat het wel samen kon maar met dit soort sample snelheden heb je eigenlijk best heel veel cpu cycles nodig

[ Voor 26% gewijzigd door madwizard op 20-01-2006 16:51 ]

[TweakPino]

madwizard schreef op vrijdag 20 januari 2006 @ 16:50:
Dit lijkt me wel een geschikt ding:
Texas Instruments THS10064

• 4 analoge inputs
• 10 bits
• Gelijktijdige sample & hold!
• 6 MSPS op 1 input, 2 MSPS op 3 inputs (6 / #inputs)
• Interne referentie van 1.5V of 3.5V.
• Parallele digitale output
• Ingebouwde 16 word FIFO buffer

Kost ¤ 8,36 (digikey), valt op zich nog mee en dan heb je ook wel wat.

Denk trouwens dat er zowieso 2 controllers nodig zijn, een voor het aansturen van de A/D en het berekenen van de gemiddelden en 1 voor het algoritme dat de kleur bepaald. Dacht eerst dat het wel samen kon maar met dit soort sample snelheden heb je eigenlijk best heel veel cpu cycles nodig

hmm, dit is idd wel een mooi ding. Alleen jammer dat ie niet zo makkelijk te solderen is.

Drie atmels die elk een kleur samplen is trouwens wel mogelijk als je 4 samples ipv 8 per beeldlijn neemt. één sample duurt 13us, 4 samples dus 52us, precies evenlang als het zichtbare deel in een beeldlijn. Je zou dan van twee opeenvolgende beeldlijnen 4 samples kunnen nemen in plaats van 8 samples op één beeldlijn, zoals ik hieronder heb proberen te teken:

code:

8 samples per beeldlijn:

  0...0...0...0...0...0...0...0...


4 samples per beeldlijn

  0.......0.......0.......0.......
  ....0.......0.......0.......0...

[madwizard]

TweakPino schreef op vrijdag 20 januari 2006 @ 20:41:
hmm, dit is idd wel een mooi ding. Alleen jammer dat ie niet zo makkelijk te solderen is.

Mja ik ben bewust een beetje over aan het gaan op SMD maar denk dat dit soort dingen in DIP ook veel lastiger te vinden is.

Drie atmels die elk een kleur samplen is trouwens wel mogelijk als je 4 samples ipv 8 per beeldlijn neemt. één sample duurt 13us, 4 samples dus 52us, precies evenlang als het zichtbare deel in een beeldlijn. Je zou dan van twee opeenvolgende beeldlijnen 4 samples kunnen nemen in plaats van 8 samples op één beeldlijn, zoals ik hieronder heb proberen te teken:
[...]

edit: Zag te laat dat je 'drie atmels' zei , nouja dit was m'n post :p:
Dat is ook wat ik in gedachte had, maar je vergeet dat je 3 keer zoveel samples moet nemen, 1 voor elke kleur. Er zit een multiplexer aan de ingang die een bepaald kanaal selecteerd. En zelfs al zou je het dan redden zou je een sample & hold achtig iets moeten maken om de kleuren ook op hetzelfde moment te meten (of in ieder geval de samplen). Het IC dat ik noemde kan niet alleen veel sneller samplen maar heeft ook een sample & hold voor elk kanaal, waardoor ze dus altijd op hetzelfde moment gesampled worden (alleen niet verwerkt, het duurt evengoed nog 3x zo lang voor 3 kleuren, maar op 6 megasamples is dat te doen).

Verder wilde ik ook letten op andere standaarden die nog sneller zijn, zoals VGA en HDTV.

[ Voor 5% gewijzigd door madwizard op 20-01-2006 20:54 ]

[TweakPino]

Als je idd ook rekening wilt houden met VGA en HDTV dan valt de atmel al gauw af en kom je bij de THS10064 uit.

Ik heb ook nog even bij microchip gekeken of zij nog een handige pic hadden. De dsPIC30F2010 heeft net als de THS10064 een gelijktijdige sample en hold voor 4 kanalen. Helaas haalt de AD omzetter 'slechts' 500ksps. Het voordeel van deze PIC is dat hij wel beschikt over 3 PWM units om lampen / leds aan te sturen.

[Verwijderd]

oud, i know maar ik wil dit project wel zien werken, dus een subtiele voet.

Ik zat rond te kijken op spam, en kwam dit tegen: http://www.voti.nl/winkel/catalog.html?IC-TDA8703-DIP
is die niet aan een PIC te hangen?
Ze zijn niet goedkoop nee, maar wel snel genoeg?

[ Voor 4% gewijzigd door Verwijderd op 06-03-2006 21:05 ]