Beste lezers,

Intussen weer wat verder gekomen met de "Testbeeld generator".

Ik heb nog wat onderzocht of er nog wat te doen is aan de kwaliteit van het beeld. Zoals eerder opgemerkt vond ik de "rafels" en het beeld net iets te veel. Nu weet ik dat de PAL-encoder (AD724) beperkt is, maar toch. Ik heb daarom het composiet-signaal gesplitst in Luma en Chroma en die aangeboden aan de S-video-ingang van de monitor. Het beeld is dan aanzienlijk beter (beeld op PC monitor, dus even niet op de trapvormen letten):

Uiteraard is S-video beter dan composiet, maar misschien is het beeld toch nog iets te verbeteren. Ik heb iets gelezen over het "lekken" van Y signaal naar het C signaal (dot crawling). Bij de AD724 is daar niets aan te doen, maar zijn "broertje" de AD725 heeft daar een voorziening voor, de Y-trap:

Is iemand van jullie bekend met dat fenomeen, en zou het nuttig zijn om eens met een AD725 te experimenteren?

Een ander punt is de beeldopbouw. Ik heb de gegevens gehaald uit het cursusmateriaal, dat werd gebruikt bij de toenmalige NTS:

Een volledig beeld heeft 625 lijnen. Per halfbeeld worden 20 lijnen gebruikt voor verticale synchronisatie. dit houdt in dat er 625-20-20=585 zichtbare lijnen zijn. Willen we "vierkante pixels", dan moeten er horizontaal 585*4/3=780 pixels komen. Dit heb ik geprogrammeerd in de FPGA. Het viel me daarbij wel op dat de kantelen van het PM5544 beeld dan niet of maar heel beperkt zichtbaar zijn. Nu zag ik in de datasheet van een andere PAL-encoder een andere beeldopbouw staan:

(Let ook op opbouw in 8 halfbeelden).

Hierin worden voor de verticale synchronisatie 25,5 beeldlijnen gebruikt. Weet iemand van jullie nu hoe het precies zit? Misschien dat voor kleur toch minder lijnen worden gebruikt dan voor zwart wit. dit zou kunnen verklaren dat de kantelen van het PM5544-beeld zo veel buiten het beeld vallen.

Otto

Voor kleur worden volgens mij niet minder lijnen gebruikt. Wel is de bandbreedte sterk beperkt. Dat kan omdat onze ogen een hoge resolutie in kleur niet aankunnen, De ogen zien scherpte met de staafjes waarvan er veel in het oog zijn en kleur met de kegeltjes, die in de minderheid zijn.Bij elke lijn is de burst aanwezig.
Er bestond ook nog zoiets als "volks pal", waarbij de fasefouten tussen opvolgende lijnen niet werden opgelost met electronica, maar door onze "gebrekkige" ogen.
Overigens krijg je als reparateur wel te maken met het testbeeld, maar dan met de fouten in een defecte tv. Dat is toch wat anders dan het opbouwen van een dergelijk testbeeld. Ik schreef al een keer dat het vol valkuilen zit en dat het beter is dan het beste element in de hele uitzendketen.
Ook interliniering kan beoordeeld worden, doordat bij een fout in de ontvanger bepaalde lijnen gaan paren en andere juist verder uit elkaar gaan.
Al sinds een paar jaren heb ik geen zin meer om voor derden TVs te repareren, Het blijkt dan dat je ook de routine kwijt raakt. De reparatie aan een analoge tv, met een beeldbuis is toch al weer een jaar of tien geleden. (Verdikkeme, wat gaat de tijd snel!. Mijn kleinkinderen, waarvan de oudste al weer acht is, hebben nooit een beeldbuis tv gezien.)

beste Otto

Uiteraard is S-video beter dan composiet, maar misschien is het beeld toch nog iets te verbeteren. Ik heb iets gelezen over het "lekken" van Y signaal naar het C signaal (dot crawl). Bij de AD724 is daar niets aan te doen, maar zijn "broertje" de AD725 heeft daar een voorziening voor, de Y-trap:

Je mag geen zuigfilter voor de luma toepassen rond 4,43 in een beeldgenerator. Het kan niet de bedoeling zijn een mooi plaatje te generen, maar wel een correct testbeeld...dus met dot crawl en al.

Nu is die dotcrawl vooral een gevolg van het niet correct locken van de subcarriër met de H-sync. Dat wordt ook (in bedekte termen ) ookvermeld op de wiki pagina en ik had je in vorige posts je er al op gewezen.

Bij een correcte SC versus H relatie kan een 2H comb flter in de ontvanger de dot crawl 100% vermijden in PAl en NTSC, in secam blijft het een drama.

Nu zie ik op jouw foto's niet echt dot crawl, maar vooral een onscherpe overgang..

Een volledig beeld heeft 625 lijnen. Per halfbeeld worden 20 lijnen gebruikt voor verticale synchronisatie. dit houdt in dat er 625-20-20=585 zichtbare lijnen zijn. Willen we "vierkante pixels", dan moeten er horizontaal 585*4/3=780 pixels komen. Dit heb ik geprogrammeerd in de FPGA. Het viel me daarbij wel op dat de kantelen van het PM5544 beeld dan niet of maar heel beperkt zichtbaar zijn.

Niemand verplicht je vierkante pixels aan te houden. in andere gevallen kan dat van belang zijn, maar niet hier, tenslotte ga je terug naar analoog. De resolutie die eruit komt programmeer je, en wordt niet bepaald door het aantal pixels.(als er maar genoeg zijn)

Nu vergeet je wel te vertellen of je aantal berekende pixels geld voor de actieve lijn (52µs) of de gehele lijn (64µs)...

Hierin worden voor de verticale synchronisatie 25,5 beeldlijnen gebruikt. Weet iemand van jullie nu hoe het precies zit? Misschien dat voor kleur toch minder lijnen worden gebruikt dan voor zwart wit. dit zou kunnen verklaren dat de kantelen van het PM5544-beeld zo veel buiten het beeld vallen.

Het actieve beeld bestaat uit 576 lijnen van 52µ sec. De rest zit in de blanking, ttz de lijnen worden geschreven maar het is zwart en wordt eventueel gebruikt voor rand signalen zoals teletekst, time code etc. uiteraard vallen je kantelen (voor een stuk) in dit blankinggebied wat dus normaal zwart is. Als je je dus enkel focust op de actieve zone is het normaal dat er niet veel kantelen overschieten.. (De bedoelng van de kantelen is dat je ze niet ziet als het toestel goed is afgeregeld , dus ze moeten wel voor een stuk doorgaan in de blanking)

Indien nodig kan ik wel eens meten hoe diep de kantelen doorlopen in het blankingebied.

groeten

Kris

Hallo Otto,

Kantelen, zichtbaar video en blanking timing.

Ik vond het onderwerp "narrow blanking" als onderdeel van line blanking controle in de videoketen (studiomengtafels) in combinatie met een "Colorbar over Red" testbeeld met een witte bies van een paar beeldlijnen tussen de twee ongeveer in het midden van het beeld. Hiermee kan je min of meer de uiterste grenzen van het horizontaal zichtbare video deel herleiden.

Ik weet niet of de PM5544 kantelen de hier beschreven uiterste blanking grenzen overschrijden. Wil dit wel een keer toetsen of de PM5534 hieraan voldoet.

Hou er wel rekening mee dat de EBU en SMPTE specs. in de periode 1974 (bouwjaar PM5544) tot ca. 1990 strenger geworden zijn, gezien de industrie daar meegegroeide. Het zou best kunnen, dat als je de PM5544 in een modernere studio anno 1990 zou plaatsen, dat de out-of-specs kantelen doodgewoon door genormeerde blanking timing in de verdere videoketen gekapt zouden worden (aanname; gezien de techniek waarmee de PM5544 was ontwikkeld in 1984 al ingehaald werd door de PM5534, die met zijn OQ5501 sync fabriek veel nauwkeuriger signaal produceerde).

Best interessant om een keer een PM5544 naast een PM5534 te vergelijken!
Het gaat overigens om een luttele 0.45us aan extra zichtbaar video aan de linker beeldzijde.

Groet,
Coert

Hier de narrow blanking gegevens (Tektronix):
******************************
Line Blanking Interval
Nominal Blanking: 12.05us nominal for all test signals
execpt narrow blanking signal. Beginning at 50% point
of active video.

Narrow Blanking: 11.60us +-0.1us for narrow blanking signal.
For blanking with measurement.

******************************
- 75% Color Bars Over Red With Narrow Blanking -
Luminance rise times: 150ns +/-25ns

Field Timing
Color Bars: Lines 23-156
Narrow Blanking: Lines 157-176
(700mV white bar with 150ns luminance rise times and 11.6us blanking)
Red: Lines 177-310
******************************