LCD screen going nuts with hi-freq vertical image data

[Chris Millar]

Hello,

 

I noticed my new cheapo LED/LCD screen glitches when I feed it high frequency vertical image data...

 

I first noticed it on a line drawing black and white picture on the net but made a proper image in photoshop to test that it was comprised of alternating black and white stripes one pixel in dimension.

 

If the stripes were horizontal, no issue, but rotating them to be vertical I get a sort of 'humming' effect in the area of the image especially when viewed 1:1 (one image pixel = one screen pixel). Flat areas are not affected at all.

 

What is going on ?

 

I'm feeding it via a VGA cable from a macbook pro

 

Should I be taking it back to the shop ?

 

cheers,

Chris

[Phil Rhodes]

I would suspect one of two things. Either:

 

http://www.lagom.nl/lcd-test/clock_phase.php

 

Or, more likely, since it's doing it on only horizontal stripes,

 

http://www.lagom.nl/lcd-test/inversion.php

 

P

[Chris Millar]

Thanks for that page - (I found it hard to search for the problem in google)

 

Interestingly enough a checker pattern just like they have there is the first test image I made - then went vertical/horizontal to see if that changed things (as it did)...

 

I have a chance today to try my mac on another monitor of the same type which I was going to use as an A/B to rule mine out, may still do it out of interest. But going with the theory that OS X is feeding it the wrong clock or phase how to go about fixing it ?

[Chris Millar]

OS X says its feeding it 60Hz - Autoconfig on the screen gives me 50Hz which is much better than last night but there is still a slight flicker, manually choosing clock rates in the screen menu go up in 1Hz increments, suspect the rate is just off 50Hz ...

 

:huh:

 

Hope at least one other person is finding this interesting

[Phil Rhodes]

OS X says its feeding it 60Hz - Autoconfig on the screen gives me 50Hz which is much better than last night but there is still a slight flicker, manually choosing clock rates in the screen menu go up in 1Hz increments, suspect the rate is just off 50Hz ...

 

:huh:

 

Hope at least one other person is finding this interesting

 

Slightly odd situation; if the mac is feeding it 60hz, you'd expect the monitor to detect that and sync to it, and for it to report as such. It's very irregular for the computer to say one thing and the monitor another, if you have an image at all.

 

Making a monitor autoconfigure correctly is quite tricky, and I suspect that may be what you're seeing. I could be wrong, but let's continue on that assumption.

 

The issue is that since you're feeding it analog signals, there is no absolute relationship between a pixel on your monitor and a pixel as rendered by your graphics card. Assuming you've set your computer to send graphics at the native resolution of the monitor, the monitor knows how many rows there are because it gets a nice clean unmistakable sync pulse for every line. However, in the horizontal direction it just sees scanlines, so it just samples those scanlines once for every pixel in every row of its disipaly, and puts the resulting values onto the LCD pixels. Contrast this with a DVI or HDMI feed, whereby every pixel is individually addressed as part of a digital bitstream and there is no ambiguity.

 

Consider the case where you have one black pixel next to one white pixel. There's a well-defined edge between them, but if the point at which the TFT panel samples a pixel happens to lie exactly on that edge, small variations in the clock rates of the computer and the TFT will cause the resulting sample to flicker randomly between the black and white state. As a practical matter, the sample points used by the TFT will go in and out of phase with the graphics card's pixels, resulting in flickering or shimmering vertical bands of noise.

 

The auto adjust feature on a TFT attempts to solve this by detecting where sharp edges in the graphics are. In days of yore, text was usually drawn using single columns and rows of pixels, and would provide a reasonable clock and phasing reference. However, this is more difficult on modern operating systems like Windows XP, 7 or Vista, and OSX, where all the text and is drawn with nice soft edges and antialiasing which are easy on the eye, but provide a very poor clock and phase reference with few single-pixel black to white transitions - and the monitor needs a good few scattered around the screen to get a really solid lock on the signal.

 

The standard solution is to draw a test pattern which gives the monitor a best-case reference. People draw black and white vertical stripes of single pixels, but that fails to provide a good reference as to the exact location of the beginning and end of the scan, since all screenmodes are an even number of pixels wide and the pattern must therefore either start or end on black, which cannot be reliably distinguished from the end-of-line blanking period. A one pixel error like this is exactly what'll cause these sorts of problems.

 

The best approach is to draw stripes in two primary colors (I usually use red and blue). This gives the monitor an absolutely unmistakable clean square wave on the red and green components, at least one of which will be in a "high" state at both the beginning and end of the scanline. This should, with any luck and competent software in the monitor, produce a situation which is hard to screw up. I wrote a program to do this, but it's windows-only, so it won't help you, but it's easy enough to knock something up in Photoshop. Make sure it fills the entire screen at its native resolution, that the primary stripes are exactly one pixel wide and that they're not antialiased.

 

By this technique it is possible to get analog monitors looking pretty much as good as digital ones; unfortunately, it's a bit fiddly to do. There's at least one projection facility to which I provided some display equipment that currently goes through this procedure every night because they were too cheap to buy the DVI input card for their big ticket projector.

 

And if that doesn't solve it, well, we made the wrong assumption.

 

P

[Chris Millar]

Made it - auto-configured - no more buzz ...

 

Thank you Phil ^_^

[Chris Millar]

oh for f's sake...

 

NEW problem noticed

 

Ok, so If I have black on white text and I scroll it up and down or left or right on screen it leaves behind a very short white ghost - whiter than the 'white' that is already there which now appears colder in tone (yes, I've calibrated the screen).

 

I only see it with moving text

 

Wow, the cinematography forums have a light blue BG - I can read the text in white below the proper black if I move fast enough to ghost it so far that it is separated from the black (and read fast enough)