BBC HD vs ITV1 HD

It's just not worth arguing with someone who can't or won't even
believe the evidence of his own eyes!

PLONK!

On Fri, 1 May 2009 00:49:15 +0100, "jamie powell"
wrote:

"Java Jive" wrote in message

Of course, if someone were actually to come up with evidence to the
contrary, I'd have to, and would have no problem with, changing my
opinion (and my webpage), but it hasn't happened yet. All that ever
seems to happen is that people just repeat the same old myths without
thinking about them analytically.

Sorry but the photo on your webpage isn't conclusive "evidence" of anything,

======================================

Please always reply to news group as the email address in
this post's header does not exist. Alternatively, use the
contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html

First, a clarification, that particular picture was taken during the
ancillary artifacts experiment, and so shows the larger 22" LCD, and
you've made me realise that I haven't noted that on the page. Next
time I republish I'll correct that.

However, the basis of your argument is still valid. I've just used a
hand lens to count the picture elements on the 22", and, perhaps
rather surprisingly, its vertical resolution is somewhere around that
of the 15".

But while the point you raise is interesting in its own right, you
still have to find an alternative explanation of the picture which
appears to show the lines from two fields side by side. What is your
explanation for this?

On Fri, 01 May 2009 01:22:09 +0100, Andy Furniss
wrote:

Java Jive wrote:
Hard information is hard to come by, but it's debatable whether LCDs
*need* to deinterlace at all, really they only *need* to buffer, and
therefore that's much more likely what the majority do:
http://tinyurl.com/daw2gz
... standing in for ...
http://www.macfh.co.uk/JavaJive/Audi....html#CriticTV

You say in that article that the LCD TV has a vertical resolution the
source so I wouldn't expect you to be able to see interlacing artifacts.

======================================

Please always reply to news group as the email address in
this post's header does not exist. Alternatively, use the
contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html

Tut, field ..

On Fri, 01 May 2009 10:32:07 +0100, Java Jive wrote:

The previous frame

======================================

Please always reply to news group as the email address in
this post's header does not exist. Alternatively, use the
contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html

In article ,
Java Jive wrote:

Choose the correct one from:
1) Nothing, it continues to display what was previously there,
just as a CRT does.

To do what a CRT does, it would have to continuously fade the lines
after it displayed them (even, to a small extent, mixing them into the
new lines for that field). That is hardly "just buffering". In fact,
it's a deinterlacing technique.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

No, it's just buffering. It doesn't convert 50 fields ps into 25
frames ps, which is the fundamental characteristic of deinterlacing.

On 1 May 2009 12:42:17 GMT, (Richard Tobin)
wrote:

To do what a CRT does, it would have to continuously fade the lines
after it displayed them (even, to a small extent, mixing them into the
new lines for that field). That is hardly "just buffering". In fact,
it's a deinterlacing technique.

======================================

Please always reply to news group as the email address in
this post's header does not exist. Alternatively, use the
contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html

In article ,
Java Jive wrote:

To do what a CRT does, it would have to continuously fade the lines
after it displayed them (even, to a small extent, mixing them into the
new lines for that field). That is hardly "just buffering". In fact,
it's a deinterlacing technique.

No, it's just buffering. It doesn't convert 50 fields ps into 25
frames ps, which is the fundamental characteristic of deinterlacing.

Well you can choose your own definition of deinterlacing, though why
you should require it to produce 25 frames a second I can't imagine.
Since the fading would not, in fact, be continuous you would in effect
be creating a much larger number of frames per second.

But it's completely absurd to suggest that an algorithm that includes
fading lines is "just buffering".

-- Richard
--
Please remember to mention me / in tapes you leave behind.

I think we're talking at cross purposes here. Rereading your post, I
see an alternative meaning than the one I originally read, but this
alternative makes your post seem rather pointless. I am only claiming
that my LCDs are buffering, without fading anything. Your
hypothetically trying to get LCDs to be exactly like CRTs by fading
lines is a pointless distraction which doesn't illuminate anything.

On 1 May 2009 15:29:20 GMT, (Richard Tobin)
wrote:

In article ,
Java Jive wrote:

To do what a CRT does, it would have to continuously fade the lines
after it displayed them (even, to a small extent, mixing them into the
new lines for that field). That is hardly "just buffering". In fact,
it's a deinterlacing technique.

No, it's just buffering. It doesn't convert 50 fields ps into 25
frames ps, which is the fundamental characteristic of deinterlacing.

Well you can choose your own definition of deinterlacing, though why
you should require it to produce 25 frames a second I can't imagine.
Since the fading would not, in fact, be continuous you would in effect
be creating a much larger number of frames per second.

But it's completely absurd to suggest that an algorithm that includes
fading lines is "just buffering".

-- Richard

======================================

Please always reply to news group as the email address in
this post's header does not exist. Alternatively, use the
contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html

"Java Jive" wrote in message
...
It's just not worth arguing with someone who can't or won't even
believe the evidence of his own eyes!

Are you thick or something?

"Java Jive" wrote in message
...

A conventional CRT *doesn't* continue to display what was previously
there -
there is some minimal residual phosphor lag, but field A has all for all
intents and purposes disappeared from a given area of the screen before
field B reaches the area.

No it hasn't.

Yes it has.

The term persistence when applied to phosphors has a specific,
mathematical meaning: it's the time taken for the luminescence to
decay to 10% of its starting value. It is NOT the time taken to fade
away to nothing (that would be infinite) NOR even the time taken for
luminescence to become invisible to the eye or any other detector. I
get the impression that many, perhaps including yourself, do not
understand this fundamental point.

Oh my - methinks you've been Googling this, having previously not even known
about its existence until I told you, and are now pasting what you've read
in an effort to maintain some credibility!
For the record, I said it became invisible *for all intents and purposes*.


Each phosphor dot as it is refreshed momentarily reaches a brightness
many orders of magnitude greater than its brightness during the
greater part of its exponential decay. This extreme brightness if
maintained would probably blind you (and may be related to stories of
eyesight deterioration using CRTs, as in my experience, though I am
not aware of independent evidence proving exactly what the mechanism
of deterioration is). Thus, by the time the next field is being
drawn, the previous one can still be picked up by cameras:

http://en.wikipedia.org/wiki/File:Refresh_scan.jpg

The previous field is still visible to this camera at only 1/3000s
f/1.6 exposure. Though darker, it is clearly discernible as two
people facing the camera over the top of a counter or table, the top
of the right hand person's head having just been refreshed.

As the human eye is much more sensitive than most cameras, it beggars
belief that this would not also be visible to the naked eye.

If left alone, it would still be visible to the naked eye, *but* when the
next field gets drawn in the same area of screen at a *much* higher
brightness level than the previous field's residual phosphor lag, it gets
totally blocked out.

Never at any time, on any given part of the CRT screen, is field A being
displayed at anything close to the same brighness level as field B, hence
there's no "mice teeth" effect.
It really is as simple as that.

So much so that I have been giving it further thought. On the face of
it, why would an LCD maker use too small a screen size? I don't think
it's a coincidence that NTSC has 486 visible scan lines ...
http://en.wikipedia.org/wiki/NTSC

486 is very close to my measured value of 492 and comfortably within
the accuracy of my measurements +-35, so it seems likely that, being
early models into this country, they were built primarily for the NTSC
market but adapted for European use as well.

Consequently, their pictures aren't probably as good as a vertical
resolution of 576 would give, but they're still very good, and a lot
better than my CRT.

On Fri, 01 May 2009 11:16:39 +0100, Java Jive wrote:

However, the basis of your argument is still valid. I've just used a
hand lens to count the picture elements on the 22", and, perhaps
rather surprisingly, its vertical resolution is somewhere around that
of the 15".

But while the point you raise is interesting in its own right ...

======================================

Please always reply to news group as the email address in
this post's header does not exist. Alternatively, use the
contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html