• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 47 subscribers
  • Views 522 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TVP5147 grayscale combing

Andrew Leech (medmont)
Prodigy 60 points
Other Parts Discussed in Thread: TVP5147, TVP5147M1

Hello,

I'm replacing a legacy PCI video capture card (Leutron brand) with a custom USB video capture unit using a TVP5147PFP. I realise this part is now NRND but originally thought I had to stick with it for square pixel support. I now see that a patch for TVP5147M enables square pixel support, so will probably migrate to that in future.

My primary query is with respect to the image quality obtained. Visually it looks perfectly good, capturing a grayscale PAL 768x576 image from an analog camera. As part of our validation process however, my colleague put together a program that compares the PCI capture and my USB version side by side with real time histograms, basically showing the number of pixels of each level of grayscale.

While the histograms of the PCI card and my unit look basically the same (once contrast, gain and brightness have been adjusted to give an equivalent picture), we're getting a strange combing effect in the histogram, with regular intervals of individual levels of gray getting spikes up or down from the rest of the curve. It looks like some kind of harmonic effect enhancing or degrading individual levels of gray, although the levels effected change as settings (primarily contrast) are changed. There's not visible noise in the picture, so I'm not sure where they're coming from. The spike positions and levels are also constant up or down, and only change when contrast/brightness/gain are changed.

I've attached a few images of these histograms that should illustrate the issue much better.

Is this a known outcome of the way filtering in the TVP5147 would operate? I'm using it currently in CVBS mode, although I've tried setting it to SVIDEO with my input as the Luma input, and that just makes the combing worse. Tried changing the comb&trap filter settings with no change visible. I'm using the chip set to 20 bit mode and just grabbing the 8 most significant bits from the luma outputs, ignoring the color outputs.

Can you make any suggestions on how to eliminate this?

Thanks,

Andrew

  • 0
    TI__Genius 16810 points

    Hi Andrew,

    Can you porvide a picture of the grayscale test pattern that you are using?

    Does this occur for only certain types of test paterns?

    Are you using an anti-alias filter on the TVP video input?

     

  • 0 in reply to Larry Taylor
    Prodigy 110 points

    Hi Larry, 

    I'm away from work for the weekend already (in Australia), you probably are too by now.

    Either way I don't have a copy of a test pattern, as I was just feeding in the signal from a PAL/CCID B/W camera. Moving the camera around obviously changes the overall shape of the histograms, but the locations of peaks never changed with the picture, as mentioned they only moved when changing video settings. As is visible in the images above also, at some settings the combs are really close, other times they are much further apart. We can occasionally find settings that have no visible spikes (in between them going up and going down) although those settings never happen to give the ideal image on screen.

    I do have an anti-alias filter on the analog front end, it's the same one as used in the  Anti-Aliasing Filters app note (SLEA086), although on my dev board I used jumpers to allow them to be bypassed, and doing so didn't change the spikes at all (although I do get some visible vertical banding noise on the picture without the filter).

    Thanks,

    Andrew

  • 0 in reply to Andrew Leech66752
    Prodigy 60 points

    I got some TVP5147M1's to try, turns out they've got exactly the same combing effect, no visible change.

    On a related note, patch 7.02.00 adds perfectly functional square pixel support, which is completely compatible with me existing code which is great. Do you know why then, that in 7.03.00 it's been disabled again? bit 7 of 0x33 is set back to being 720 pixel mode. If this 720 pixel mode is in fact different to the normal operating mode and is desired, why could they not use a different register to enable it, rather than replacing square pixel mode with it? For now I'll just have to leave 7.02.00 running, but if future patch code comes out that's desired, I wont be happy about not being able to use it due to square pixel mode not being available.

    I'd still like to find the source of the combing too, if you've got any suggestions?

    Andrew