Line Interpolation.

[Steve Anderson]

If one were to construct a display that yielded 64 lines instead of the usual 32 by deriving the additional lines from the existing ones, how would you do it?

Would you simply average the values, e.g. pixel 24 in original line 12 has a value of 52 and line 13 pixel 24 has a value of 30 would the new line (call it 12a) have a value of 41? (The average of the two original lines).

Or would it be better to apply some other algorithm? Or even simply repeat line 12 to become line 12a?

A lot of work was done on this many years ago by amongst others the BBC for 405 to 625 and vice-versa conversion. And others continue to work on this for SD to HD conversion and the reverse.

In this case things are somewhat simpler, just a doubling exercise, a ratio of 2:1 rather than some awkward figure...

...ideas anyone...

Steve A.

[gary]

Steve, unless one is limited by a hardware implementation then the problem is simply one of image processing. There are a number of interpolation algorithms in use such as Binlinear, Bicubic, Lanczos, cubic spline, or even simple averaging as you mention. I can provide plenty of more information if this is what you are looking for.

[Steve Anderson]

Thanks Gary for refreshing my memory regarding interpolation, it's been a long time since I went anywhere near this subject.

In reviewing the processes involved and the (lack of) processing power at best all I can envisage is bilinear. But with already more samples (pixels) in a line than really required it may come down to a simple averaging process as you say.

I need to crunch some numbers to see if a PIC us up to the task in real-time.

Steve A.

[Viewmaster]

Steve, consider how splitting 32 to 64 will effect the club's CD No 1 test signals. Tracks 8-10, 11-13 and 14-16 for example all have single pixel
ON/OFF requirements, to give the sharp dot's and lines.

If you average values on these tests then you will get middle grey pixels in between the full white/black dots etc.

Will this not lead to a smudged outline where previously we had a sharp outline? So, for 32 lines purposes I would just repeat 12 to become 12a as your example mentioned.
Just my, probably, ignorant 2p's worth.

[gary]

Well, Albert, it's always a choice of whether you want a smooth picture or a pixellated one, ultimately you can't increase the bandwidth of the original picture so increasing it's size will result in either a "perceived" softening of the picture or additional pixellation.

This is also an application where aperture correction may be beneficial.

[gary]

I need to crunch some numbers to see if a PIC us up to the task in real-time.
Steve A.

It may be worth looking at the range of dsPICs...

[Steve Anderson]

Albert, your point is very valid and it's a continuing topic in the development of up-converters, 405-625, 525-625 and 625-1080. Test signals are always meant to expose the weaknesses and/or faults of or in a system and any artifacts should be exposed. In real program material you often have to really look hard and know what to look for to see them, of course there are exceptions.

What I am intending to do here is perform a number of purely subjective tests on an apparent line quantity increase, to see if the time, effort and cost is worth it. At the same time it also gives me an NBTV display which I WILL NOT strip for parts! I intend to perform this on a CRT as some of the methods don't lend themselves to a mechanical unit. A 75mm (3") CRT yields a reasonable sized picture where the results of these tests should be visible. I did a 72-line 3" CRT display a while back and it was still possible to see the line stucture, but that was about the limit.

As a reminder, below is a few screen shots of 72-lines on a 3" DG3-72 CRT...OK, I know the scanning directions are wrong. My current avatar is of a 48-line display, same CRT.

There are a number of schemes I plan, I'm open to suggestions for others..

1. A standard display, the 'control' or reference. (32-lines).
2. Introducing a triangular waveform for spot-wobble into the frame/horizontal deflection. (32-lines).
3. Simple line repetition, no processing. (64-lines).
4. Simple line-averaging at a moderately low pixel-rate, say 60 samples/line. (64-lines).
5. Bilinear interpolation as per above. (64-lines).
6. Both 4 & 5 above but at 120 samples/line. (64-lines).
7. ...suggestions...

***********************

Gary, I have considered the dsPIC range for other projects as well as this one, but it's quite a steep learning-curve when migrating from 8-bit devices. Something like USB which I have pushed into the future...but I know one day I'll have to get to grips with it.

Doing a few fag-packet calculations I think some of the newer PIC devices should be able to do it with their extended instruction set and faster speeds. These are all PIC18F devices.

Then there comes flicker reduction/elimination, see Graham Lewis's article in newsletter Vol. 29. No. 3. (March 2004), "NBTV Frame Rate Converter". Given the speed and additional external RAM this also possible. What subjective effect on the above pseudo-line increase would be is open to question.

More in due course...

***********************

If anyone is wondering what's happened to the SD-card thing (and others) I was working on...I had a rationalization of my NBTV projects. I had 12 in the pipeline and five actually 'active'. Now it's a case of one-at-time until completion AND submitted to Jeremy...THEN the next. All assuming 'real work' doesn't get in the way!

Steve A.

P.S. Some time later...the CRT mentioned above of course should have read, "a 3" DG7-32".

[Viewmaster]

It occured to me that although one cannot get something for nothing in this ol' world (re bandwidth) many photo manipulation applications have
'sharpening' facilities where it really does appear that one gets something for nothing.
I just wondered if the methods they use had any application to increasing NBTV lines, Steve?

[Steve Anderson]

Albert, a reasonable and intuitive progression, but processing power and time are against one here. Bicubic as opposed to Bilinear interpolation does perform a 'sort-of' edge-sharpening effect, but in one axis only, X or Y, but not both.

Then throw in motion. A still 'sharpened' my look like an improvement, but a series of them...perhaps not. The artifacts thrown up in fast-panning motor sports or football would be probably of no use. But this is way beyond where I want to go at this point, but a useful suggestion and one I'll keep in the back of my mind.

Steve A.

P.S. OK, fast-panning motor-sports are a no-no for mechanical TV, think of the gyroscopic stresses on an aircraft propeller and crankshaft when doing aerobatics! No difference really.

[gary]

Bicubic.... but in one axis only, X or Y, but not both.

Which, BTW, is ideal for NBTV where the resolution in one direction (e.g. the vertical direction for most Baird formats) is much greater than the other. In fact the vertical resolution in a mechanical nipkow disk arrangement is only limited by the height of the aperture and is theoretically infinite if you could make an infinitely small (in the direction of scanning) aperture, and produce an infinitely bright modulated light source. None-the-less, given these obviously practical limitations, it can be shown that an "optimised" aperture will always have a smaller dimension in the direction of scanning than across it. It is the transmission medium that normally reduces the resolution in the scanning direction (for obvious practical reasons), and it is conventionally assumed that the resolution in the scanning direction need be no greater than that across it.

The sharpening effect of image processing systems is really just a form of what we call aperture correction and is not increasing the bandwidth of the image but just lifting the high end that has been reduced by aperture distortion or some other form of (low pass filtering) processing.

P.S. OK, fast-panning motor-sports are a no-no for mechanical TV, think of the gyroscopic stresses on an aircraft propeller and crankshaft when doing aerobatics! No difference really.

hmmm, whilst this is obviously true when discussing the conventional construction of mechanical cameras, there is no reason I can see why the cameras optics could not be panned independently of the moving scanning device. In fact the optics are very often 90 degrees out of phase with the (most often) rotating device.

I admit though, that I can't think of a single example of such an arrangement.

[M3DVQ]

The bigger issue when you're using very low frame rates such as our 12.5 FPS club standard is the tearing of the picture when objects move at any speed in the direction of the line scan.

[Klaas Robers]

Steve, in the past I did some of those picture processings. One thing to remind is that optimally you should do the processing on non gamma corrected signals. So
1. perform de-gamma correction, i.e. square the voltage,
2. do the processing, interpolation, extrapolation,
3. perform gamma correction, i.e. square root the voltage.
Your CRT will square it again.

However, when you simply process the video signals in gamma-corrected form, you do 80% of the task.

Theoretically you should use a sin(x)/x function over the neighboring lines. However the method of inserting lines that are the mean value of both neighboring lines is not at all a bad method. The question is what to do with line 1 or line 64...... Anyway you need a memory of one NBTV-line for it.

Another comparably good method is to split each NBTV-line in two, where
the first one is 3/4 of that same line + 1/4 of the previous line,
and the second one is 3/4 of the line + 1/4 of the next line.
In this case by defining a virtual line 0 to be black
and a virtual line 33 to be black eliminates the edges problem.
You need a memory of two NBTV-lines for this solution.

[Steve Anderson]

Thanks Gents for your input. The advantage of a programmable device is the ability to experiment/develop/try different processing algorithms...given the internal hardware, speed and memory etc. to handle the software.

I must admit I had neglected the Gamma issue, but thankfully it's just a squaring function to return a Gamma-encoded source back to linear. The micros I'm considering have an 8-bit hardware multiplier which for an unsigned 8-bit multiply only takes one cycle. This returns a 16-bit result which you simply truncate (ignore the LSB). If you wanted to be clever you could do some round up/down from that byte. (Two more cycles).

The CRT will be made linear, and the other suggestions and points are certainly worth investigation. But first I have to get the hardware built! While I'm waiting for my slow metal-basher I can make a start on the electronic hardware and start mulling over the software.

The Bicubic function could be done but I need to work out the weighting factors applied to the pixels at differing distances. The point regarding line-1 and 64 is also an interesting challenge.

Thanks again...

Steve A.

[Steve Anderson]

Gents, thinking further on this...let's call the the original frame line 1 to 32 and the interpolated frame line 1' to 32'. Line 1' would be the interpolation of line 1 and 2, line 2' would be the interpolation of line 2 and 3....and so on.

Until line 32' which we simply make black. So we end up with an effective display of 63 lines rather than 64. But in an analogue display we still present the now black line 32' which gives us (perhaps) a black reference? A lot more to consider here...I need more thinking time...

One line lost in 64 is somewhat less than 50 in 625....

Steve A.

[Steve Anderson]

...more thinking on this....the only time we DO get a black reference is during the 'missing pulse' time...surely there's a reason for pause for thought here?

It's narrow, yes, but it's there...

More anon...

Makes AGC a whole lot simpler...

Steve A.