HDTV resolution.
David Paste
at x0.5 (or x2) would be better for up- or down-scaling or is there
some complercatid maffs that I am not aware of which renders this
moot?
T.I.A.
David Paste.
Peter Duncanson
Half of 1080 is 540 which is less than SD's 576.
I suspect American influence!
America SD is 480 rather than our 576.
480 x 1.5 = 720
720 x 1.5 = 1080
--
Peter Duncanson
(in uk.tech.digital-tv)
Brian Gaff
seen any kind of explanation for the various video modes on pcs either. I'm
sure they are based on storage or some historic limit that used to prevail
like most things, but it eludes me.
Brian
--
Brian Gaff....Note, this account does not accept Bcc: email.
graphics are great, but the blind can't hear them
Email: bri...@blueyonder.co.uk
______________________________________________________________________________________________________________
"Peter Duncanson" <ma...@peterduncanson.net> wrote in message
news:f6u0l6lsl1luauu1j...@4ax.com...
snot
> Hmm but that is a statement of fact not an explanation. I've never really
> seen any kind of explanation for the various video modes on pcs either. I'm
> sure they are based on storage or some historic limit that used to prevail
> like most things, but it eludes me.
>
> Brian
>
I suspect Peter is right. The countries producing the raw LCD screens
see the USA as their main market hence being based on multiples of 640 x
480, which is also the base resolution for PC monitors.
Dave
--
Blow my nose to email me
Andy Champ
> Half of 1080 is 540 which is less than SD's 576.
>
> I suspect American influence!
>
> America SD is 480 rather than our 576.
>
> 480 x 1.5 = 720
> 720 x 1.5 = 1080
>
Japan uses the same TV system as the US.
Andy
David Kennedy
Richard Russell
wrote:
> I'm sure they are based on storage or some historic limit that
> used to prevail like most things, but it eludes me.
I assume 1920 x 1080 was chosen partly because the total number of pixels
(2073600) makes efficient use of memory (2 Mpixels being 2097152).
Richard.
http://www.rtrussell.co.uk/
Mark Carver
There are other reasons too, I can remember going on a Tektronix training
course about 6 years ago, but I can't find my notes, and Googling brings up
nothing, but ISTR mathematical connections between the various HD and SD modes ?
--
Mark
Please replace invalid and invalid with gmx and net to reply.
Andy Champ
> Andy Champ wrote:
>>
>> Japan uses the same TV system as the US.
>>
>> Andy
>
> Yes and no
>
> Analogue yes, digital no [AIUI]
>
> <http://en.wikipedia.org/wiki/ISDB>
>
Thanks, I wasn't aware of that. I notice the Wikipedia article fails to
mention ISDB resolutions - but they seem to be the same as other systems.
Andy
David Paste
> Half of 1080 is 540 which is less than SD's 576.
>
> I suspect American influence!
>
> America SD is 480 rather than our 576.
>
> 480 x 1.5 = 720
> 720 x 1.5 = 1080
But wouldn't it have been better to come up with a system where the
two HD systems weren't so seemingly awkwardly matched? 720 and 1440
(rather than 1080).
Richard Russell
wrote:
> But wouldn't it have been better to come up with a system where the
> two HD systems weren't so seemingly awkwardly matched? 720 and 1440
> (rather than 1080).
But then they would differ by a factor of *four* in the total number of
pixels! The object with 720 and 1080 is to have two standards that differ
by approximately a factor of *two* (2073600 vs 921600) in the total number
of pixels.
And I don't understand what you mean by "awkwardly matched". The ratio
between 1080 and 720 is exactly 3:2 - you can't get a much more
straightforward ratio than that! When you think that conversions from HD
to SD are routine, and in the horizontal direction that's a ratio of
approximately 30:11, 3:2 is trivial in comparison!
Also remember that 1920x1080 is (usually) interlaced and 1280x720 is
progressive, so the real complication in converting one to the other is
the need to deinterlace the source. That would be just the same if the
ratio was 2:1 rather than 3:2, so in fact the conversion would not be
significantly easier.
Richard.
http://www.rtrussell.co.uk/
David Paste
> But then they would differ by a factor of *four* in the total number of
> pixels! The object with 720 and 1080 is to have two standards that differ
> by approximately a factor of *two* (2073600 vs 921600) in the total number
> of pixels.
>
> And I don't understand what you mean by "awkwardly matched". The ratio
> between 1080 and 720 is exactly 3:2 - you can't get a much more
> straightforward ratio than that! When you think that conversions from HD
> to SD are routine, and in the horizontal direction that's a ratio of
> approximately 30:11, 3:2 is trivial in comparison!
Well, you see, this is where my lack of understanding comes in to it:
One (me) would naively assume that to go from 720 to 1440 would be
trivial, as each pixel in the 720 material is simply reproduced 3
times, where as to go to 1080 means that either some lines of the 720
source are not reproduced as much as others. How do you get 100 lines
to transform equally into 150?
Kennedy McEwen
<bc2aae98-f661-4c19...@x3g2000yqj.googlegroups.com>,
David Paste <paste...@gmail.com> writes
New Line 1 = Old Line 1
New Line 2 = (Old Line 1 + Old Line 2) / 2
New Line 3 = Old Line 2
New Line 4 = Old Line 3
New Line 5 = (Old Line 3 + Old Line 4) / 2
etc.
In other words, every 3rd line is the average of two old lines and every
one of the old lines gets reproduced exactly the same, on 1.5 new lines.
--
Kennedy
Yes, Socrates himself is particularly missed;
A lovely little thinker, but a bugger when he's pissed.
Python Philosophers (replace 'nospam' with 'kennedym' when replying)
Richard Russell
wrote:
> How do you get 100 lines to transform equally into 150?
The mathematics are fairly complicated, but in principle what you do is
first upconvert the 100 lines to 300 lines and then you throw away
alternate samples to give you 150 lines. In general the process
conceptually involves upconverting to the Lowest Common Multiple of the
input and output sampling rates, and then decimating, but practical
implementations use shortcuts which avoid literally doing that.
You may be interested in reading my online paper on scaling:
http://www.rtrussell.co.uk/filters/fdscale.html
Richard.
http://www.rtrussell.co.uk/
davidr...@postmaster.co.uk
> On Thu, 10 Feb 2011 22:45:58 -0000, David Paste <pasteda...@gmail.com>
> wrote:
>
> > How do you get 100 lines to transform equally into 150?
>
> The mathematics are fairly complicated, but in principle what you do is
> first upconvert the 100 lines to 300 lines and then you throw away
> alternate samples to give you 150 lines. In general the process
> conceptually involves upconverting to the Lowest Common Multiple of the
> input and output sampling rates, and then decimating, but practical
> implementations use shortcuts which avoid literally doing that.
>
> You may be interested in reading my online paper on scaling:
>
> http://www.rtrussell.co.uk/filters/fdscale.html
I like that a lot.
What you didn't mention (I know you know it, but probably didn't want
to confuse things) is that in broadcast applications, trivial/rational
relationships between resolutions just aren't important any more. The
processing power to do good scaling of any arbitrary relationship is
easily available, and good upscaling now involves doing far clever
things - e.g. http://chiranjivi.tripod.com/EDITut.html - the
complexity of which totally dwarfs any additional processing for
apparently "difficult" ratios of resolutions.
1920x1080 was chosen partly because it was pretty close to what the
Japanese already used (1035 lines), square pixel, mod 8, and still
fitted into 1125 total analogue lines (chosen for the same reasons as
older analogue line standards - i.e. small prime factors = 3*3*5*5*5).
1280x720 came slightly later and was chosen as a progressive format
with a comparable raw bandwidth to 1080i, while remaining square
pixel, mod 8 (in fact they managed mod 16 with this one).
Cheers,
David.
Richard Russell
> good upscaling now involves doing far clever
> things - e.g.http://chiranjivi.tripod.com/EDITut.html
My paper is primarily concerned with downscaling, and of course the issues
are significantly different from those of upscaling. With downscaling the
problem is how to *reduce* the amount of information in an image, without
introducing defects like aliasing. You can only do that satisfactorily by
considering the frequency domain.
With upscaling the output can carry all the information present in the
input, so whilst aliasing can still occur if carried out incompetently,
frequency domain considerations are not so critical. Upscaling presents
the opportunity to 'invent' information that was not in the original
image, which is the topic of the paper you linked to. It's no more than
guesswork really, and personally I think it's a gimmick.
Richard.
http://www.rtrussell.co.uk/
bugbear
Did you consider IIR filters? In some cases they're equivalent
to enormous FIR filters.
BugBear
bugbear
Have you seen Stessen's work at Philips?
BugBear
David Paste
<davidrobin...@postmaster.co.uk> wrote:
> 1280x720 came slightly later and was chosen as a progressive format
> with a comparable raw bandwidth to 1080i, while remaining square
> pixel, mod 8 (in fact they managed mod 16 with this one).
Skooz me ignorance, but what is mod 8 and mod 16?
David Paste
> You may be interested in reading my online paper on scaling:
>
> http://www.rtrussell.co.uk/filters/fdscale.html
Thanks, an interesting read there!
Also, thanks to everyone else. This topic has made me wonder for a
while!
davidr...@postmaster.co.uk
> With upscaling the output can carry all the information present in the
> input, so whilst aliasing can still occur if carried out incompetently,
> frequency domain considerations are not so critical. Upscaling presents
> the opportunity to 'invent' information that was not in the original
> image, which is the topic of the paper you linked to. It's no more than
> guesswork really, and personally I think it's a gimmick.
Really? I'm surprised. Most high-end TVs enable "jaggies suppression"
on their scaling chips - a process which looks for diagonal lines and
knocks the pixelation off of them - like a poor man's EDI - and it's
certainly beneficial. Full blown EDI can look a little artificial /
cartoonish, but I don't think it's a gimmick if used carefully.
I don't think comparing bicubic with, say, nnedi3 here...
http://www.infognition.com/articles/video_resize_shootout.html
...shows a gimmick. YMMV!
Cheers,
David.
davidr...@postmaster.co.uk
A multiple of 8 (or 16) - beneficial because video codecs work on
blocks of this size.
Cheers,
David.
Richard Russell
> Really? I'm surprised. Most high-end TVs enable "jaggies suppression"
> on their scaling chips
What I said was a gimmick is 'inventing' (i.e. guessing) information not
present in the source image, in an attempt to make the picture appear to
be a higher resolution than it actually is. 'Jaggies' (aliasing) only
appear when the scaling is performed incompetently, e.g. with no
consideration for the frequency domain. The two things are completely
different.
> Full blown EDI can look a little artificial /
> cartoonish, but I don't think it's a gimmick if used carefully.
Any system that 'guesses' what the original scene was like will sometimes
work well and sometimes work badly. Needless to say the examples used by
its proponents are carefully chosen to look good!
There's nothing inconsistent in wanting to eliminate aliasing but being
disapproving of adding information that wasn't there in the original
image. :-)
> I don't think comparing bicubic with, say, nnedi3
> here...http://www.infognition.com/articles/video_resize_shootout.html
> ...shows a gimmick. YMMV!
As I show in my paper bicubic is a poor scaling algorithm, and you can do
much better without straying into the territories of 'edge-detection',
'enhancement' and other types of snake oil. Unfortunately the 'shootout'
you link to doesn't include a proper 'mathematical' upscaling process for
comparison - unless one of the methods is that in disguise. Judging by
their descriptions the majority of the methods are interpolation processes
in the spatial domain, and therefore miss the point entirely.
Richard.
http://www.rtrussell.co.uk/
davidr...@postmaster.co.uk
> On Tue, 15 Feb 2011 15:20:37 -0000, davidrobin...@postmaster.co.uk
OK - I'll have to try some upscaling with FFT filters to control the
frequency response. Heck, it's only like 2-D audio - I'll cope ;)
Well, maybe. We accept far more ringing in audio - nice image filters
are far far far shorter.
Do you have a paper on upscaling you can link to, or even example
images you could share? The link I posted was the first Google found -
there are a couple of better ones I remember seeing, but can't find -
I don't recall if they had a simple upscale with optimised frequency
response though.
Cheers,
David.
Richard Russell
> We accept far more ringing in audio - nice image filters
> are far far far shorter.
I routinely use 16-tap or 32-tap filters for video, and in my Colour
Recovery application there's a 47-tap FIR filter! However none of them
are used for upscaling, so what you describe as 'ringing' isn't an issue.
The CR filter plots are here:
http://colourrecovery.wikispaces.com/Response+curves
Incidentally 'ringing' is a very interesting subject in its own right,
because so many people seem to think of it as an artefact the filter
*adds*. In fact most filters can't actually *add* anything to the signal
(certainly not an FIR) and 'ringing' is simply a phenomenon caused by the
filter *taking something away*.
Richard.
http://www.rtrussell.co.uk/
Richard Russell
wrote:
> Did you consider IIR filters? In some cases they're equivalent
> to enormous FIR filters.
A filter either has a finite impulse response (in which case it's an
FIR) or it has an infinite impulse response (in which case it's an
IIR), so really you can't say one is ever "equivalent" to the other.
To the extent that one can approximate an IIR to a large FIR, it will
be an asymmetic FIR which isn't usually what you ideally want.
If computational resources are limited IIR filters can be useful, but
they involve too many compromises for my liking and they're difficult
to synthesise.
> Have you seen Stessen's work at Philips?
The name rings a bell, so I may have come across his work, but it's
not something in which I've taken any recent interest.
Richard.
http://www.rtrussell.co.uk/
davidr...@postmaster.co.uk
> On Wed, 16 Feb 2011 11:36:10 -0000, davidrobin...@postmaster.co.uk
>
> <davidrobin...@postmaster.co.uk> wrote:
> > We accept far more ringing in audio - nice image filters
> > are far far far shorter.
>
> I routinely use 16-tap or 32-tap filters for video, and in my Colour
> Recovery application there's a 47-tap FIR filter!
Ah, that'd be a baby in audio ;-)
> However none of them
> are used for upscaling, so what you describe as 'ringing' isn't an issue.
> The CR filter plots are here:
>
> http://colourrecovery.wikispaces.com/Response+curves
>
> Incidentally 'ringing' is a very interesting subject in its own right,
> because so many people seem to think of it as an artefact the filter
> *adds*. In fact most filters can't actually *add* anything to the signal
> (certainly not an FIR) and 'ringing' is simply a phenomenon caused by the
> filter *taking something away*.
Yes, I get Gibbs, I know Gaussian or cosine based filters are free
from ringing but too soft etc, but still I think "cheats" giving
sharpness without ringing are subjectively preferable for most images.
Even so, I think upscaling with Lanczos _can_ leave stepping/jaggies
when upscaling SD to HD. You could argue this only happens when the
original SD contains aliasing - but almost all SD video _does_ contain
some aliasing, so I think using some trick or other to mitigate it in
the HD version is valuable.
Anyway, would you be willing to share your thoughts on optimal image
+video upscaling? Or could that be your next great project (I don't
say that sarcastically - I know some of the fantastic stuff you've
been involved in already). Do you think the Lanczos approach (sinc,
windowed in spatial domain) is good, or would you rather tweak the
response in the frequency domain? If so, how? I've tried taking a
brick wall filter and softening it with various windows (gauss,
hanning) in the frequency domain, but nothing I've tried buys anything
above a Lanczos approach to my eyes.
There's spine36 and spline64 in AVIsynth, but they make a vanishingly
small difference IMO.
Cheers,
David.
Richard Russell
> Even so, I think upscaling with Lanczos _can_ leave stepping/jaggies
> when upscaling SD to HD.
I would expect so. Lanczos is simply a windowed sinc-filter, therefore
far from optimum, and will result in aliasing unless it uses far more taps
than strictly necessary. I always use filters optimised using the Parks
McClellan algorithm.
> You could argue this only happens when the
> original SD contains aliasing - but almost all SD video _does_ contain
> some aliasing
If the source material contains aliasing there is *nothing* you can do to
remove it. Aliasing is fundamentally inseparable from the 'wanted'
signal, which it why it's so important to avoid aliasing occurring in the
first place.
> Anyway, would you be willing to share your thoughts on optimal image
> +video upscaling?
Upscaling isn't something I've been particularly interested in. My
'campaign' is to get people to realise how important it is to think of
scaling in the frequency domain, rather than in the temporal/spatial
domain. That's absolutely vital for downscaling, because the output can
support only a reduced range of frequencies compared to the input, but
it's not so much of an issue for upscaling. There's a need to avoid
generating aliases, certainly, but you don't theoretically have to 'throw
away' any of the original signal in an upscaling process, as you do with
downscaling.
> but nothing I've tried buys anything above a Lanczos approach to my eyes.
It all depends what your priorities are. The main visible defect
resulting from the 'common' upsampling algorithms (e.g. cubic, Lanczos) is
aliasing, as it evident in the examples on the first site you linked to.
It's not difficult to synthesise an upscaling filter with far less
aliasing, but subjectively the resulting image is softer.
Part of the problem is that scaling is almost always carried out in a
'variable separable' way, that is the vertical scaling and the horizontal
scaling are done separately. If you design the filter for maximum
sharpness, the resulting image exhibits *diagonal* aliasing because it is
effectively sampled at a lower frequency diagonally than it is
horizontally or vertically.
The only straightforward way to eliminate the diagonal aliasing whilst
still using independent horizontal and vertical filters is to reduce the
cut-off frequency by a factor of root-2, but of course the sharpness
suffers considerably. This will sometimes be a better compromise, but
sometimes not, depending on the application.
I am unlikely ever to be convinced that 'guessing' information that was
not in the original image is the way forward. It obviously works well,
subjectively, in the examples you have linked to, but they are dominated
by *edges*. What happens when you present one of these algorithms with a
'texture' that happens to include a similar pattern of pixels? I reckon
it will 'invent' edges which were never in the original image!
Another issue is that algorithms that seem to work well with static images
fall over with moving images like video. A small amount of aliasing can
often be acceptable in a still image, because it adds artificial 'detail'
and gives an illusion of sharpness. However once the image starts to move
the aliasing moves *in a different direction* and the illusion is
completely lost.
I would almost always choose a soft, but alias-free, image over a
subjectively sharper image that is full of aliasing and/or invented
detail. But YMMV.
Richard.
http://www.rtrussell.co.uk/
Richard Russell
wrote:
> The only straightforward way to eliminate the diagonal aliasing whilst
> still using independent horizontal and vertical filters is to reduce the
> cut-off frequency by a factor of root-2, but of course the sharpness
> suffers considerably.
Here's what you get if you do that with the image in the paper referred to:
http://www.rtr.myzen.co.uk/upscale4.png
It is pretty free from aliases, but it's considerably less sharp as a
result. At least everything there is genuinely in the original image:
there's no 'artificial' detail being added by the scaling process.
Richard.
http://www.rtrussell.co.uk/
davidr...@postmaster.co.uk
> Part of the problem is that scaling is almost always carried out in a
> 'variable separable' way, that is the vertical scaling and the horizontal
> scaling are done separately. If you design the filter for maximum
> sharpness, the resulting image exhibits *diagonal* aliasing because it is
> effectively sampled at a lower frequency diagonally than it is
> horizontally or vertically.
Thank you - that's a new insight for me on why that happens so easily.
> The only straightforward way to eliminate the diagonal aliasing whilst
> still using independent horizontal and vertical filters is to reduce the
> cut-off frequency by a factor of root-2, but of course the sharpness
> suffers considerably. This will sometimes be a better compromise, but
> sometimes not, depending on the application.
Is there a less straightforward way? Diagonal filtering?!
> I am unlikely ever to be convinced that 'guessing' information that was
> not in the original image is the way forward. It obviously works well,
> subjectively, in the examples you have linked to, but they are dominated
> by *edges*. What happens when you present one of these algorithms with a
> 'texture' that happens to include a similar pattern of pixels? I reckon
> it will 'invent' edges which were never in the original image!
Yes, I've seen that with a low resolution video of a beach. The edges
are joined on people and beach balls as they should be, but also the
fine details of pebbles (hopelessly under-sampled and aliased) are
joined into lines too! I had to reduce the line joining thresholds
greatly to get anything watchable.
> Another issue is that algorithms that seem to work well with static images
> fall over with moving images like video. A small amount of aliasing can
> often be acceptable in a still image, because it adds artificial 'detail'
> and gives an illusion of sharpness. However once the image starts to move
> the aliasing moves *in a different direction* and the illusion is
> completely lost.
Yes, again, the low resolution videos from my old digital still camera
(which in lowest mode will point-sample 320x240 from a 6MP sensor)
exhibit this greatly.
> I would almost always choose a soft, but alias-free, image over a
> subjectively sharper image that is full of aliasing and/or invented
> detail. But YMMV.
Well, I wouldn't really want to watch any of these four...
http://chiranjivi.tripod.com/EDITut.html
...or yours...
http://www.rtr.myzen.co.uk/upscale4.png
...but if that's the only way that the content was available, I might
opt for a compromise.
There are ways of stabilising the "guesses" so that they don't do
really obvious horrible things - i.e. you can prevent things moving in
the "wrong" direction and joining up lines that aren't lines by only
applying them to things that are very certainly lines. Though this in
itself creates a threshold effect which can be annoying. Blasting it
with far too much motion compensated denoising "helps", if the motion
compensation works (which it won't in the case of the aliasing you
mention).
Given that SD content is often interlaced, and most people watch on
progressive HDTVs, I don't feel it's possible to avoid TV pictures
with some guessing. I don't think much to simple bob deinterlacing
that avoids guessing. Though I do still watch an SD CRT for now, so
don't have to suffer too much yet.
Cheers,
David.
j r powell
news:prttl6pp21oovr4k9...@4ax.com...
>
> In <5e6d9b53-b2b9-4e33...@f15g2000yqf.googlegroups.com>,
> "davidr...@postmaster.co.uk" <davidr...@postmaster.co.uk> wrote:
>
> >Given that SD content is often interlaced, and most people watch on
> >progressive HDTVs, I don't feel it's possible to avoid TV pictures
> >with some guessing. I don't think much to simple bob deinterlacing
> >that avoids guessing. Though I do still watch an SD CRT for now, so
> >don't have to suffer too much yet.
>
> credits are so rare, that I notice them immediately. "Mock The Week" has
> very fast smooth horizontal end credits. I dread to think what they look
> like on an LCD or plasma - I'm sure it sorts out the good ones from the
> bad ones!
Deinterlacing stages have been common in the UK's TV broadcast chains since
the late 1990s - they're used in so-called "broadcast-grade" ARCs (and any
other piece of broadcast kit which upscales or downscales interlaced video).
A progressive video signal is used internally by said kit in order to make
adequate scaling decisions when resizing.
Scrolling text is actually one of the few things which deinterlacing doesn't
inherently blur or otherwise spoil, as it moves steadily and predictably and
consists of relatively uncomplex and well-defined 'patterns'.
Save for a few sets with unusually poor image processors, the 'blurring' of
said text on LCDs is more an artefact of the display technology than the
deinterlacing.
As an aside, I wonder if the downscalers used to convert 625 lines to 405
deinterlaced? I'm guessing that they just took one field at a time and
rescaled it.
> The majority of graphics seems to have been dumbed down to 25Hz motion :-(
I've not noticed that, but there has been a long-running issue on Channel4
whereby scrolling credits are reduced to 25fps and become unreadable when
the 'playout people' cut in and superimpose promo graphics over the
programme source.
On a related note, has C4's laggy chroma issue (resulting from incorrect use
of the progressive version of 4:2:0 chroma subsampling for interlaced
material I presume) been fixed yet?
Richard Russell
> Given that SD content is often interlaced, and most people watch on
> progressive HDTVs, I don't feel it's possible to avoid TV pictures
> with some guessing. I don't think much to simple bob deinterlacing
> that avoids guessing.
Given my background (!) I don't think you can go far wrong with a Martin
Weston-style Vertical-Temporal de-interlacing filter:
http://neuron2.net/misc/USP4789893.pdf
Even in its static form it's been good enough for all the de-interlacing
I've ever needed to do. If you're fussy a little bit of motion steering
can improve it.
Sadly, despite its simplicity and remarkably good performance, the very
fact that it's patented puts some manufacturers off using it.
Richard.
http://www.rtrussell.co.uk/
Roderick Stewart
> As an aside, I wonder if the downscalers used to convert 625 lines to 405
> deinterlaced? I'm guessing that they just took one field at a time and
> rescaled it.
No they didn't. The technology of the day wouldn't have made it feasible,
and it wasn't necessary anyway, as input and output standards were both
interlaced and had the same frame rate. They didn't even store an entire
field, but just a few lines.
Rod.
--
Virtual Access V6.3 free usenet/email software from
http://sourceforge.net/projects/virtual-access/
Richard Russell
<rj...@escapetime.removethisbit.myzen.co.uk> wrote:
> and it wasn't necessary anyway, as input and output standards were both
> interlaced and had the same frame rate.
Entirely wrong! If the number of lines is different, deinterlacing is
required: you can't perform (quality) vertical scaling on an interlaced
field, because of the aliasing. So for a 576i to 376i (625 to 405)
conversion you need to deinterlace the 576i to 576p, vertically scale the
576p to 376p, then discard alternate lines to give 376i.
Of course the original 1970s-era converters didn't do this, because a
deinterlacer requires a field-store and that was beyond the practical
technology available at the time. Therefore they simply interpolated the
interlaced field, with inevitably poor results. But given that they were
only providing a legacy 405-line service that didn't really matter.
If one considers the modern 'equivalent', that is converting 1080i to
576i, a deinterlacer would always be used to get the best results (i.e.
1080i -> 1080p -> 576p -> 576i). I have little doubt that the Snell
HD-to-SD downconverters use the deinterlacer I mentioned in the previous
post, because Martin Weston works for them! I've recently written a
software downconverter (for the BBC) that works the same way.
Richard.
http://www.rtrussell.co.uk/
charles
Richard Russell <ne...@rtrussell.co.uk> wrote:
> On Sat, 19 Feb 2011 06:06:18 -0000, Roderick Stewart
> <rj...@escapetime.removethisbit.myzen.co.uk> wrote:
> > and it wasn't necessary anyway, as input and output standards were both
> > interlaced and had the same frame rate.
> Entirely wrong! If the number of lines is different, deinterlacing is
> required: you can't perform (quality) vertical scaling on an interlaced
> field, because of the aliasing. So for a 576i to 376i (625 to 405)
> conversion you need to deinterlace the 576i to 576p, vertically scale the
> 576p to 376p, then discard alternate lines to give 376i.
> Of course the original 1970s-era converters didn't do this, because a
> deinterlacer requires a field-store and that was beyond the practical
> technology available at the time. Therefore they simply interpolated the
> interlaced field, with inevitably poor results. But given that they
> were only providing a legacy 405-line service that didn't really matter.
But - there was also a 405 < 625 one used for acessing archive tapes.
--
From KT24
Using a RISC OS computer running v5.16
Roderick Stewart
> > and it wasn't necessary anyway, as input and output standards were both
> > interlaced and had the same frame rate.
>
> Entirely wrong! If the number of lines is different, deinterlacing is
> required: you can't perform (quality) vertical scaling on an interlaced
> field, because of the aliasing.
To the best of my recollection, interpolation between 625 and 405 lines was
done on individual fields, with only a part of a field in storage, but I
don't recall any of the horrible effects that can frequently be seen
nowadays when elaborate computer manipulations are performed on interlaced
video sources. The conversion being carried out was very simple in
comparison with many routine things we do today.
j r powell
news:VA.00000a4...@escapetime.removethisbit.myzen.co.uk...
> To the best of my recollection, interpolation between 625 and 405 lines
> was
> done on individual fields, with only a part of a field in storage, but I
> don't recall any of the horrible effects that can frequently be seen
> nowadays when elaborate computer manipulations are performed on interlaced
> video sources. The conversion being carried out was very simple in
> comparison with many routine things we do today.
There are pros and cons, but personally I'd tend to agree - accurate motion
tracking and lack of motion blur is most important to my perception of
quality. I'd rather preserve that 'genuine film and video feel' by avoiding
any deinterlacing stage even if it meant the vertical scaling was
"sub-optimal".
In many ARCs and flat panel TVs, the deinterlacing combined with the scaling
makes much of their output so 'soft' that a bit of aliasing would actually
be welcome, simply to give one's eyes something sharp on the screen to focus
on.
MPEG compression spoils the modern TV experience too, but this is the
massive 20,000lb white elephant in the middle of the room, so we're not
supposed to mention it.
j r powell
news:51a802c7...@charleshope.demon.co.uk...
I wonder if they actually interpolated at all, or simply repeated certain
lines for 377i -> 576i and discarded certain ones for 576i -> 377i.
If this were the case, it would be possible to digitally recover the
original 377i line structure from an upconverted 576i recording, then
perform "modern style" upconversion with scaling and deinterlacing.
I've seen upconverted 405 recordings on TV which exhibit 'mice teeth' during
motion however, so if the convertors only worked on one field at a time,
what caused this to occur?
Richard Russell
> I'd rather preserve that 'genuine film and video feel' by avoiding any
> deinterlacing stage even if it meant the vertical scaling was
> "sub-optimal".
What makes you think that a 'deinterlacing stage' would not preserve the
'genuine video feel'? That might be true of some poor deinterlacers, but
if you read the patent to which I linked, you'll see that a fundamental
characteristic of Martin Weston's method is that low vertical frequencies
come *only from the current field*. So the end result exhibits 'video
motion' (50 Hz) as you would want, not 'film motion' (25 Hz).
This is the really clever aspect of his vertical-temporal filter. If you
add together all the coefficients for contributions from adjacent fields
you'll find that they sum to zero. It's only high vertical frequencies
(vertical detail) that come from those fields. It's a work of genius!
> In many ARCs and flat panel TVs, the deinterlacing combined with the
> scaling makes much of their output so 'soft'
Try a Snell & Wilcox ARC (or my software ARC based on the same principles,
or for that matter my award-winning '2D DVE for Virtual Studios'). You
won't find that to be the case.
> I wonder if they actually interpolated at all
Yes, they did. If you look at this report on the IBA converter you'll see
that it used a 4-line interpolator:
http://www.domino405.co.uk/documents/EXP_Converter.pdf
> I've seen upconverted 405 recordings on TV which exhibit 'mice teeth'
> during motion however, so if the convertors only worked on one field
> at a time, what caused this to occur?
Most probably what you were seeing was an optical standards conversion (a
625-line camera looking at a 405-line monitor) or it might have been a
film telerecording subsequently converted back to video in a telecine. In
either case you might expect to see both fields superimposed.
Richard.
http://www.rtrussell.co.uk/
Andy Champ
>
> Entirely wrong! If the number of lines is different, deinterlacing is
> required: you can't perform (quality) vertical scaling on an interlaced
> field, because of the aliasing. So for a 576i to 376i (625 to 405)
> conversion you need to deinterlace the 576i to 576p, vertically scale
> the 576p to 376p, then discard alternate lines to give 376i.
>
> Of course the original 1970s-era converters didn't do this, because a
> deinterlacer requires a field-store and that was beyond the practical
> technology available at the time. Therefore they simply interpolated the
> interlaced field, with inevitably poor results. But given that they were
> only providing a legacy 405-line service that didn't really matter.
>
> If one considers the modern 'equivalent', that is converting 1080i to
> 576i, a deinterlacer would always be used to get the best results (i.e.
> 1080i -> 1080p -> 576p -> 576i). I have little doubt that the Snell
> HD-to-SD downconverters use the deinterlacer I mentioned in the previous
> post, because Martin Weston works for them! I've recently written a
> software downconverter (for the BBC) that works the same way.
>
Richard,
going from interlaced to non-interlaced results in severe artefacts on
vertical edges of horizontally moving objects (as I have no doubt you
know well!).
When you convert the way you suggest how do you get rid of these artefacts?
Andy (not arguing, just confused)
Steve Thackery
> There are pros and cons, but personally I'd tend to agree - accurate
> motion tracking and lack of motion blur is most important to my
> perception of quality.
Interestingly I have a problem in cinemas with panning. 24fps just
isn't enough for a smooth pan - the rapid jumping stands out a mile to
me.
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.
Loads of people seem entirely happy with 24fps* in a cinema, and 50Hz
on a TV.
SteveT
*I realise each cinema frame is "flashed" two or three times to reduce
flicker, but of course that's not going to smooth out a pan, which
still makes 24 jumps per second.
Richard Russell
wrote:
> going from interlaced to non-interlaced results in severe artefacts on
> vertical edges of horizontally moving objects (as I have no doubt you
> know well!).
Let's see if I've got this straight: you have a horizontally-moving object
with vertical edges, so it might be a simple rectangle or square moving
from left-to-right or right-to-left. Is that correct? The Martin Weston
de-interlacer, to which I linked, won't result in "severe artefacts" on
the vertical edges, in fact it won't result in *any* artefacts on the
vertical edges!
As I explained, with his de-interlacer all low vertical frequencies come
only from the current (central) field. Since a vertical edge has *no*
vertical frequency component at all (confusingly, it's horizontal edges
that have a lot of vertical energy!) the output from the de-interlacer in
that region will come entirely from just one field.
The only parts of the picture which may exhibit some artefacts will be the
top and bottom *horizontal* edges of the moving object, which will contain
a contribution from the adjacent (previous and following) fields. So you
may see artefacts near the corners of the object if you look very
carefully.
> When you convert the way you suggest how do you get rid of these
> artefacts?
They simply don't occur. That is the beauty of that particular
de-interlacer.
Richard.
http://www.rtrussell.co.uk/
Max Demian
news:SrCdnUU9bYHW9_zQ...@bt.com...
>j r powell wrote:
>
>> There are pros and cons, but personally I'd tend to agree - accurate
>> motion tracking and lack of motion blur is most important to my
>> perception of quality.
>
> Interestingly I have a problem in cinemas with panning. 24fps just isn't
> enough for a smooth pan - the rapid jumping stands out a mile to me.
>
> 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.
>
> Loads of people seem entirely happy with 24fps* in a cinema, and 50Hz on a
> TV.
You are obviously a superior being. I'm sorry our motion picture technology
is inadequate for you.
--
Max Demian
Richard Russell
wrote:
> Interestingly I have a problem in cinemas with panning. 24fps just
> isn't enough for a smooth pan - the rapid jumping stands out a mile to
> me.
And to most people. It is an indisputable fact that 24 fps, flashed twice
or three times per frame to reduce flicker, doesn't create the illusion of
smooth continuous motion. Even film enthusiasts don't claim that it does
(at least, not many!).
What film enthusiasts will claim is that we have grown to *like* (or at
least have become accustomed to) the motion artefacts and somehow
associate them with a particular cinema 'experience'. It is in an attempt
to reproduce this experience - but not to improve the realism - that some
TV producers and directors like to shoot at 24 or 25 fps (or 'filmise'
video material to create a similar effect).
> Loads of people seem entirely happy with 24fps* in a cinema, and 50Hz on
> a TV.
Americans, who are accustomed to 60Hz TV, often notice the 50Hz flicker
for a while, but they (mostly) gradually get used to it and eventually
can't see it any more.
Richard.
j r powell
>
> On Sun, 20 Feb 2011 16:03:26 -0000, j r powell <no...@invalid.com> wrote:
>
> > I'd rather preserve that 'genuine film and video feel' by avoiding any
> > deinterlacing stage even if it meant the vertical scaling was
> > "sub-optimal".
>
> What makes you think that a 'deinterlacing stage' would not preserve the
> 'genuine video feel'? That might be true of some poor deinterlacers, but
> if you read the patent to which I linked, you'll see that a fundamental
> characteristic of Martin Weston's method is that low vertical frequencies
> come *only from the current field*. So the end result exhibits 'video
> motion' (50 Hz) as you would want, not 'film motion' (25 Hz).
>
> This is the really clever aspect of his vertical-temporal filter. If you
> add together all the coefficients for contributions from adjacent fields
> you'll find that they sum to zero. It's only high vertical frequencies
> (vertical detail) that come from those fields. It's a work of genius!
Just to clarify, I never suggested that deinterlacing inherently reduced a
source's 50Hz temporal resolution to 25Hz.
The issue is of course how much resemblence the 50Hz progressive output
bears to the input, both in terms of motion tracking and image definition.
I realise that film sources do not require deinterlacing however, and that
modern ARCs et al employ pulldown detection to recognise said sources and
deal with them accordingly (ie. by ensuring that the correct fields are
paired together on the progressive output, but leaving the actual content of
said fields completely unmodified) .
I presume you are referring to the patent at
http://neuron2.net/misc/USP4789893.pdf (it's been a while since you linked
to it).
I did read it.
To be honest though, I thought all 'professional grade' deinterlacers
included most of the features it describes.
The patent says: "...low vertical frequencies come solely from the current
field and are thus free of movement blur. Higher vertical frequency
components come partly from the current field and partly from the adjacent
fields. An improved vertical resolution is thus achieved, on stationary
pictures, by the incorporation of information from adjacent fields. On
moving pictures the contribution from the adjacent fields is out of phase
and the vertical resolution is reduced (by the same amount as the increase
on stationary pictures) but this loss of vertical detail on moving pictures
is subjectively much less serious than the movement blur produced by
previous [deinterlacing] methods."
So it acknowledges that moving objects are subject to a loss of vertical
resolution (which still counts as blurring in my book).
If only the two adjacent lines in the current field were used as the
contribution for moving objects in the new line, this loss would (I think)
not increase beyond the level one would expect from a basic 'bob'
deinterlacer.
Would it not be the case however, that fast/erratic movement of an object
which consisted of complex/detailed irregular patterns (such as the jerky
movements of an animal with 'exotic' markings) could still cause the
blurring effect to increase beyond this level? The reason being that even
moving content on a newly-generated line contains some high frequency
contributions from lines in other fields (an average value derived from 14
other lines representing 3 different points in time, but not in equal
measures afaict). So the more extreme and erratic the variation is between
said lines, the less representative this average value will be?
Either way, Fig 6 shows considerably large vertical high frequency losses on
the deinterlaced output compared to the input (even on stationary images)
and seems to show an increase in loss which is proportional to motion speed.
Those losses are already introduced before any upscaling or downscaling has
been applied.
I am not sure if some implementations of the software detect and distinguish
between moving and stationary objects within a frame (a sort of pulldown
detection working on localised areas of the image) to eradicate all high
frequency loss from stationary objects?
Also, when the input source switches between cameras without a cross-fade,
the 3-field principle would not be valid for 2 newly-generated frames - I
presume this is detected also.
At least the loss on the basic convertors used for 405 lines (way before my
time) was constant (and therefore would be less noticible to me - I tend to
perceive any adaptive processing as a "deliberate" interference).
> > I wonder if they actually interpolated at all
>
> Yes, they did. If you look at this report on the IBA converter you'll see
> that it used a 4-line interpolator:
>
> http://www.domino405.co.uk/documents/EXP_Converter.pdf
I'll finish reading that when I have more time, but it does refer to a
digital convertor which is a proposed replacement for "the 37 analogue
electric line convertors used by the IBA" - it was to the latter type which
I was referring, since I don't think the majority of them were ever replaced
with digital ones in the end?
> > I've seen upconverted 405 recordings on TV which exhibit 'mice teeth'
> > during motion however, so if the convertors only worked on one field
> > at a time, what caused this to occur?
>
> Most probably what you were seeing was an optical standards conversion (a
> 625-line camera looking at a 405-line monitor) or it might have been a
> film telerecording subsequently converted back to video in a telecine. In
> either case you might expect to see both fields superimposed.
So presumably transfers made using the 'stored field' technique?
( http://en.wikipedia.org/wiki/Kinescope#Stored_field )
j r powell
news:SrCdnUU9bYHW9_zQ...@bt.com...
> Interestingly I have a problem in cinemas with panning. 24fps just isn't
> enough for a smooth pan - the rapid jumping stands out a mile to me.
>
> 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.
>
> Loads of people seem entirely happy with 24fps* in a cinema, and 50Hz on a
> TV.
So you're basically saying "24fps film and 50Hz TV are shit anyway, so why
bother trying to optimise them".
Thanks Thickery. Those are very basic and obvious artefacts you've
mentioned, which anyone could spot. You don't win a prize.
fwiw my eyes can detect your 85Hz CRT flicker too, but not 100Hz.
j r powell
> What film enthusiasts will claim is that we have grown to *like* (or at
> least have become accustomed to) the motion artefacts and somehow
> associate them with a particular cinema 'experience'. It is in an attempt
> to reproduce this experience - but not to improve the realism - that some
> TV producers and directors like to shoot at 24 or 25 fps (or 'filmise'
> video material to create a similar effect).
Surely nowadays it's also done by TV producers to avoid those deinterlacing
artefacts, since there exists something of a two-tier trade-off between
temporal and vertical resolution.
Roderick Stewart
> > 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.
Roderick Stewart
wrote:
> Interestingly I have a problem in cinemas with panning. 24fps just
> isn't enough for a smooth pan - the rapid jumping stands out a mile to
> me.
You're not alone. 24 fps never has been enough to give a smooth rendition
of motion, but film stock is expensive, so I suspect 24fps was simply the
lowest acceptable to most people for reasons of cost. When cine film was
invented, it probably seemed miraculous that movement in images could be
depicted at all, and we've been stuck with the most commercially
successful system ever since.
I think it's particularly unfortunate that the measures taken by the film
fetishists to "improve" televison to match what they see as a superior
system should include the destruction of one of its main advantages. Film
can indeed be claimed to be superior to television in some respects, but
not this one.
Richard Russell
> To be honest though, I thought all 'professional grade' deinterlacers
> included most of the features it describes.
I think you'll find that most alternative 'professional grade'
deinterlacers don't work as well, certainly not when you consider how
simple it is, and that it's 'non adaptive' (i.e. a static
vertical-temporal filter). As I said, the fact that the technique is
patented does put off some potential users. Others, I suspect, simply
have never come across it.
> So it acknowledges that moving objects are subject to a loss of vertical
> resolution (which still counts as blurring in my book).
Considering that a vertically-moving object (depending on its speed)
cannot be represented by an interlaced signal in the first place - it's a
fundamental shortcoming of interlace - you're trading off aliasing in the
interlaced case with some slight blurring in the progressive case.
Subjectively there's unlikely to be much in it.
It's widely acknowledged that Snell (& Wilcox) make the best Aspect Ratio
Converters and Standards Converters in the world. It's no coincidence
that the de-interlacer we are discussing is used in their products.
> If only the two adjacent lines in the current field were used as the
> contribution for moving objects in the new line
But you can't do that, and expect to get good results. Mathematically you
can't interpolate a signal which is sub-Nyquist sampled, and the lines in
individual fields of an interlaced signal are sub-Nyquist sampled.
> I am not sure if some implementations of the software detect and
> distinguish between moving and stationary objects within a frame
As I mentioned before, you can add motion steering to the Weston
deinterlacer to improve its performance, but it's rarely worthwhile (the
improvement you get is small for a large increase in complexity). I've
never done it in any of my hardware or software implementations.
Richard.
http://www.rtrussell.co.uk/
charles
Roderick Stewart <rj...@escapetime.removethisbit.myzen.co.uk> wrote:
> In article <ijre2u$i3n$1...@speranza.aioe.org>, 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.
576 to be precise.
davidr...@postmaster.co.uk
> On Fri, 18 Feb 2011 17:26:49 -0000, davidrobin...@postmaster.co.uk
>
> <davidrobin...@postmaster.co.uk> wrote:
> > Given that SD content is often interlaced, and most people watch on
> > progressive HDTVs, I don't feel it's possible to avoid TV pictures
> > with some guessing. I don't think much to simple bob deinterlacing
> > that avoids guessing.
>
> Given my background (!) I don't think you can go far wrong with a Martin
> Weston-style Vertical-Temporal de-interlacing filter:
>
> http://neuron2.net/misc/USP4789893.pdf
>
> Even in its static form it's been good enough for all the de-interlacing
> I've ever needed to do. If you're fussy a little bit of motion steering
> can improve it.
>
> Sadly, despite its simplicity and remarkably good performance, the very
> fact that it's patented puts some manufacturers off using it.
Which is a bit bizarre, given that the patent expired a few years ago.
I wonder if there's any freely available software that implements it?
Cheers,
David.
davidr...@postmaster.co.uk
> On Sat, 19 Feb 2011 06:06:18 -0000, Roderick Stewart
>
> > and it wasn't necessary anyway, as input and output standards were both
> > interlaced and had the same frame rate.
>
> Entirely wrong! If the number of lines is different, deinterlacing is
> required: you can't perform (quality) vertical scaling on an interlaced
> field, because of the aliasing. So for a 576i to 376i (625 to 405)
> conversion you need to deinterlace the 576i to 576p, vertically scale the
> 576p to 376p, then discard alternate lines to give 376i.
>
> Of course the original 1970s-era converters didn't do this, because a
> deinterlacer requires a field-store and that was beyond the practical
> technology available at the time. Therefore they simply interpolated the
> interlaced field, with inevitably poor results. But given that they were
> only providing a legacy 405-line service that didn't really matter.
>
> If one considers the modern 'equivalent', that is converting 1080i to
> 576i, a deinterlacer would always be used to get the best results (i.e.
> 1080i -> 1080p -> 576p -> 576i).
Given that a full resolution 576p signal would require vertical
filtering to avoid twitter at 576i, (and, arguably, the 1080i signal
should also have been restricted in the same way, if only optically),
then the quality of the 1080i>1080p step is almost irrelevant. Single
field resizing (with the appropriate offset) really does look as good.
If the wanted output is 576p then it's a different kettle of fish -
proper deinterlacing at 1080i>1080p does visibly help - but for a
final output of CRT friendly 576i, I defy anyone to see a difference
worth mentioning.
FWIW some earlier genuine 50i HD>SD conversions broadcast on the BBC
included horrendous aliasing. I remember watching some ice skating a
few years back - one of the early native HD events downconverted for
SD - and the lines at the edge of the rink were flickering and full of
jaggies (50Hz CRT). It looked very sharp of course, but quite
horrible.
Cheers,
David.
Richard Russell
> Given that a full resolution 576p signal would require vertical
> filtering to avoid twitter at 576i, (and, arguably, the 1080i signal
> should also have been restricted in the same way, if only optically),
> then the quality of the 1080i>1080p step is almost irrelevant.
There's no doubt that the benefit of the 1080i -> 1080p step is small, for
the reason you state, but I certainly consider it worth doing, and my
software HD to SD downconverter that I've recently written for the Beeb
does.
This is largely because it isn't actually a separate step at all! In
practice everything takes place in one filtering operation, with 1080i in
and 576i out. Because the 'Weston' deinterlacer is a simple, static,
vertical-temporal filter (and assuming the temporal element has a 'one
sided' 2-field aperture rather than a symmetrical 3-field aperture as in
the patent) it amounts to just a simple vertical filter on the input
*frame*.
Since I'm working with files and therefore everything is frame-based,
there's no extra effort in building a filter that looks at frame lines
rather than field lines. I just convolve the coefficients of my
downscaling filter with the coefficients of the deinterlacing filter and
Bob's your Uncle.
> I defy anyone to see a difference worth mentioning.
When the extra effort involved in doing it 'properly' is negligible you
might as well do it, even if the benefit is small. Certainly it gives me
some satisfaction that my HD to SD downconverter does interpolate lines
from two input fields rather than one.
Richard.
http://www.rtrussell.co.uk/
Richard Russell
> I wonder if there's any freely available software that implements it?
I would be prepared to make my software implementations more widely
available, especially if the patent has expired. I have an SD ARC, an HD
ARC and the HD to SD downconverter, all of which use the 'Weston'
deinterlacer. They are Windows executables working with QuickTime
video-only files (there are also AVI versions of the ARCs, but not of the
downconverter).
Richard.
http://www.rtrussell.co.uk/
davidr...@postmaster.co.uk
> On Mon, 21 Feb 2011 12:51:38 -0000, davidrobin...@postmaster.co.uk
>
> <davidrobin...@postmaster.co.uk> wrote:
> > Given that a full resolution 576p signal would require vertical
> > filtering to avoid twitter at 576i, (and, arguably, the 1080i signal
> > should also have been restricted in the same way, if only optically),
> > then the quality of the 1080i>1080p step is almost irrelevant.
>
> There's no doubt that the benefit of the 1080i -> 1080p step is small, for
> the reason you state, but I certainly consider it worth doing, and my
> software HD to SD downconverter that I've recently written for the Beeb
> does.
>
> This is largely because it isn't actually a separate step at all! In
> practice everything takes place in one filtering operation, with 1080i in
> and 576i out. Because the 'Weston' deinterlacer is a simple, static,
> vertical-temporal filter (and assuming the temporal element has a 'one
> sided' 2-field aperture rather than a symmetrical 3-field aperture as in
> the patent) it amounts to just a simple vertical filter on the input
> *frame*.
Yes, I see what you mean - it's no more effort than bobbing and
resizing. Maybe even less effort.
> Since I'm working with files and therefore everything is frame-based,
> there's no extra effort in building a filter that looks at frame lines
> rather than field lines. I just convolve the coefficients of my
> downscaling filter with the coefficients of the deinterlacing filter and
> Bob's your Uncle.
Can you share the coefficients for the 2-field version? I reckon I can
do a same-rate deinterlacer using those in mt_convolution in AVIsynth
quite easily. (I couldn't do the 3-field version easily like that).
While I wouldn't choose to use a same-rate deinterlacer, at least it
would let me see something of the algorithm in action.
Cheers,
David.
P.S. and having owned and used Acorn Electron (yes, I was poor) I
can't help having a geeky admiration that you're doing all this in BBC
BASIC!
davidr...@postmaster.co.uk
> On Mon, 21 Feb 2011 12:41:09 -0000, davidrobin...@postmaster.co.uk
>
> <davidrobin...@postmaster.co.uk> wrote:
> > I wonder if there's any freely available software that implements it?
>
> I would be prepared to make my software implementations more widely
> available, especially if the patent has expired. I have an SD ARC, an HD
> ARC and the HD to SD downconverter, all of which use the 'Weston'
> deinterlacer. They are Windows executables working with QuickTime
> video-only files (there are also AVI versions of the ARCs, but not of the
> downconverter).
That would be brilliant!
The US patent was granted in 1988. They only last 17 or 20 years in
the USA (depends on original filing date). The European patent was
filed in 1987 (covering DE, FR and NL only), and EU patents last 20
years from date of filing. The original filing was in the UK in 1986
and 1987, but I can't find the UK patent on Espacenet. Might be
misfiled or have a typo in the metadata or some other strangeness. In
any case, it's more than 20 years since filing, so has now expired.
Obviously Martin Weston has been busy at Snell since then, and if he's
made any refinements to the process and patented them more recently,
they could still be covered (though it doesn't sound like you've
included them in your code, if they exist).
Research is exempt from patent infringement claims in the UK (and lots
of other countries, though not so much the USA). So arguably you're
free to play with any of this if you're just seeing what can be done.
Cheers,
David.
P.S. I am not a lawyer - this advice is worth what you paid for it ;)
Richard Russell
> On Feb 21, 2:45 pm, "Richard Russell" <n...@rtrussell.co.uk> wrote:
>> I would be prepared to make my software implementations more widely
>> available
>
> That would be brilliant!
Here's the HD to SD downconverter:
http://www.rtr.myzen.co.uk/HDtoSD.zip
This is made available on an 'as is' basis with absolutely no warranty as
to quality or functionality! Use at your own risk.
It requires QuickTime for Windows to be installed on the PC:
http://www.apple.com/quicktime/download/
The Aspect Ratio Converters would be a better demonstration of the
deinterlacer because you can see it working directly, but they are a bit
old (pre-Vista) and need updating before I'd be able to release them.
Richard.
http://www.rtrussell.co.uk/
j r powell
> I think you'll find that most alternative 'professional grade'
> deinterlacers don't work as well, certainly not when you consider how
> simple it is, and that it's 'non adaptive' (i.e. a static
> vertical-temporal filter).
Non-adaptive in a manor of speaking, but the amount of loss still varies in
response to the input signal, which is what catches my attention when
viewing.
> Considering that a vertically-moving object (depending on its speed)
> cannot be represented by an interlaced signal in the first place - it's a
> fundamental shortcoming of interlace - you're trading off aliasing in the
> interlaced case with some slight blurring in the progressive case.
> Subjectively there's unlikely to be much in it.
Horizontally-moving objects can be represented by a native interlaced signal
however, whereas they (afaict) suffer largely the same loss as
vertically-moving ones in this deinterlacer.
Also, if the content is to be reinterlaced in a broadcast chain, this
compounds the associated problems.
> > If only the two adjacent lines in the current field were used as the
> > contribution for moving objects in the new line
>
> But you can't do that, and expect to get good results. Mathematically you
> can't interpolate a signal which is sub-Nyquist sampled, and the lines in
> individual fields of an interlaced signal are sub-Nyquist sampled.
I know it yields poor results, but it's been done nontheless :)
Sometimes there are images which only appear in one field (such as the flash
of cameras or fireworks, or the shimmering reflection of light from a
'glittery' dress).
I suppose I prefer to watch (uncompressed) native interlaced material on a
CRT because every piece of information displayed is a direct impression of
what the camera picked up, rather than average values derived from an
interpolator, the accuracy of which will not be consistent across different
content.
My brain seems to do a better job of 'filling in the vertical gaps' between
field lines than a computer does, which is perhaps why interlaced CRT
technology worked so well, and why the aliasing contained within single
fields was seldom apparent to the viewer.
JohnT
"j r powell" <no...@invalid.com> wrote in message
news:ijugv3$dae$1...@speranza.aioe.org...
> "Richard Russell" wrote in message news:op.vq8ynxzan5ksl5@richard...
>
>> I think you'll find that most alternative 'professional grade'
>> deinterlacers don't work as well, certainly not when you consider how
>> simple it is, and that it's 'non adaptive' (i.e. a static
>> vertical-temporal filter).
>
> Non-adaptive in a manor of speaking, but the amount of loss still varies
> in response to the input signal, which is what catches my attention when
> viewing.
WTF is a manor of speaking?
--
JohnT
j r powell
> WTF is a manor of speaking?
T'was a test to see which sneery little clueless dimwit would be first to
take a cheap shot, so congratulations - you've won a rotten potato.
Andy Champ
> On Sun, 20 Feb 2011 19:23:22 -0000, Andy Champ <no....@nospam.invalid>
> wrote:
>
>> going from interlaced to non-interlaced results in severe artefacts on
>> vertical edges of horizontally moving objects (as I have no doubt you
>> know well!).
>
> Let's see if I've got this straight: you have a horizontally-moving
> object with vertical edges, so it might be a simple rectangle or square
> moving from left-to-right or right-to-left. Is that correct? The Martin
> Weston de-interlacer, to which I linked, won't result in "severe
> artefacts" on the vertical edges, in fact it won't result in *any*
> artefacts on the vertical edges!
>
Yes, that's the effect... sometimes known as "combing".
> As I explained, with his de-interlacer all low vertical frequencies come
> only from the current (central) field. Since a vertical edge has *no*
> vertical frequency component at all (confusingly, it's horizontal edges
> that have a lot of vertical energy!) the output from the de-interlacer
> in that region will come entirely from just one field.
>
... And I'll now rummage back through the thread to find the answer.
See you later...
> The only parts of the picture which may exhibit some artefacts will be
> the top and bottom *horizontal* edges of the moving object, which will
> contain a contribution from the adjacent (previous and following)
> fields. So you may see artefacts near the corners of the object if you
> look very carefully.
>
I've gone back and re-read "A Frequency Domain approach to Scaling" and
that hasn't helped me. And I can't see you linking to anything else
relevant... though you did mention Martin Weston's Patent, which I can
see on line. Now I hate reading patents; they're not designed as a
technical description, but as a way to persuade a judge that you
invented something before someone else did. Oh well...
>> When you convert the way you suggest how do you get rid of these
>> artefacts?
>
> They simply don't occur. That is the beauty of that particular
> de-interlacer.
>
OK (somewhat later) see if I have this right. You interpolate between
lines in one of the fields to get a pretty good idea of what the
intervening lines would have been; use of frequency based filters as in
your paper help to get this interpolation fairly accurate. You also
interpolate in an adjacent field. But that's not what is used directly;
instead you calculate a difference from the two fields, and use that to
enhance the interpolated values, and that gives you a pretty good idea
of the state that the picture would have had at a point half-way in time
between the two frames, and half-way in vertical space between the lines
of one frame and the lines of the other.
Given that I can see (even though I'm not following all the details) how
the combing goes.
This signal is a 576-line signal (if we're PAL).
Repeating this between the 2nd field and the 3rd field gives us another
576-line frame, representing a time half-way between the 2nd and 3rd
frames, so we now have a 50Hz, 576 line signal which is a pretty good
shot at what a real 50p signal would have been.
Some kinds of high frequency detail will be lost. It won't be able to
tell two closely space flashes from one long one (VW tail-lights, for
instance...) nor will it be able to properly cope with highly detailed
objects moving at variable speed (the legs of a cheetah would be a
challenge!). But these are exactly the kinds of areas that MPEG falls
over on, and no-one seems to care about that.
Andy
Richard Russell
wrote:
> And I can't see you linking to anything else relevant... though you did
> mention Martin Weston's Patent
Yes, I linked to it:
http://neuron2.net/misc/USP4789893.pdf
> Now I hate reading patents; they're not designed as a technical
> description, but as a way to persuade a judge that you invented
> something before someone else did.
Don't read the words, look at the pictures (particularly Figures 3 & 5,
nicely hand drawn)! They tell you exactly the coefficients Martin used so
you can easily reproduce the filters, although the variant I use has less
HF loss and isn't in the patent.
> OK (somewhat later) see if I have this right.
I don't think so. Your description didn't seem to match my understanding
of how it works. The essence can be found in the frequency response
graphs (e.g. Figures 4 & 6 in the patent) but you do need to be able to
'think' in the (vertical-temporal) frequency domain.
> Repeating this between the 2nd field and the 3rd field gives us another
> 576-line frame, representing a time half-way between the 2nd and 3rd
The Weston deinterlacer generates an output temporally coincident with an
input field, not half-way between fields. You can tell that simply by
noticing that the filter has a symmetrical aperture with an *odd* number
of fields (3), so the centre must be coincident with a field. To generate
a frame representing a time half-way between fields would require an
even-number aperture.
Richard.
http://www.rtrussell.co.uk/
Richard Russell
> I suppose I prefer to watch (uncompressed) native interlaced material on
> a CRT
So do I, although the opportunity rarely presents itself these days. I am
proud to say that the PC on which I'm typing this still has a CRT monitor!
> because every piece of information displayed is a direct impression of
> what the camera picked up, rather than average values derived from an
> interpolator, the accuracy of which will not be consistent across
> different content.
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.
Richard.
http://www.rtrussell.co.uk/
John Legon
> Here's the HD to SD downconverter:
>
> http://www.rtr.myzen.co.uk/HDtoSD.zip
What did you use for that - BBC BASIC? ;-)
And a bit of assembler as well, no doubt...
--
John L
davidr...@postmaster.co.uk
> On Mon, 21 Feb 2011 18:19:19 -0000, davidrobin...@postmaster.co.uk
>
> <davidrobin...@postmaster.co.uk> wrote:
> > On Feb 21, 2:45 pm, "Richard Russell" <n...@rtrussell.co.uk> wrote:
> >> I would be prepared to make my software implementations more widely
> >> available
>
> > That would be brilliant!
>
> Here's the HD to SD downconverter:
>
> http://www.rtr.myzen.co.uk/HDtoSD.zip
>
> This is made available on an 'as is' basis with absolutely no warranty as
> to quality or functionality! Use at your own risk.
>
> It requires QuickTime for Windows to be installed on the PC:
>
> http://www.apple.com/quicktime/download/
>
> The Aspect Ratio Converters would be a better demonstration of the
> deinterlacer because you can see it working directly, but they are a bit
> old (pre-Vista) and need updating before I'd be able to release them.
All XP here.
I've bitten the bullet and installed QuickTime (I haven't used it for
a decade), and now need to find a free AVI to MOV converter -
preferably that doesn't transcode.
(The idea of using QuickTime for something useful, or even the MOV
format itself, are a bit alien to me - all AVIsynth and VirtualDUB
here. MATLAB if I want to play, but not often with video.)
Anyway, thank you for this - though as you say, the action of the
deinterlacer might be tricky to see in this case. ARC, or plain
576i>576p (or anything-i > anything-p) would be most revealing.
Cheers,
David.
Richard Tobin
be sampled simultaneously, or successively over the course of the 1/50
second (for PAL) that the field represents? The latter would make
sense for CRT devices (and cameras), but presumably modern displays
and cameras are closer to the former.
-- Richard
Richard Russell
wrote:
Yes, BBC BASIC (of course!). The program totals about 1660 lines, of
which roughly two-thirds are BASIC and one-third are embedded assembler
code.
Richard.
http://www.rtrussell.co.uk/
davidr...@postmaster.co.uk
I don't know about "supposed", but as you say tube based cameras and
CRTs take most of the 1/50th of a second between first and last line
(ignoring any shutter), while CCDs are simultaneous.
CMOS devices have a rolling shutter, which brings the effect back.
Quite horrible in amateur hands - the world visibly warps as the
camera pans quickly.
Cheers,
David.
Andy Champ
> On Mon, 21 Feb 2011 21:39:02 -0000, Andy Champ <no....@nospam.invalid>
> wrote:
>
>> And I can't see you linking to anything else relevant... though you
>> did mention Martin Weston's Patent
>
> Yes, I linked to it:
>
> http://neuron2.net/misc/USP4789893.pdf
>
I found patent #6,922,214. So I spent all that time...
Andy
Richard Russell
wrote:
> I found patent #6,922,214. So I spent all that time...
Oh dear!
I find this passage from the 'correct' patent particularly interesting:
"This has in the past led to the assumption that some form of adaption, to
distinguish moving areas of the picture from stationary areas, is
essential, so that the most appropriate form of interpolation can be used
in each area. We have now appreciated that it is after all possible to
devise a combined spatio-temporal interpolator which gives improved
vertical resolution, without any subjectively-serious movement blur".
I like the "in the past" bit, because 24 years after that was written I
suspect the majority of people *still* believe it is necessary to use some
form of content/motion adaption to achieve good results from a
deinterlacer.
Richard.
http://www.rtrussell.co.uk/
Richard Russell
> Anyway, thank you for this - though as you say, the action of the
> deinterlacer might be tricky to see in this case. ARC, or plain
> 576i>576p (or anything-i > anything-p) would be most revealing.
Here is the SD ARC program (another BBC BASIC production):
http://www.rtr.myzen.co.uk/arcqtm.zip
As with the downconverter, use entirely at your own risk!
You can directly judge the performance of the deinterlacer by feeding it
with an input file with a lot of inter-field motion. If you select the
'Film (25 Hz)' motion option - in which the ARC filmises the material
(yuk!) - a deinterlaced frame is displayed. In fact the filmising mode
always uses the 2-field temporal aperture (even if '3 fields' is selected
in the Options) so it's not quite as good as when ARCing.
Richard.
http://www.rtrussell.co.uk/
Eric Putt
Roderick Stewart <rj...@escapetime.removethisbit.myzen.co.uk> 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
Albert Ross
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
davidr...@postmaster.co.uk
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.
Richard Russell
<spam@dev_null.com.invalid> 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/
Richard Russell
> 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/
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/
j r powell
>
> 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).
Richard Russell
> 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/
Albert Ross
"davidr...@postmaster.co.uk" <davidr...@postmaster.co.uk>
wrote:
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.
j r powell
>
> On Thu, 24 Feb 2011 21:04:21 -0000, j r powell <no...@invalid.com> 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.
Richard Russell
> 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
Er, no. Why would it need to do that? A frame consists of two fields (!)
so a 2-field-aperture deinterlacer never needs to result in any leakage
across cuts (assuming the cuts are frame-synchronous, of course, which
they always should be). It's only when the aperture exceeds the duration
of a frame that leakage is inevitable.
> Anyway, the same unwanted leakage is of course an issue where any
> movement exists between fields (in either mode).
Every deinterlacer has to find a compromise between inter-field crosstalk
and vertical frequency response. Since the high vertical frequencies
needed to construct the deinterlaced frame are only present in the
adjacent fields, you can't have one without the other. You may happen to
prefer a soft picture to crosstalk, but the Weston deinterlacer provides a
compromise which suits many applications.
> It seems to me (and please correct me if I'm wrong) that in situations
> like this ... the only useful information available to create the new
> line is coming from a single field
You said that the picture was scrolling *horizontally*. In that case
there typically will be "useful information" from the adjacent fields
(much earlier on in the thread I gave the example of a horizontally-moving
rectangle, where the adjacent fields contribute to the sharpness of the
top and bottom edges). It's when the picture is scrolling *vertically*
that the adjacent fields don't contribute anything useful, unless the
filter is 'steered', but as I mentioned previously a vertically-scrolling
picture can look terrible through interlace anyway.
> 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
Surely that's back to front? Deinterlacing artefacts can be easy to spot
when viewing single frames, but may be almost invisible at normal play
speed. I assume you were viewing on a CRT, but on a flat-screen display
motion blur is likely to be dominated by the poor response time of an LCD
or the temporal sub-field processing of a plasma.
I would refer you again to the patent: "The method illustrated gives good
vertical resolution on stationary areas, and moving areas are not blurred,
although they do suffer a slight loss of vertical resolution".
Richard.
http://www.rtrussell.co.uk/
j r powell
> On Fri, 25 Feb 2011 20:55:06 -0000, j r powell <no...@invalid.com> wrote:
>
> > 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
>
> Er, no. Why would it need to do that?
If it doesn't do that, then it must only use the fields from a single source
frame to create every two new progressive frames, which means alternating
between combinations of 'current & next' and 'previous & current' source
fields as the new frames are created. Further playing reveals that your
program does just that, but of course the downside to this method is the
effect it has on the 'leakage'. Staying with the horizontally-scrolling
object example, the related leakage (aka crosstalk) from the adjacent source
field now jumps ahead of, and then behind said object in alternating output
fields, causing a very noticible 25Hz flicker effect during playback.
> > It seems to me (and please correct me if I'm wrong) that in situations
> > like this ... the only useful information available to create the new
> > line is coming from a single field
>
> You said that the picture was scrolling *horizontally*. In that case
> there typically will be "useful information" from the adjacent fields
> (much earlier on in the thread I gave the example of a horizontally-moving
> rectangle, where the adjacent fields contribute to the sharpness of the
> top and bottom edges).
But when the object has moved (in *any* direction) between fields, the
required information from the adjacent field(s) needed to render high
frequency content of said object will be spatially displaced from the
current position, and the "weston" deinterlacer has no means of detecting
and correcting this displacement in order to make use of said information,
right??
(I realise that if an object has moved vertically some of this information
may have already been lost to the interlacing process.)
If I am correct here, a contribution from adjacent fields would only work on
the horizontal edges of a horizontally-scrolling rectangle because the edges
have a horizontal frequency of zero and no spatial displacement in the
vertical direction between fields.
There would be loss of vertical resolution along the horizontal edge in
places where there was no overlap of the rectangle between more than one
source field (ie. the current source field was the only one to contain
useable information, at only half the vertical resolution and sub-nyquist
sampled).
> I would refer you again to the patent: "The method illustrated gives good
> vertical resolution on stationary areas, and moving areas are not blurred,
> although they do suffer a slight loss of vertical resolution".
But the patent concedes that moving areas suffer a loss of vertical
resolution - it doesn't explicitly confine this to vertically-moving areas.
Richard Russell
> If it doesn't do that, then it must only use the fields from a single
> source frame to create every two new progressive frames, which means
> alternating between combinations of 'current & next' and 'previous &
> current' source fields as the new frames are created.
Indeed.
> causing a very noticible 25Hz flicker effect during playback.
It's not "very noticeable", but it is one reason why the 3-field aperture
is preferable to the 2-field aperture. In a software implementation there
would be no reason ever to use the 2-field aperture if you always used the
'previous' or 'next' field, because then you'd need a cut detector to
avoid leakage across cuts, in which case you might as well use the 3-field
aperture anyway!
Interestingly, the BBC (when running my software) always use the 2-field
aperture, simply because their programme 'delivery standards' say that
there mustn't be any leakage across cuts. Clearly they don't consider any
additional artefacts resulting from the 2-field aperture to be of
significant concern.
> But when the object has moved (in *any* direction) between fields, the
> required information from the adjacent field(s) needed to render high
> frequency content of said object will be spatially displaced from the
> current position, and the "weston" deinterlacer has no means of
> detecting and correcting this displacement in order to make use of said
> information, right??
You're falling into the old trap of thinking in the spatial domain rather
than in the frequency domain. For any given pan rate, one can calculate a
horizontal frequency above which the contribution from the adjacent fields
is uncorrelated, and therefore not useful. Horizontal frequencies below
this cut-off contribute usefully to the reconstruction of the deinterlaced
frame.
Take a practical example. Suppose the camera is panning at a rate of 7
seconds per picture width, that is approximately two horizontal pixels per
field (assuming Rec. 601 sampling). You can calculate that the 'cut off'
frequency is about 3.4 MHz; horizontal frequencies greater than this are
uncorrelated between consecutive fields, but lower frequencies contribute
usefully to the deinterlacing process (of course there's a transition
band, but that can be ignored for the purposes of the argument).
If you look at the horizontal spectrum of a typical TV picture you will
find that low frequencies dominate, so at all sensible panning rates the
Weston deinterlacer is still doing a useful job by incorporating high
vertical frequency components from adjacent fields.
Another thing to note is that the 'useless' uncorrelated inter-field
crosstalk has both a high vertical frequency (because that's what the
deinterlacer gets from adjacent fields) and a high horizontal frequency
(higher than the pan-speed-dependent cutoff). Therefore it tends not to
be objectionable (at normal play speed). This contributes to the
'graceful failure' property of the deinterlacer which makes it so
attractive.
> But the patent concedes that moving areas suffer a loss of vertical
> resolution - it doesn't explicitly confine this to vertically-moving
> areas.
As explained above, it depends on the speed of movement and the horizontal
spectrum. High horizontal frequencies can suffer a loss of vertical
resolution as a result of horizontal motion, but low horizontal
frequencies don't. With typical material it's not a big effect.
Richard.
http://www.rtrussell.co.uk/
j r powell
>
> You're falling into the old trap of thinking in the spatial domain rather
> than in the frequency domain. For any given pan rate, one can calculate a
> horizontal frequency above which the contribution from the adjacent fields
> is uncorrelated, and therefore not useful. Horizontal frequencies below
> this cut-off contribute usefully to the reconstruction of the deinterlaced
> frame.
Okay, I followed your practical example through logically. I can sort of see
where you're coming from, but this is something I'll have to take a break
from, and then return to in the future with a clean perspective (no such
option when it comes to coursework, unfortunately), as it's still not
totally 'clicking' for me.
Thanks for the interesting discussion by the way - rare on usenet nowadays.
Richard Russell
> Thanks for the interesting discussion by the way - rare on usenet
> nowadays.
You're welcome. It forced me to think about things more deeply than I've
had to do since I retired five years ago!
Richard.
http://www.rtrussell.co.uk/
John Legon
>On Feb 21, 6:48 pm, "Richard Russell" <n...@rtrussell.co.uk> wrote:
>>
>> Here's the HD to SD downconverter:
>>
>> http://www.rtr.myzen.co.uk/HDtoSD.zip
>a decade), and now need to find a free AVI to MOV converter -
>preferably that doesn't transcode.
FWIW I've found that the wonderful ffmpeg.exe will convert from AVI to
MOV without transcoding, by using the option "-vcodec copy". Usually the
vcodec option forces the use of a specified codec, but here it just
copies the stream. Might not work with your AVI files though.
Ffmpeg also converts my 1280 x 720 HD recordings from TS to AVI in the
same way, but it wouldn't work with a sample of Astra HD at 1920 x 1080.
For that I have to use transcoding, but the bitrate needs to be something
like 14 Mb/s to preserve the detail...
--
John L
j r powell
>
> davidr...@postmaster.co.uk <davidr...@postmaster.co.uk> wrote:
> >
> >I've bitten the bullet and installed QuickTime (I haven't used it for
> >a decade), and now need to find a free AVI to MOV converter -
> >preferably that doesn't transcode.
>
> FWIW I've found that the wonderful ffmpeg.exe will convert from AVI to
> MOV without transcoding, by using the option "-vcodec copy". Usually the
> vcodec option forces the use of a specified codec, but here it just
> copies the stream. Might not work with your AVI files though.
I typically work with uncompressed AVI files (recorded from analogue sources
via DScaler). I was able to transcode them to uncompressed MOV using
'TMPGEnc 4.0 Xpress', in order to use Richard's software.
davidr...@postmaster.co.uk
> On Tue, 22 Feb 2011 23:43:16 -0000, Richard Russell <n...@rtrussell.co.uk>
> 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
Thank you Richard. That SD ARC is really impressive.
I was going to write "...given it's simplicity" - but that's not
really fair. While I can do better, for that specific application I
can only do ~40% better, and that involves throwing about 10,000 times
more processor cycles at the job!
So what you've shown is impressive because it's rather good, _and_
amazingly simple.
I've tried to do the Weston deinterlacer in AVIsynth, but I'm not sure
I've got it right. I've used the 2D convolution function and overlays,
which is a really clunky way of doing it. (It would be far better and
faster to hand code a plug-in). My script doesn't quite match the
results from your ARC, though that might be because I'm using
spline36resize rather than (what I assume is your) frequency domain
optimised upscaling filter. Or it might be because I'm abusing 2d
convolution and overlay!
Using just the deinterlacer, the results are like a special sharp-ish
version of dumb bob - which is what I'd expect - but your ARC seems
slightly sharper vertically (and that's before I've pushed the
"enhancement" sliders any amount to the right. Are you using any other
tricks, or shall I check my code?
I'll check my code anyway, but if you're using a single set of
coefficients to do the deinterlacing and resizing in one go, I doubt
I'll get close without hand coding to match.
Cheers,
David.
davidr...@postmaster.co.uk
Thanks John.
FWIW I was starting with raw 4:2:0/YV12 AVI (no compression - just for
this test), and tried "copy" in ffmpeg and "direct stream copy" in
Oxelon. Both gave the same strange result: 3 small monochrome images
across the top, with the half sized colour different signals across
the middle, and black at the bottom. I think I get why and how, but
that's hardly a direct stream copy! Transcoding to MJPEG was fine, so
I used that (in Oxelon - nicer GUI!). I used the same to get back to
AVI.
It worked, but I'm not sure it handled the 4:2:0 interlaced chroma
properly. I might have to re-try with a 4:2:2/YUV source to see if
it's any better.
Cheers,
David.
John Legon
>On Feb 27, 7:59 am, John Legon <j...@nospam.demon.co.uk> wrote:
>>
>> FWIW I've found that the wonderful ffmpeg.exe will convert from AVI to
>> MOV without transcoding, by using the option "-vcodec copy". Usually the
>> vcodec option forces the use of a specified codec, but here it just
>> copies the stream. Might not work with your AVI files though.
>>
>> Ffmpeg also converts my 1280 x 720 HD recordings from TS to AVI in the
>> same way, but it wouldn't work with a sample of Astra HD at 1920 x 1080.
>> For that I have to use transcoding, but the bitrate needs to be something
>> like 14 Mb/s to preserve the detail...
>
>Thanks John.
>
>FWIW I was starting with raw 4:2:0/YV12 AVI (no compression - just for
>this test), and tried "copy" in ffmpeg and "direct stream copy" in
>Oxelon. Both gave the same strange result: 3 small monochrome images
>across the top, with the half sized colour different signals across
>the middle, and black at the bottom.
Not surprised that Oxelon gave the same result since it's just a GUI
shell for ffmpeg, making file selection and so on a bit easier but
lacking many of the options. The current Oxelon version of ffmpeg is
also a couple of years out of date.
>I think I get why and how, but
>that's hardly a direct stream copy! Transcoding to MJPEG was fine, so
>I used that (in Oxelon - nicer GUI!). I used the same to get back to
>AVI.
I'm happy with the command line for the raw ffmpeg.exe, and use it in
batch files so I don't have to keep typing everything in...
--
John L
Richard Russell
> I'll check my code anyway, but if you're using a single set of
> coefficients to do the deinterlacing and resizing in one go, I doubt
> I'll get close without hand coding to match.
Yes, I am using a single set of coefficients to do both deinterlacing and
resizing. They were calculated using a filter synthesis tool to which I
had access at BBC R&D, but sadly I don't any longer (having retired five
years ago). So I couldn't re-synthesise those filters now if I wanted
to. :-(
If I had to do it now I would convolve a straight resizing filter with a
Weston-style vertical-temporal deinterlacing filter, but the consequence
would be an overall aperture greater than it theoretically needs to be.
That's what I did for the HD to SD downconverter.
Another possible reason for your results not being quite as good as mine
are that the deinterlacing filter I routinely use isn't one listed in
Martin Weston's patent, but a more recently designed one with a better
vertical frequency response.
Richard.
http://www.rtrussell.co.uk/
davidr...@postmaster.co.uk
> On Mon, 28 Feb 2011 18:44:56 -0000, davidrobin...@postmaster.co.uk
>
> <davidrobin...@postmaster.co.uk> wrote:
> > I'll check my code anyway, but if you're using a single set of
> > coefficients to do the deinterlacing and resizing in one go, I doubt
> > I'll get close without hand coding to match.
>
> Yes, I am using a single set of coefficients to do both deinterlacing and
> resizing. They were calculated using a filter synthesis tool to which I
> had access at BBC R&D, but sadly I don't any longer (having retired five
> years ago). So I couldn't re-synthesise those filters now if I wanted
> to. :-(
Was this an internal BBC R&D program, or something available
commercially?
> If I had to do it now I would convolve a straight resizing filter with a
> Weston-style vertical-temporal deinterlacing filter, but the consequence
> would be an overall aperture greater than it theoretically needs to be.
> That's what I did for the HD to SD downconverter.
>
> Another possible reason for your results not being quite as good as mine
> are that the deinterlacing filter I routinely use isn't one listed in
> Martin Weston's patent, but a more recently designed one with a better
> vertical frequency response.
I remembered you saying you didn't use those exact coefficients. I
guess I'm going to have to go and really understand that patent.
Thanks for sharing these programs Richard. Much appreciated. Hope
you're enjoying retirement! Maybe you left BBC R&D at just the right
time? Though I assume/hope the people there will find a way to work on
interesting projects and contribute to broadcasting, despite the
attitudes of upper management.
Cheers,
David.
Richard Russell
> Was this an internal BBC R&D program, or something available
> commercially?
Internal, written by Jim Easterbrook I think.
> I remembered you saying you didn't use those exact coefficients. I
> guess I'm going to have to go and really understand that patent.
There's an infinite number of possible sets of coefficients that meet the
criteria in the patent. At the time of Martin's original work I don't
think there was any way of synthesising a suitable vertical-temporal
filter other than 'intelligent guesswork'. Since then mathematical
techniques have been developed to allow the synthesis of an 'optimum' V-T
filter against a set of parameters.
> Maybe you left BBC R&D at just the right time?
> Though I assume/hope the people there will find a way to work on
> interesting projects and contribute to broadcasting, despite the
> attitudes of upper management.
Kingswood Warren has been sold (and the building in which I worked
bulldozed) so now R&D are located in West London. It's an entirely
different environment which some would argue isn't so conducive to
innovation.
Richard.
http://www.rtrussell.co.uk/