Fix color interpolation visual artifacts

[lkesteloot]

The protocol program draws a single large RGB triangle, and I sometimes see strange visual artifacts, like a dark red line near the red vertex. It's most visible when the line is near-vertical.

[lkesteloot]

This video shows the artifacts: https://www.youtube.com/watch?v=ty_4Y_9PYis

That's a red-black-black triangle rotating. When the red vertex points right, there's a bright vertical line down the middle. When the red vertex points left, there are two bright vertical lines, one 1/4 of the way and one 3/4 of the way. (The one 1/4 of the way is hard to see in the video, but it's the brightest in person.)

The problem does not occur for green and blue. It does not show up when the frame buffer is saved to disk. It must be a scanout problem.

By adjusting the colors of the vertices, I've determined that the line down the middle happens right at the place where the color red is 128, and the lines at 1/4 and 3/4 are when the color is 192 and 64 respectively. So the problem happens when the scanned-out red color goes from 0x7F to 0x80 (dark to light), from 0xC0 to 0xBF (light to dark), and 0x40 to 0x3F (light to dark).

Writing out the bits, those transitions are:

From: 01111111
To:   10000000

and:

From: 11000000
To:   10111111

and:

From: 01000000
To:   00111111

The artifacts are explained by saying that bit 6 of red transitions too slowly from 1 to 0. In the first case that would result in 11000000, in the second 11111111 (very bright), and in the third 01111111 (dimmer). That matches what we see.

It does not have trouble transitioning from 0 to 1 or we'd see more artifacts (in the other direction).

[lkesteloot]

@bradgrantham, I'd be interested in whether you see these artifacts. I've checked in (commit 9cb5eb34) the protocol program that spins the triangle from the video. If you do, then it's some capacitance in the daughter board, I'm guessing. If you don't then it must be some loose cable in my system.

[lkesteloot]

I've pushed on my various cables and didn't see a difference.

[lkesteloot]

Strangely, the final fix to bug #34 made this problem worse. I went from 4 to 5 stages in the reciprocal pipeline and didn't see a difference. I went from 5 to 6 and I don't think I saw a difference (but I don't remember). I then refactored my state machine, and now I see three lines when the red point is at the left. The one in the middle (at 0x80) is now super bright. It flickers a bit, even after killing the protocol program, so the problem is definitely during scanout.

[lkesteloot]

And now in the RGB triangle it appears for blue, but still not for green.

[bradgrantham]

I've seen artifacts like these the whole time scanouts been working, even in the original alice4view images. I hadn't done much with them because they seemed lower priority than just getting things working. I agree it seems like something electrical.

Could this happen if R6 was swapped with R5 or R7? (And ditto for blue?)

Another way this might be explained is that those 3 transitions flip all or all-but-one of the bits in the byte at once. Interpolating over the triangle would only cause 7 or 8 bits to flip at only those 3 values. If the supply is weak, that would cause a brownout or an unexpected overvoltage, which could be caused by insufficient local power caps, I guess. Or changing state could be drawing power (and not just all 0s to 1s or 1s to 0s), but then I would expect dark lines. It doesn't line up quite as well as your explanation; I'd think we'd see other, dimmer, unexpectedly bright lines when R5 transitioned (and all the other bits). We'd also see unexpectedly dark lines. I think one way to test it would be to write a bunch of columns of, say, 0b01010101 and then 0b00101010, and see if there are unexpected bright lines.

For your explanation, what would cause R6 to change too slowly from 1 to 0? If there was unexpected capacitance to 3v3? One place to look is on the ribbon itself, but R6 is nowhere near 3v3. R6 doesn't appear to run very close to anything in particular on the PCB. So I would expect, for example, R5 to behave similarly, or maybe even worse because it travels over the ribbon next to 5V.

Are you saying blue shows bright lines in the same 3 places in the RGB triangle? But not green? That would be a weird coincidence and also failure of coincidence. And points away from the possibility above of transitions of lots of bits.

Why do the bright lines fade toward the bottom of the image? Interestingly that's on scanlines where there's less total brightness (as a sum of values on the scanline). That sounds very electrical.

I suppose it's possible TFT friend has some kind of an issue, but I'd doubt my work first.

I will try this later today. When I tried the current Verilog earlier in the week, I saw very strange blocky artifacts (as if you were still drawing the bounding box) and after just a few frames drawing stopped. I will try again. What state should my switches be in? All 4 are, uh, towards the SoC.

I can probably simulate these possibilities with a simple C program that loads an image and pretends to do scanout with a delay on R6 or a capacitor on R6.

What would the fix be if there's unexpected capacitance?

I hate capacitance.

-Brad

-- Brad Grantham, http://plunk.org/~grantham/

On Fri, May 12, 2017 at 10:57 PM, Lawrence Kesteloot < notifications@github.com> wrote:

And now in the RGB triangle it appears for blue, but still not for green.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/lkesteloot/alice/issues/35#issuecomment-301227765, or mute the thread https://github.com/notifications/unsubscribe-auth/AEyFWfTymWv_IqMd1_muRX4af22Z0J4Vks5r5UZfgaJpZM4NSTDb .

[lkesteloot]

I wrote a C program to simulate the 6th red bit being slow to move high-to-low, and got this:

That's what I was getting originally. When the going dark-to-bright there's a single line down the middle. When going bright-to-dark there are two lines at 1/4 and 3/4. I've checked the program in with a8fa5cb. Feel free to modify to test other ideas. (I haven't modified it to look like the latest artifact.)

[bradgrantham]

It's remarkable how well that reflects what's going on! I also feel like it's somehow related to the rest of the line as the bright lines dither out near the bottom left edge as indicated in your GitHub issue shot.

On May 13, 2017 13:31, "Lawrence Kesteloot" notifications@github.com wrote:

I wrote a C program to simulate the 6th red bit being slow to move high-to-low, and got this:

[image: out] https://cloud.githubusercontent.com/assets/419771/26029013/064f4190-37e0-11e7-886c-13506ff2a07a.png

That's what I was getting originally. When the going dark-to-bright there's a single line down the middle. When going bright-to-dark there are two lines at 1/4 and 3/4. I've checked the program in with a8fa5cb https://github.com/lkesteloot/alice/commit/a8fa5cb0999fd1c535b0ba9d566960fade9037fd. Feel free to modify to test other ideas. (I haven't modified it to look like the latest artifact.)

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/lkesteloot/alice/issues/35#issuecomment-301272985, or mute the thread https://github.com/notifications/unsubscribe-auth/AEyFWR02WuwHHZfO_kKJy4xbYX3Votdzks5r5hMrgaJpZM4NSTDb .

[lkesteloot]

What state should my switches be in? All 4 are, uh, towards the SoC.

Mine are 0110, where 0 is away from the SoC. I don't think the two middle ones matter. The right-most one (toward the Ethernet port) is what's causing your blockiness.

[bradgrantham]

That solved the blockiness. I don't know what the hangs were about; I'm not getting them now.

I installed Linux Mint and Quartus 16.1 on my 8-year-old quad-core 16GB HP laptop. My Verilog compile time was 20 minutes on my Mac. It's 7 minutes, 30 seconds on my HP.

What I'm seeing is almost as if each bit that is more significant than the last lags the less significant bit. I see subdivisions corresponding to R7-R4 bits. It may even go to R3 but it's hard to tell.

I guess I could kill the program when a really bad pattern is on-screen and then put the scope on it. I'm not sure my scope will go to 25MHz..

-Brad

-- Brad Grantham, http://plunk.org/~grantham/

On Sun, May 14, 2017 at 11:25 AM, Lawrence Kesteloot < notifications@github.com> wrote:

What state should my switches be in? All 4 are, uh, towards the SoC.

Mine are 0110, where 0 is away from the SoC. I don't think the two middle ones matter. The right-most one (toward the Ethernet port) is what's causing your blockiness.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/lkesteloot/alice/issues/35#issuecomment-301330496, or mute the thread https://github.com/notifications/unsubscribe-auth/AEyFWQ5pXuKdUjtke7DAiCyb3371l4mxks5r50cNgaJpZM4NSTDb .