Post processing of NBTV

Forum for discussion of narrow-bandwidth mechanical television

Moderators: Dave Moll, Andrew Davie, Steve Anderson

Post processing of NBTV

Postby gary » Mon Mar 31, 2008 5:58 pm

AncientBrit wrote:I may be jumping to conclusions but it seems all the prior discussions assume a frequency stable input signal which is fine for an electronic source of pix.

But how one cope with an NBTV mechanical source where the frequency stability is suspect? There could be no fixed relationship between input and output scan rates.

Regards,

Graham


That is indeed a different kettle of fish, Graham. I am referring, on this thread, to standards conversion of material already digitised to the PC in a frame stable format. The problem reduces to one of converting from the digital domain to the digital domain where the ratio of the conversion is non-rational due to arbitrary user input of line resolution, aspect ratio, and frame rate.

Interestingly the problem is much simpler when converting from the analogue domain to the digital domain (and hence back to the analogue domain) assuming that the analogue domain signal is stable in frequency.

At this stage the only solution I have is to simulate the analogue domain (i.e. continuous rather than discrete signal) by massive oversampling. This, of course, introduces computational power problems.
gary
 

Postby AncientBrit » Mon Mar 31, 2008 10:23 pm

>Gary,

Understood, thanks.

Perhaps at some stage we might return to the theme of digitising a non- stable mechanical source?

In the meantime I'll keep listening,

Regards,

Graham
AncientBrit
Green padded cells are quite homely.
 
Posts: 858
Joined: Mon Mar 26, 2007 10:15 pm
Location: Billericay, UK

Postby gary » Thu Apr 10, 2008 7:37 pm

I am posting a hacked up utility I have been using to test my algorithms for additional NBTV formats and would appreciate any feedback but especially from anyone who can test the video on mechanical monitors of the appropriate format.

The utility supports:

NBTVA (standard 32 line)
Baird (30 line with outermost 3 lines widened)
TeKaDe/Telehor (30 lines landscape)
Visionette (24 lines, 30 frames/sec, landscape)

The utility allows video to be created from bitmaps either provided internally or user provided.
Attachments
OmniNBTV.zip
Updated
(1.16 MiB) Downloaded 1675 times
Last edited by gary on Sat Apr 12, 2008 9:56 am, edited 1 time in total.
gary
 

Postby NutmegCT » Sat Apr 12, 2008 6:09 am

Gary - congratulations on the progress! For a "hacked up utility" it's quite impressive. For that matter, it's impressive for a finished product!

I've used the supplied input samples, as well as some still and moving .wav files of my own (NBTVA format). All input files create a "view" which works perfectly for me for immediate viewing, and for saving.

One tiny behavior surprise: When creating an NBTVA format file, I get the message "video created ..." etc. I don't get that message after Creating a file using any other format.

Until I hear from Peter on the Visionette availability I can't actually test the Visionette output file on hardware; however, if the two "mesh", I'd say you've created an extremely useful tool.

Thanks.
Tom
WinXP, SP2
NutmegCT
Research Scientist
 
Posts: 44
Joined: Wed Dec 05, 2007 9:51 am
Location: Connecticut USA

Postby gary » Sat Apr 12, 2008 10:00 am

NutmegCT wrote:One tiny behavior surprise: When creating an NBTVA format file, I get the message "video created ..." etc. I don't get that message after Creating a file using any other format.


Thanks Tom, I have uploaded a corrected version (see my previous post).
gary
 

Postby Viewmaster » Sat Apr 12, 2008 6:45 pm

Thanks again Gary for another winner. I can now sit back and watch other formats too as well as NBTV standard.
I'm enjoying the music too. :)
Albert.
User avatar
Viewmaster
Frankenstein was my uncle.
 
Posts: 1306
Joined: Fri Apr 06, 2007 4:50 am
Location: UK Midlands

Postby NutmegCT » Sat Apr 12, 2008 11:33 pm

Albert - just curious - what do you watch the "non-NBTVA" files on? (TeKaDe, Visionette)

Do you have one of Peter's Visionettes? I'm trying to learn if the Visionette circuitry will accept input from audio .wav files. Haven't heard from Peter about that.

Thanks.
Tom
NutmegCT
Research Scientist
 
Posts: 44
Joined: Wed Dec 05, 2007 9:51 am
Location: Connecticut USA

Postby gary » Thu Apr 24, 2008 12:26 pm

This thread is an example of one that really got off topic. I never really did get any comments on my original question relating to the format of meta-data within NBTV wave files to allow identification of the actual NBTV format the audio represents.

With the advent of new formats, e.g. time-multiplexed colour, 128-line ;-), etc, I think it is becoming even more important to decide on a standard.

Even if you only use mechanical monitors that have no use or knowledge of this meta-data, in a few years time, when you come to browse through your library of NBTV video on your PC you may regret not being able to easily determine what video format they are in.

Those of you who have played around with my OmniNBTV utility may have noticed that it can automatically recognise the format of the items it creates, whereas, items imported from an external source result in it having to ask the user to specify the format. The app recognises it's own material because it adds in an "nbtv" RIFF chunk (for those who are interested but don't know what the hell I am writing about, I recommend at least a quick look at the BWF document I have a link to in my original post).

The format of this chunk is:
<chunk>
<chunk>
<nbtv>
<reserved>

where,

<chunk> = 'n','b','t','v'
<chunk> = 8
<nbtv> = a 32 bit number representing a format (1 = NBTVA standard)
<reserved> a 32 bit number for future proofing. i.e. it can extend the size of the chunk to include extra data.

Keep in mind that wave files are RIFF files, and RIFF files were designed for this kind of use so adding this data will have no detrimental effect on any applications that use wave files - it is industry standard - those applications that don't use this information simply ignore it.

Note also that chunks may be added to the end of RIFF files so existing items can be easily modified to include this chunk if necessary.

I have added this chunk as an interim measure in the absence of other suggestions but it is, of course, restricted to items OmniNBTV has created only so it is not too late to completely change the format, or move the information into a BWF chunk for even further industry standardisation (i.e. many wave editors allow the inspection of BWF data). Now is the time for input.

I really believe that the addition of this information will eventually be of great use in the exchange of NBTV material via wave files between interested parties and I especially recommend that members creating formats and software applications at least have a look at this method and how they might incorporate it into their own designs.
gary
 

Postby chris_vk3aml » Thu Apr 24, 2008 6:06 pm

Great work Gary!

I have now generated .wav file copies of most of my experimental NBTV tape recordings back to 1970. Semi-complete sets of CD ROMS - some 18 of these - have been provided to Gary Millard and Daniel Gosson. Unfortunately, the lack of adaptability and the immobile scan rate provided by software video display packages limit their ability to display these. Danny Gosson has had better success at playing these on his mechanical displays by manipulation of the speed control on his discs. I have many important recorded examples of early work by NBTVA members - Doug Pitt, Stan Kujawinski, Alan Short, Gil Miles, Dan Van Elkan and Trevor Hill which can only be fleetingly viewed via "The Big Picture" program.

Just from a personal point of view, the only existing video recordings of my father are preserved on 32-line video recordings made on a stereo audio tape recorder in 1973. As my dad died in January 1975, these recordings are of great sentimental value to me.

It would be nice if the software viewing program could be interfaced - possibly via a games port on a computer - so that a pot could manipulate the line scan rate of the display software, or perhaps some outboard pulse-generating software could generate sync pulses at a variable rate to manually track the original scan speed of the tapes/scanners.

The fact of the matter is that many of our early recordings were made with scanning discs or sweep oscillators running at variable rates for experimental purposes. Sometimes the scan rates vary during the recordings themselves, an effect often encountered in running Nipkow scanners with the sewing machine (universal series) motors we frequently used in the early 1970s. I am sure that I was not the only experimenter of that time to use whatever cheap driving motors we could obtain on our High School students' pocket money of the time. There was also some variability of recording speeds between various open reel tape recorders in the 1970s. Replay in those days, even completely without any sync pulses, was quite simple - you varied the speed of the Nipkow disc driving motor to view them, or shifted the incremental sweep speed of a CRO manually with a fine control pot. Generally you could manually track the line speed reasonably well.

The point I'm making is that standards were not all that hard-and-fast at any time in the NBTVA's history. But I still feel that 32 lines at 12.5 fps should remain a basic standard. Anybody who has tried to make an ACCURATE Nipkow disc for 64 lines or more will know why I'm urging the retention of that standard, just as I would urge the retention of vertical scanning in the 2:3 aspect ratio, so perfectly suited to maximising the effect of limited definition on a facial image (see the reproduced 40-line picture on the left).

More power to your programming, Gary - I'm sure we all feel that your contributions to this have been mightily excellent so far, and every bit of effort you've put in has been greatly to the whole group's advantage.

With sincere thanks on behalf of us all,

Chris Long VK3AML.
chris_vk3aml
 

Postby Viewmaster » Thu Apr 24, 2008 9:29 pm

chris_vk3aml wrote:Great work Gary!

With sincere thanks on behalf of us all,
Chris Long VK3AML.


Maybe I could take this opportunity to thank again all those wizz kids we have among us......
Gary, Chris, Steve, Graham, etc for engaging in all the troubled bits and bytes, programming and circuit designs/ideas which others of us do not understand but get the benefit of.

I sometimes feel guilty that I gain so much from all this creativity, but have so little to give in return....except the odd joke now and then! :)
Thanks guys.
Albert.
User avatar
Viewmaster
Frankenstein was my uncle.
 
Posts: 1306
Joined: Fri Apr 06, 2007 4:50 am
Location: UK Midlands

Postby AncientBrit » Thu Apr 24, 2008 10:30 pm

>Gary,

"To get back on topic", I'll cast my vote for the NBTV format option.
It seems more flexible and appropriate for our work.


Regards,


Graham
AncientBrit
Green padded cells are quite homely.
 
Posts: 858
Joined: Mon Mar 26, 2007 10:15 pm
Location: Billericay, UK

Postby gary » Mon Apr 28, 2008 9:31 pm

chris_vk3aml wrote: I have many important recorded examples of early work by NBTVA members - Doug Pitt, Stan Kujawinski, Alan Short, Gil Miles, Dan Van Elkan and Trevor Hill which can only be fleetingly viewed via "The Big Picture" program.


Thanks for the kind words Chris.

True, it only supports 32 line/12.5fs video, however there is a version floating around that allows sync processing to be turned off that does a better job of following video that just has speed variations and/or poor sync (i.e. it just assumes frame of the correct size and rate).

chris_vk3aml wrote:It would be nice if the software viewing program could be interfaced - possibly via a games port on a computer - so that a pot could manipulate the line scan rate of the display software, or perhaps some outboard pulse-generating software could generate sync pulses at a variable rate to manually track the original scan speed of the tapes/scanners.


In fact I have had for quite a while now a hacked up piece of software that allows variable line rate and line length and this does a fair job of tracking at least some of the video I have of yours. Unfortunately, because of the relatively low sample rate of NBTV video, small variations can cause large (detrimental) effects, but at the same time doesn't allow small corrections.

I have recently begun attempting to improve on this by using massive oversampling (or at least resampling to a much higher rate). This will allow much finer corrections to be made. The downside is that this is very CPU intensive and so may not be suitable for realtime display, however, I feel it will still be useful for post processing this type of video. I envisage being able to use the controls to 'tidy' up the signal on a frame by frame basis, and allowing each frame to be then saved in that state, thus building up a new stable video stream. In fact, if the variations are temporally slow, many frames can be processed in one hit.

So... watch this space!

(also suggestions and words of encouragement are ALWAYS welcome)
gary
 

Timebase correction...

Postby Steve Anderson » Mon Apr 28, 2008 9:48 pm

gary wrote:....to improve on this by using massive oversampling


Indeed that's the way to go. I've been working on this in the background for some time now and the major problem for me has been the accuracy of the sync pulses that actually define the supposed line time. The source material I have from various downloads shows a an equal irregularity between the sync pulse and the line-time. So neither can really be taken as a reference.

What doesn't help is the source is usually far removed from 400Hz, meaning lines have to be inserted/duplicated or dropped.

It's a real headache and one I've put on the 'back-burner'.

Steve A.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 5360
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Re: Timebase correction...

Postby gary » Tue Apr 29, 2008 5:17 pm

Steve Anderson wrote:...the major problem for me has been the accuracy of the sync pulses that actually define the supposed line time. The source material I have from various downloads shows a an equal irregularity between the sync pulse and the line-time. So neither can really be taken as a reference.

What doesn't help is the source is usually far removed from 400Hz, meaning lines have to be inserted/duplicated or dropped.

It's a real headache and one I've put on the 'back-burner'.

Steve A.


Just looking at this post again, and also to bounce a few ideas around, I was wondering why you think that lines have to be "inserted/duplicated or dropped"?

I am referring here to mechanically scanned video and maybe video from an electronic source is different, but it seems to me (leaving recording to tape issues aside for the moment) that all of the line information should be there, just compressed or expanded in length due to variations in motor speed (OK, some frequencies will be lost when the motor slows down but this should have negligible effect) so the real trick is how to determine, and then reproduce, the variations... (my head hurts)

Also, "sync pulses"? bloody looxury! a lot of the material I have doesn't have them and so there is no reference point at all. Which brings me to another question, how does one do DC restoration on a sync-less video stream? I have a vague notion that the best one can do is to assume that there is black in each frame, or maybe even line, and to equate the lowest sample value over the period to be black. In sync-ed video the time constant is related to the sync period, but what should it be in sync-less video? In my experiments so far I have simply kept track of the lowest level sample and used that to normalise to zero (black) using a time constant derived from the selected line frequency. This works to some extent but does not remove the possibility of too dark or too bright sections of the video. How is it done for mechanical monitors? (with sync-less video I mean).

Any thoughts from anyone would be most welcome.
gary
 

Postby chris_vk3aml » Tue Apr 29, 2008 6:50 pm

So far as I am aware DC restoration is a post-mechanical TV concept. I am not aware of any 30-line receiving circuit published in the 1930s that even hinted at the usage of DC restoration. Many black and white TV sets of the 1960s and early 1970s had no DC restoration either. These simply could not do a 'fade to black', they always faded to grey! DC restoration only became absolutely essential when the mixing of three colour video components were necessary.

As Gary says, "purely looxury"! In the 1970s, those of us working in NBTV really did live in the proverbial video "paper bag in a septic tank"!

I'm not sure, but I think DC restoration was another A D Blumlein/Marconi-EMI concept, like flyback EHT, but it certainly was not universally applied in the monochrome days. Even today, I have a cheap little portable 5" monochrome set which my wife and I take on holidays up country, and it very obviously has no DC restoration.

One problem with DC restoration lies in reproducing NBTV recordings with 'ringing', overshoot or excessive treble boost, where the restoration may actually lock to the dark tips of video overshoot - a very odd effect when DC restore is applied.

Like gamma correction, DC restoration is one of those things that is a 'nicety' but which one can really live without. I find 32 line pictures without aperture correction, or with streaky rasters due to using a round scanning spot without spot wobble (in CRT case) or via using Nipkow disc with undersized circular holes far more annoying. However it WOULD be nice if we had it.

The way I obtained DC restoration was simply to place a diode across my CRT grid to the CRT cathode, this would charge the video coupling capacitor feeding the CRT very approximately so that the modulation applied was always generally upwards from a black datum, but it was very approximate.

Dear me, Gary, you must think that our mechanical scanners circa 1972 were built by Blumlein himself with the facilities of a major research laboratory! Only joking, but I think you'll find that pictures derived from mechanical scanners will be ALL OVER THE PLACE in that regard, even today. How do you INSERT the dc component into a constant sync pulse stream with a mechanical scanner, let alone RETRIEVE IT ???? !!!!

Oh dear, dear, dear....

All the best,

Chris Long VK3AML.
chris_vk3aml
 

Next

Return to Mechanical NBTV

Who is online

Users browsing this forum: No registered users and 25 guests