Ontwerp testbeeldgenerator Deel 3 (enkele vragen) (Toestel of techniek)
door Otto , Drenthe, 15-08-2017, 09:04 (2665 dagen geleden)
Gewijzigd door Otto, 15-08-2017, 09:23
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 crawl). 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
Ontwerp testbeeldgenerator Deel 3 (enkele vragen)
door soundman2 , Wouw, 15-08-2017, 09:34 (2665 dagen geleden) @ Otto
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.)
Ontwerp testbeeldgenerator Deel 3 (enkele vragen)
door Auke Kieffer , Farmsum, 15-08-2017, 18:20 (2665 dagen geleden) @ soundman2
Oef man,
Dit is voor mij high tech....
Ga door... Ik denk er eea v te leren...
Groetjes uut Grunn
Ontwerp testbeeldgenerator Deel 3 (enkele vragen)
door kris , Gent, België, 15-08-2017, 23:16 (2665 dagen geleden) @ Otto
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
Ontwerp testbeeldgenerator Deel 3 (enkele vragen)
door Otto , Drenthe, 16-08-2017, 07:35 (2664 dagen geleden) @ kris
Dank voor je feedback, Kris.
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.
Okee, maar ik wil niet echt een beeldgenerator bouwen, maar een apparaatje om een (zo goed) mogelijk beeld op onze oude televisies weer te geven. Alles wat ik extra mee kan nemen, doe ik, maar het is een hoofddoel. Want wie regelt en nu nog oude TV's zo af dat alles optimaal is? Ik denk dat men tevreden is met een mooi beeld. Het wordt dus echt een apparaatje met compromissen. Misschien dat ik nog iets maak dat eventuele filtering inschakelhaar is.
Nu zie ik op jouw foto's niet echt dot crawl, maar vooral een onscherpe overgang..
Okee, ik ben niet zo thuis in het herkennen van specifieke foutjes.
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)
Dat weet ik. Maar ik wil wil de "pixels" vierkant houden omdat het ook mogelijk is om plaatjes van SD-kaart weer te kunnen geven. Bij niet vierkante pixels zou je dan de plaatjes moeten bewerken voor ze op de kaart worden gezet. Bovendien moet ik dan bij de rekenkundige bewerkingen ook rekening houden met die "vervormingen", de cirkel in het PM5544 beeld moet dan als een ovaal worden berekend.
Nu vergeet je wel te vertellen of je aantal berekende pixels geld voor de actieve lijn (52µs) of de gehele lijn (64µs)...
Alleen het actieve deel van 52µs. 52µs/780pixels => 15 MHz pixel clock (vandaar het kristal van 30 MHz)
Het actieve beeld bestaat uit 576 lijnen van 52µ sec.
Dan is mijn beeld dus iets te groot. Voor vierkante pixels zou ik dan moeten gaan naar 768 pixels horizontaal, bij een kristal van 29,5 MHz
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)
Duidelijk.
Indien nodig kan ik wel eens meten hoe diep de kantelen doorlopen in het blankingebied.
Dat kan nuttig zijn. Wil je dat even meten, Kris?
Otto
Ontwerp testbeeldgenerator Deel 3 (enkele vragen)
door Maarten Bakker , Haarlem/Delft, 16-08-2017, 09:03 (2664 dagen geleden) @ Otto
Okee, maar ik wil niet echt een beeldgenerator bouwen, maar een apparaatje om een (zo goed) mogelijk beeld op onze oude televisies weer te geven. Alles wat ik extra mee kan nemen, doe ik, maar het is een hoofddoel. Want wie regelt en nu nog oude TV's zo af dat alles optimaal is? Ik denk dat men tevreden is met een mooi beeld. Het wordt dus echt een apparaatje met compromissen. Misschien dat ik nog iets maak dat eventuele filtering inschakelhaar is.
Ik snap denk ik het idee van een gadget te maken die net iets beter is dan van een gadget verwacht wordt en bewonder je doorzetting om ondanks het hinken op twee benen toch een zo correct mogelijk beeld te genereren (de Chinese concurrent pakt gewoon een jpeg van een testbeeld en geeft die weer), maar de uitspraak dat niemand oude TV's meer afregelt zodat alles optimaal is omdat mensen alleen maar een mooi beeld willen, vind ik al strijdig met zichzelf want afregelen totdat alles optimaal is, is precies wat je doet om een mooi beeld te krijgen.
Ik zou zeggen, je hebt nu zo hard gewerkt aan details die je niet nodig hebt om alleen maar een mooi bveeld te krijgen, doe het dan meteen zo correct mogelijk met alleen begrenzing door technische beperkingen.
Ontwerp testbeeldgenerator Deel 3 (enkele vragen)
door Otto , Drenthe, 17-08-2017, 20:57 (2663 dagen geleden) @ Maarten Bakker
Ik heb het idee dat sommigen denken dat ik een meetinstrument aan het maken ben. Dat is niet het geval, ik maak enkel een beeldgenerator. Dat is enkel mijn punt. Voorlopig ben ik wel zoet met de software, dus even geen updates meer...
Otto
Ontwerp testbeeldgenerator Deel 3 (enkele vragen)
door kris , Gent, België, 16-08-2017, 22:21 (2664 dagen geleden) @ Otto
Beste Otto,
bij de modernere generatore blijven de kantelen toch binnen het actieve gebied....
Dus,ze geven de safety zone aan. dwz het stukje actieve gebied dat in een BB tv werd opgeofferd om in alle omstandigheden een mooi gekard beeld te hebben.
Ik moet mijn digitale scoop nog eens uithalen om exact te meten wat de tijdsduur is. (na staat de analoge scoop op de werkbank..)
das ten vroegste voor het weekend. Nu op weg naar Kosovo..
En nu begrijp ik waarom je vierkante pixels wenst...
Als de bedoeling is een keurig plaatje te bekomen kan je idd een zuigkring voor de luma rond 4,43 gebruiken. Maar in principe veranderd dat niets aan de dot crawl, maar wel aan de "cross color" interferentie.
groeten
Kris
Ontwerp testbeeldgenerator Deel 3 (enkele vragen)
door PA1CSL , Amsterdam, 08-09-2017, 21:01 (2641 dagen geleden) @ Otto
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
******************************
Ontwerp testbeeldgenerator Deel 3 (enkele vragen)
door Otto , Drenthe, 21-09-2017, 17:47 (2628 dagen geleden) @ PA1CSL
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 +/-25nsField 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
******************************
Coert,
Dank voor het meedenken. Actief beeld is dus lijnen 23 t/m 310, oftewel 311-23 = 288 => 576 lijnen per beeld. Voor "vierkante pixels" dus inderdaad 768 x 576.
Otto