deinterlacing bij LCD

Niet meer: line repetition (a.k.a. line doubling) Soms: intra-field upscaling (vertical interpolation a.k.a. Bob) Vaker: 2-field vertical-temporal median filter ("digital scan") Ook: 2-field, 3-field, etc. vertical-temporal majority selection En: motion-adaptive recursion (V-T interpolation gebaseerd op het generalized sampling theorem - GST, ook "super resolution") En: directional-correlated de-interlacing (Faroudja DCDI) En: edge-dependent de-interlacing (Philips EDDI) En: structure-adaptive filtering (Sony DRC) En: bandlet transform (LetItWave) En voor film mode en still pictures uiteraard field insertion (a.k.a. Weave)

Ik denk dat als ik de PhD thesis van Erwin Bellers wat beter had gelezen dat ik er dan nog wel een paar moet kunnen noemen. Kortom: welke niet ! Wat was de vraag ook al weer ? :-)

Groeten,

-- Jeroen.

"Jeroen S" schreef in bericht news:4611470c$0$14700$ snipped-for-privacy@text.nova.planet.nl...

Wow, een paar kende ik al, de rest die je noemt staat hier goed beschreven:

Te ingewikkeld voor mij. Het wachten is op 720p HD progressive (jammer, dan is al die moeite bij Philips en Sony voor niets geweest). bedankt Aad

Inderdaad, Erwin is onder Gerard gepromoveerd, en dit paper was een voorloper van zijn thesis. Kun je wel even mee vooruit...

Ik zeg altijd maar dat een 1440i signaal meer informatie geeft dan een 720p signaal, voor (ongeveer) "hetzelfde geld", dus je zou wel gek zijn om tweemaal hetzelfde uitzenden als je de tweede keer ook de tussenliggende ontbrekende informatie kunt uitzenden. Overigens maakt een geringe vertikale beweging tussen onderwerp en camera van een progressive beeld een interlaced beeld, en vice versa. En dat laatste is dan zeer gevreesd omdat het onmogelijk is om nog de maximale vertikale resolutie te reconstrueren. Dat is de "kritische snelheid". Maar omdat stilstand vaker voorkomt dan vertikale beweging is interlace gemiddeld gunstiger. Je moet het alleen durven... De meeste mensen krijgen helaas hoofdpijn van het onderwerp interlace en de-interlacing. Vinden ze te moeilijk...

Dus we gaan nog effe door, bijv. voor 1080i signalen op 1080p schermen. Daar blijft nog wel even behoefte aan hoor !

J.

Ja, en nee.

Ja, je hebt gelijk, en nee, misschien is het *toch* geen slim plan. Al was het maar dat je bij een verdere conversie van een 1440i signaal

*weer* met die pokke-deinterlacing zit te kijken, terwijl je met een 720p 'alleen' maar een FRC te pakken hebt.

Dat mag je me even uitleggen, want als ik het boek van Ome Gerard erbij pak kan ik dat nergens terugvinden ;)

--
Martijn van Buul - pino@dohd.org

"Jeroen S" schreef in bericht news:4611685c$0$380$ snipped-for-privacy@text.nova.planet.nl...

niets geweest).

Dit begrijp ik even niet. 720p op 50frames/sec geeft toch schonere informatie dan een geinterlaced 1440i signaal? Of bedoel je dat 720p altijd op 25fr/sec verzonden zal worden en dan wordt gedubbeld in de tv.? Aad

Schoner ja, maar niet meer informatie. Ik denk dat het beter is om ook een keer "tussen de regels door te lezen".

Nee, ik vergelijk 720p 50 Hz met een hypothetische 1440i 25 Hz (50 fields / sec). Het enige verschil is dus dat de lijnen in het tweede field een halve lijn zijn opgeschoven, en dus niet precies dezelfde informatie bevatten maar informatie die in het andere field ontbrak. ALS je niet te gulzig bent met vertikale resolutie dan is dit een (kleine) verbetering. Je moet dus NIET proberen om 1440p (50 Hz) te evenaren.

Groeten,

-- Jeroen.

Natuurlijk, de-interlacing is niet altijd even gemakkelijk, hoewel het in de praktijk tegenwoordig al aardig meevalt. Het valt vooral tegen als er aan zenderzijde te weinig pre-filtering is gedaan, als er teveel informatie in een interlaced signaal wordt gestopt. Idealiter mag je maar ongeveer +40% meer vertikale scherpte maken, niet +100%.

Ik zal het Gerard nog een keer uitleggen, haha. ;-) (Grapje, ik denk echt niet dat hij dat nodig heeft !)

Okee, vergelijk even een 240p en een 480i raster.

240p scant twee keer dezelfde 240 lijnen, terwijl 480i de tweede keer 240 nieuwe lijnen tussen de 240 oude lijnen in scant. Als je weer de 240p camera neemt en je pant die vertikaal met 1/2 lijn per 1/60 sec. dan scant die de tweede keer ook 240 nieuwe lijnen tussen de oude lijnen in. Dat is dus een interlaced raster geworden, met alle voor- en nadelen die daar bij horen. Uit een progressive camera ! (Als de lens niet scherp genoeg is dan ga je niks merken van voor- of nadelen, want dan is er ook geen aliasing.)

Omgekeerd, met een 480i camera, als je die vertikaal pant met 1 lijn per 1/60 sec. (dat is dus dezelfde snelheid als

1/2 lijn van een 240p raster) dan scant hij de tweede keer precies dezelfde lijnen. Dat is dus een GROVER progressive (240p) raster geworden. Dit is de beruchte "critical speed" waarbij een interlaced systeem faalt omdat de even en oneven rasters elkaar niet meer aanvullen maar dupliceren. Dan kun je de ontbrekende lijnen dus niet meer invullen en heb je zware vertical aliasing. (Elke speed 2N+1 is critical.)

Maar ditzelfde nadeel heb je bij een (hypothetisch) 240p raster dus al bij stilstand, en het verdwijnt juist bij de critical speed. Beter bij stilstand is i.h.a. nuttiger...

En natuurlijk, een 480p raster is beter dan beide voorbeelden, maar dat genereert dan ook 2 keer zoveel informatie, dus dat mag dan ook wel voor die prijs. Maar, zeg ik dan, voor die prijs zou 960i weer nog beter zijn. Maar weer niet zo goed als 960p. Etcetera.

Interlacing is een ander woord voor vertical-temporal quincunx (offset) sampling. Het is dus essentieel voor het beoordelen van de kwaliteit om vertikale beweging te beschouwen. Want dat geeft (eventueel) problemen.

Het Generalized Sampling Theorem zegt dat je uit twee verschoven rasters de dubbele resolutie kunt reconstrueren, mits de 2 rasters niet toevallig precies op elkaar liggen. Gerard's favoriete recursive de-interlacer (Falconic) maakt daar gebruik van, maar dan heb je wel betrouwbare motion vectors nodig. Helaas zijn die nogal rottig uit een nog interlaced signaal te halen...

Groeten,

-- Jeroen.

Ja, maar dat is niet de *volledige* definitie van interlaced. Het tijdstip waarop dit gebeurt is natuurlijk anders, ik kom hier dadelijk op terug :)

Ja, maar zo ken ik er nog wel een paar. Jij hebt zojuist alle interlaced cameras en interlaced beeldschermen omgepraat naar een progressive camera/scherm. Immers, een interlaced camera *doet* niet anders dan met een halve beeldlijn staan bibberen, en een interlaced scherm *doet* niet anders dan het ene field per ongeluk een halve beeldlijn later weergeven. Maar het uiteindelijke beeld*signaal* is *wel* interlaced.

Anders gezegd: Als ik een progressieve TV op een 25 Hz trilplateau zet, dat op miraculeuze wijze precies de juiste amplitude heeft, moet ik er een interlaced signaal in douwen. Jij vindt het nog steeds een progressive TV, ik vind de hele contraptie een interlaced TV...

Heh. Ik werk in de computervision industrie, en daar wordt erg graag een flinke draai aan de focus gegeven, zodat 'ie tenminste lekker onscherp staat - want daadoor kun je sommige dingen opeens met subpixelnauwkeurigheid.

Joh, ik kan het je nog sterker vertellen: Zelfs als je motionvectoren eigenlijk *heel* vast liggen, is het nog rottig genoeg om er een op pixelniveau nauwkeurige deinterlacer van te bouwen. Iets met lopende bandjes met stukken fruit waar opnames van worden gemaakt, die in een rotvaart voorbij komen. Richting van de motionvectors ligt keihard vast, snelheid van de beweging is bekend uit andere informatiebronnen, dus in principe is het een eitje om een fatsoenlijk gedeinterlaced beeld te bouwen.

Todat je het daadwerkelijk gaat proberen, en tot de conclusie komt dat je twee fields dusdanig ver uit elkaar liggen dat de verlichtingsomstandigheden niet meer constant zijn, waardoor je gruwelijke artifacten introduceert of dat je vrucht eigenlijk stiekum een beetje in de cup ligt te waggelen waardoor je motionvectoren eigenlijk toch niet helemaal zo perfect bekend wezen, terwijl het oppervlakte van de gemiddelde appel zich niet echt leent voor het vinden van motionvectoren. Dezelfde problemen als de sjaal van Renata, zeg maar..

En dan heb ik het nog niet gehad over de machines waar vruchten in een soort rollerbank liggen, en waar de vrucht in field B een stukje verder is gedraaid dan in field A. [1]

Wij gebruiken dan ook maar progressive scan cameras (danwel gewone analoge camera's waarbij we fields maar als individuele frames uitschelden), deinterlacing bleek namelijk meer kapot te maken dan dat het aan extra info opleverde.

[1] Ben nog op zoek naar een motionvector-achterhaal-routineding dat specifiek getrained is op rotatie, zodat ik eventuele slip kan detecteren ;)

--
Martijn van Buul - pino@dohd.org

Ik bedoel dus dat je elke 1/60 seconde 240 lijnen scant. Dus dezelfde lijnfrekwentie van ca. 16 kHz. Het enige verschil is de halve lijn offset in elk 2e field bij het interlaced geval.

Jij hebt het gesnopen. Maar behalve bibberen is een eenvoudige vertical eye tracking (snelheid 1/480 beeldhoogte per 1/60 sec) dus ook voldoende om het een in het ander om te zetten. Dat is wat we bedoelen met de critical speed: dat jouw ogen langzaam naar onder of boven draaien. Dat is ook de mooiste manier om te testen of een beeld interlaced is: met je vinger langzaam omhoog of omlaag over het scherm bewegen, met je ogen volgen, en kijken of het scanning raster twee keer zo grof wordt. Er is dus bijna niets voor nodig !

Ja. Behalve dat je het woord miraculeus kunt weglaten, want eye tracking bij vertikaal langzaam bewegende objekten is heel gewoon. Dat is waarbij interlacing het meest fout gaat, terwijl in dezelfde situatie een progressive keten in een interlaced keten zou overgaan, en m.i. dus beter wordt !

Ik snap wat je bedoelt: aliasing verhindert dat je nog met sub-pixel resolutie een positie kunt bepalen. Want aliasing betekent letterlijk dat er meerdere originelen op hetzelfde signaal worden afgebeeld, dus er zijn meerdere oplossingen. Anti-aliasing bij sampling is dus van essentieel belang.

Overigens is down-sampling equivalent aan (eerste) sampling (van continue naar diskreet), alleen is het bij digitale down-sampling nogal triviaal (in theorie althans) om een goede anti-aliasing te doen. Dus een oversampled camera en een goede down-sampling methode kan er heel erg aan bijdragen om een schoon signaal van lager resolutie op te leveren. Dit geldt ook voor het maken van een interlaced signaal, dat moet je bij voorkeur niet direct met een interlaced camera doen want dan is de anti-aliasing filtering niet goed genoeg.

Je hebt namelijk een vertikaal-temporeel 2D lowpass filter nodig, en dat is verre van eenvoudig te maken. In februari heeft David Lyon van Snell & Wilcox het nog eens fijntjes uitgelegd hoe je eigenlijk een interlaced signaal goed moet opwekken opdat het ook fatsoenlijk te de-interlacen is. Zie:

(oeps mijn eigen presentatie wordt daar ook genoemd !) De titel is: "Spatio-Temporal Quincunx Sub-Sampling (or...)" en de document name is 2007_Lyon_Spatio-Temporal_Quicunx_Subsampling.pps maar ik mag je niet vertellen dat die file te vinden is op dus dat doe ik niet...

Mits je dus recursie toepast, volgens professor Gerard. Dat wil zeggen dat je de lijnen van het nieuwe field gebruikt, en de ontbrekende lijnen haalt uit het vorige *frame*, wat wordt verschoven over de motion vector. Dat levert samen een nieuw frame op, wat je dan de volgende keer weer gebruikt. Ziedaar de recursie. Bedoelde jij dat ook ? (En bij de kritische snelheid krijg je geen nieuwe informatie en dan ga je hele oude informatie steeds weer opnieuw gebruiken.)

Je zou je natuurlijk moeten afvragen of bij dergelijke hoge bewegingssnelheden het hele principe van de-interlacing nog wel opgaat. Wat denk je van objecten die in het andere field al buiten beeld gevlogen zijn ?

Ach, tegenwoordig is intra-field interpolatie langs diagonale lijnen (DCDI, EDDI) toch populairder. De lijnen uit het andere field (weave) worden eigenlijk alleen nog maar gebruikt in film mode en bij stilstand. Dus geen motion vectors meer nodig, alleen nog een ja/nee bewegings detektie, en natuurlijk een hele goede schatting van diagonale lijnen binnen een field. Het doel is dan om die te interpoleren zonder trapjes (jaggies) te maken.

Mij lijkt dat Gerard's favoriete recursive search block matching algoritme ook daar goed werk kan verrichten, vooral als je de nominale motion vector van de lopende band er vanaf trekt.

En anders kan Igor Borovikov's Critical Points filter misschien een oplossing bieden ?

Groeten,

-- Jeroen.