HDTV resolution.

In article en.co.uk,
Roderick Stewart wrote:
In article , J r powell wrote:
But - there was also a 405 625 one used for acessing archive tapes.

I wonder if they actually interpolated at all, or simply repeated
certain lines for 377i - 576i and discarded certain ones for 576i -
377i.

They did. Because the output field was in a fixed relationship to the
input field, the relationships between each output line and its
spatially nearest input lines were in a fixed repeating sequence, and
so the interpolation coefficients were fixed by combinations of
resistors, and only a small number of them was needed. As I recall it,
storage was done with hundreds of carefully matched capacitors.

Rod.

In the BBC Designs Department line store converter each of those hundreds
of stores was two capacitors with an inductor between them. The values can
be chosen so that it takes one line time (64uS for 625 input) for the
voltage on the input capacitor to reach the output capacitor. The voltage
change is a cosine shape. The output read timing determines where on that
cosine the voltage is read and that gives the interpolation. The actual
component values used were a bit different to give an edge enhancement.

Eric

On Sun, 20 Feb 2011 19:23:55 GMT, Steve Thackery
wrote:

I think it might by my particular brain. I'm also sensitive to CRT
refresh rates: I can see a 75Hz flicker, whilst 85Hz appears completely
smooth.

Quite probably.

I had an elderly monitor which was interlaced at 1024x768 and to me it
didn't flicker. To my wife it did. Badly.

On later CRTs (all non-interlaced) I can also see a flicker at lower
refresh rates. Probably phosphor persistence is one factor and the
rest is in the retina/brain which also does a LOT of processing

On Feb 23, 2:24*pm, Albert Ross wrote:
On Sun, 20 Feb 2011 19:23:55 GMT, Steve Thackery
wrote:

I think it might by my particular brain. *I'm also sensitive to CRT
refresh rates: I can see a 75Hz flicker, whilst 85Hz appears completely
smooth.

Quite probably.

I had an elderly monitor which was interlaced at 1024x768 and to me it
didn't flicker. To my wife it did. Badly.

On later CRTs (all non-interlaced) I can also see a flicker at lower
refresh rates. Probably phosphor persistence is one factor and the
rest is in the retina/brain which also does a LOT of processing

PC CRTs seem to have very different phosphors from TV CRTs. A TV CRT
showing 50p isn't bad. A PC CRT showing 50p is unwatchable (to me).
And the PC CRT is typically dimmer, meaning a like-for-like comparison
would reveal even more flicker on the PC CRT compared with the TV CRT
at the same refresh rate.

Cheers,
David.

On Wed, 23 Feb 2011 14:24:53 -0000, Albert Ross
wrote:

Probably phosphor persistence is one factor and the
rest is in the retina/brain which also does a LOT of processing

Brightness is also a factor. The flicker-fusion frequency increases with
brightness, which is why you can get away with lower refresh rates in
darker conditions (e.g. 48 Hz may be good enough in a dim cinema).

Richard.
http://www.rtrussell.co.uk/

On Wed, 23 Feb 2011 15:19:02 -0000,
wrote:

PC CRTs seem to have very different phosphors from TV CRTs. A TV CRT
showing 50p isn't bad. A PC CRT showing 50p is unwatchable (to me).

Yet another factor is that you're more sensitive to flicker in your
peripheral vision, and typically a PC monitor fills more of your field of
view than a TV does.

Richard.
http://www.rtrussell.co.uk/

On Tue, 22 Feb 2011 23:43:16 -0000, Richard Russell
wrote:

Here is the SD ARC program (another BBC BASIC production):

I've now uploaded the HD (1080i) ARC as well. So here is the full set of
my utilities that use the 'Weston' deinterlacer:

http://www.rtr.myzen.co.uk/HDtoSD.zip
http://www.rtr.myzen.co.uk/arcqtm.zip
http://www.rtr.myzen.co.uk/arcqtmhd.zip

Richard.
http://www.rtrussell.co.uk/

"Richard Russell" wrote in message news[email protected]

One of the big attractions of the 'Weston' deinterlacer, to me, is that
because it's not content-adaptive it doesn't take you by surprise! I
generally dislike algorithms which work well most of the time but fail
spectacularly when presented with something the designer didn't
anticipate. I'd rather use an algorithm which may not match the very
best, but never lets you down very badly either.

I understand how its relative simplicity prevents any potential major
failures from occurring, which is desirable for TV station staff who just
want an easy life, but personally I still think its fixed limitations spoil
too much material.
If one considers the analogy of different camera shutter speeds, which a
camera operator or TV producer might have chosen carefully to avoid
excessive fast-motion blurring, or to match the emotion and/or maximise the
realism of a certain scene, any fixed lossy processing further down the
chain seems to negate their efforts imho.


Anyway, I played with arcqtm.exe (thanks for sharing btw) using German 4:3
analogue satellite TV as the source, saved to hard disk in uncompressed
format, which I ARC'd to 14P16.

I was going to keep the output aspect ratio the same as the input, but then
I realised that if the lines from the original field remain intact, all the
newly-added lines would be discarded when the content was reinterlaced and
I'd end up with an output file that was identical to the input (unless the
deinterlacer was - inappropriately - used solely to swap field orders - an
awful thought).

The resultant artefacts were of course familar to me, having seen ARC'd
content on UK TV for a long time, but (as one would expect) were much less
obvious when viewing the material field-by-field on a progressive computer
monitor, than they were on realtime 50i playback through my CRT TV (fed from
576i PC TV-out socket).
It's hard to illustrate said artefacts over the internet for this same
reason, so I shan't even try.
For those who might be interested however, http://tinyurl.com/6975nyh
shows what happens when the source switches between cameras without a
cross-fade, when using the deinterlacer in 3-field mode. This is
uncompressed, and shows one field at a time (4 sequential fields of 288
doubled lines).

On Thu, 24 Feb 2011 21:04:21 -0000, j r powell wrote:

For those who might be interested however, http://tinyurl.com/6975nyh
shows what happens when the source switches between cameras without a
cross-fade, when using the deinterlacer in 3-field mode.

Needless to say a 3-field-aperture deinterlacer will cause 'leakage'
across cuts. Indeed the context help in ARCQTM tells you that in 2-fields
mode 'cuts are clean, but motion artefacts are increased' whereas in
3-fields mode 'motion artefacts are reduced, but there is slight leakage
across cuts'.

Generally leakage across cuts is irrelevant when the material is being
watched at normal play speed, but it can be an issue at reduced play speed
(the ultimate being a still frame, as in your example). In that case you
can either use the 2-field version throughout or use a cut-detector to
adaptively switch between the two modes. It's not a shortcoming of the
deinterlacing algorithm itself.

The fact remains that in absolute terms the Weston deinterlacer is very
good, and considering its simplicity and that it isn't content-adaptive
its performance is remarkable. It has been more than adequate for all my
professional deinterlacing needs, both hardware and software. For the
last 25 years or so it has been the deinterlacer of choice at BBC R&D
(where it was invented) and Snell & Wilcox (whom Martin Weston
subsequently joined).

Richard.
http://www.rtrussell.co.uk/

On Wed, 23 Feb 2011 07:19:02 -0800 (PST),
"
wrote:

On Feb 23, 2:24*pm, Albert Ross wrote:
On Sun, 20 Feb 2011 19:23:55 GMT, Steve Thackery
wrote:

I think it might by my particular brain. *I'm also sensitive to CRT
refresh rates: I can see a 75Hz flicker, whilst 85Hz appears completely
smooth.

Quite probably.

I had an elderly monitor which was interlaced at 1024x768 and to me it
didn't flicker. To my wife it did. Badly.

On later CRTs (all non-interlaced) I can also see a flicker at lower
refresh rates. Probably phosphor persistence is one factor and the
rest is in the retina/brain which also does a LOT of processing

PC CRTs seem to have very different phosphors from TV CRTs. A TV CRT
showing 50p isn't bad. A PC CRT showing 50p is unwatchable (to me).
And the PC CRT is typically dimmer, meaning a like-for-like comparison
would reveal even more flicker on the PC CRT compared with the TV CRT
at the same refresh rate.

Oh yes, good point.

Maybe it's because LCDs are more similar that some of the viewing
artefacts seem to be more visible on modern TVs.

"Richard Russell" wrote in message news[email protected]

On Thu, 24 Feb 2011 21:04:21 -0000, j r powell wrote:

For those who might be interested however, http://tinyurl.com/6975nyh
shows what happens when the source switches between cameras without a
cross-fade, when using the deinterlacer in 3-field mode.

Needless to say a 3-field-aperture deinterlacer will cause 'leakage'
across cuts. Indeed the context help in ARCQTM tells you that in 2-fields
mode 'cuts are clean, but motion artefacts are increased' whereas in
3-fields mode 'motion artefacts are reduced, but there is slight leakage
across cuts'.

Yeah, I only linked to it for the benefit of any casual readers who might be
lurking, in order to clearly illustrate the 'transfer of information' from
adjacent fields, and by extension the potential for inaccuracy this presents
(which is, after all, not confined to leakage between cuts).


Generally leakage across cuts is irrelevant when the material is being
watched at normal play speed, but it can be an issue at reduced play speed
(the ultimate being a still frame, as in your example). In that case you
can either use the 2-field version throughout or use a cut-detector to
adaptively switch between the two modes. It's not a shortcoming of the
deinterlacing algorithm itself.

Your ARCQTM program appears to use a cut detector in 2-field 50Hz mode(?).
Since the cross-cut leakage was totally eliminated in this mode, I presume
it intelligently avoided a combination of the two fields adjacent to the cut
(adapting to use 'prev & current' before the cut, then 'current & next'
after it).

Anyway, the same unwanted leakage is of course an issue where any movement
exists between fields (in either mode).
This example (last one I promise), from the same (slightly strange) German
programme shows an overlayed image being horizontally scrolled into view at
50fps.
First, here is the raw field sequence from the 4:3 transmission:
http://tinyurl.com/5sspcao
Now the ARC'd version: http://tinyurl.com/67nffq8

It's easy to see how the ARC'd version shows unwanted leakage from the 1st
and 3rd field in each 3-field group (such as an additional outline of the
woman's facial features on each side of their current position).
It seems to me (and please correct me if I'm wrong) that in situations like
this, the "weston's" performance is effectively limited to that of a bob
deinterlacer (ie. the only useful information available to create the new
line is coming from a single field), but with the added disadvantage of some
extra unwanted information leaking in to pollute the mix?
In other words, the information derived from the adjacent field(s) becomes a
hindrance rather than a help, and the scaler in an ARC is subsequently
forced to interpolate lines from an image that is both vertically
sub-nyquist sampled and 'polluted'?

Obviously these 'vertical scaling mistakes resulting from motion' are not
obvious when viewing single fields on a progressive computer display, but I
suspect they are what, to my eyes, create the annoying motion blur effect I
perceive when watching the "weston's" output on TV, because it means that
the odd and even fields no longer fully complement each other to form the
illusion of full-height resolution when a CRT displays them in sequence.