I am interfacing a DaVinci SoC DM6446 to a THS8200 and it seems to work, but the colors seem to be off and I'm having trouble determining whether the problem is in the DaVinci or in the THS8200 (or in the interface between the two chips). I am using the 20-bit YCbCr interface for the THS8200 connected to the DM6446. I am just copying an RGB565 image to the OSD0 frame buffer and setting the ATTR buffer to 0xF (4-bits). I have both video buffers set to "off" at the moment since I am not using them. However, if I leave vid0="on" I get a different result. I'm not entirely sure why. I guess because there is data in the memory used for vid0? I would think it would be zeros. Any suggestions would be appreciated.
try swaping Cb and Cr components on bus; you can do this by programming a DM6446 register (see VPBE UG and let me know if you cannot find it); this should take care of the color issue.
Also, what exactly do you see when you use vid0? It is entirely possible that there is data placed there during driver initialization.
Swapping the Cb and Cr components seemed to fix the problem when the vid0 buffer is turned off, but the color still seems to be off when the vid0 buffer is on for some reason. Not sure why. It seems to be something with the shading (the attribute plane). Instead of shades of grey, I'm getting white to black and shades of pink.
well, if you have both vid0 and vid1 enabled (vid1 should be < or equal in size according to specs), vid0 should be in the back, partly or completely covered by vid1 and any OSD data will be placed on top of these to video windos blended per attribute window. That said, if you writte all zeros to attribute window (e.g. > cat /dev/zero > /dev/fb/2 ), you will essentially make any OSD data invisible and only see what is truly there in vid0 and vid1. Can you try this exercise to see what portions of what you are seeing is contributed by video window(s) and by OSD window? Also, a screen-shot of what you are seeing may help...
Does the RGB conversion matrix do anything by default when using the DaVinci digital output? What does it default to?
if your specified output pixel format is YCbCr, as it appears to be in your case (since we just discussed Cb and Cr swapping prior to THS), then the RGB conversion matrix in the VENC does not come into play. The data provided from the OSD to the VENC is already in YCbCr pixel format, so no need to do any conversion. If however, the hardware was configured to output RGB pixel format, the the RGB conversion matrix would be used to achieve the conversion and RGB data will be output from digital video output interface pins.
I think my conversion matrix is incorrect in the THS8200 for the colors. Do you know what the conversion matrix in the THS8200 when using the DaVinci DM6446 as input?
ahhh, so it appears you are taking YCbCr input into the THS8200 and converting to RGB ih the THS8200; is this correct?
To be honest, I am not too familiar with THS parts; a better place on the forums to get support for this family of parts is http://e2e.ti.com/forums/186.aspx
I am curious though, what are you interfacing to; since you are using the THS part, I assume it is an analog display.. are you using high resolution (more than what DM6446 can handle with its internal analog DACS) RGB analog displays?
BMillikan:Do you know what the conversion matrix in the THS8200 when using the DaVinci DM6446 as input?
The color space conversion functionality for the THS8200 is described in section 4.4 of the THS8200 datasheet. The example settings provided for HDTV YCbCr to HDTV RGB conversion worked for a customer who asked about this functionality in the past where they wanted to output a 720p signal on a VGA cable in analog RGB, this was from a DM355 however it will apply the same to the DM6446 as they share a similar VPBE and use the same color format output. I have a set of example settings for a 16 bit YCbCr 4:2:2 720p digital input with external syncs converting to RGB output for display over a VGA cable to a PC monitor that accepts HDTV 720p timings over VGA if you want it, though it uses the same color space conversion coefficients as outlined in the datasheet.
BMillikan:but the color still seems to be off when the vid0 buffer is on for some reason.
Thinking about this statement, it would seem to me that this would indicate that the problem could not be in the THS8200 conversion settings, since that is well beyond the mixing aspect of the OSD in the VPBE, if the problem was in the THS8200 conversion than that would mean that the image should be bad all the time, not just when the vid0 window is enabled.
This makes me wonder if your attribute window is really set to have the OSD only showing, and if your attribute window is really covering the whole screen, if you change the values in the attribute register can you see an impact on the output? Note that if the video window is not being filled with valid data that you are probably seeing random data in DDR, which usually ends up looking like a pink and green mess.
If this is really messed up all the time and you cannot impact it with the OSD window you may want to check your window sizes and make sure they are within spec, primarily the constraints listed in section 4.3.1 of SPRUE37c, and that they logically make sense.
We have tried using the default conversion tables as given in the THS8200 specification, but we get a blueish or redish tinted effect around areas where we are using the attribute plane to adjust the color. Perhaps our application is more sensitive to color that any other. We are painting something on a black background, so colors show up really well (if they are right or wrong). I am also discussing this issue with a representative of TI that is familiar with the THS8200, but it would not hurt to make sure my DaVinci interface is correct as well. I think it is ok, but I can't rule anything out at this point. I see the image, but the color is off. Unfortunately, I don't have a way to take a screen shot.
One thing to note that might be an issue is that the default color conversion tables for the OSD are 8-bit and the conversion tables for the THS8200 from Y/C to RGB are 10-bit. Perhaps this is an issue? Is there a way to change there default tables for a specific mode of operation?
BMillikan:We have tried using the default conversion tables as given in the THS8200 specification, but we get a blueish or redish tinted effect around areas where we are using the attribute plane to adjust the color.
This would still imply that the issue is more related to the attribute plane than the color conversion later on down the line, I am assuming that you have areas of color that are correct that are not involved with the attribute plane, and if so than they should be off as well. It is strange that you describe using the attribute window to adjust the color, do you have the background window set to some constant value and you are just using the attribute window to brighten or darken or tint the front image? The attribute window is not really designed for use as a color correction device, it is really just a simple pixel by pixel weighted averaging engine, though that should do what you describe as well you may be hitting some edge condition. I would probably start by taking the attribute window out of the system to validate that you can pipe test data through the system (like color bars) to validate everything else, and than go back to looking more closely at the attribute window.
I think I may be missing the end goal here and that may be throwing me off since your description is strange of painting on a black background and using the attribute window for color adjustments, if you feel this is the case we may have to take the issue offline.
BMillikan:One thing to note that might be an issue is that the default color conversion tables for the OSD are 8-bit and the conversion tables for the THS8200 from Y/C to RGB are 10-bit. Perhaps this is an issue? Is there a way to change there default tables for a specific mode of operation?
I don't believe this would be an issue at least it should not be as long as you are ok with an 8 bit color depth conversion, as long as the forumlas are all still correct this should only impact a slight loss of color depth coming out of the OSD. You may want to ask your THS8200 contact about adjusting the THS8200 side tables further, though as suggested here, I am not sure that would impact things.
What range does the DM6446 output the YCbCr data by default (if I don't change the conversion tables)?
There are a few places to control this in the VPBE, however by default (as in default register values) the range will be 0-255 for each YCbCr component. At the OSD level the stream can be attenuated to the REC601 levels of 16-235 for luma and 16-240 for chroma using OSDWIN0MD.ATN0E and OSDWIN1MD.ATN1E for the OSD windows, though the attenuation is automatically disabled when OSDWIN1 is being used as an attribute window. At the final display level the attenuation can be controlled with the ATRGB, ATYCC, and ATCOM fields in the VDPRO register, in your case for an RGB output you could set ATRGB so have the 0-255 ranges attenuated to the REC601 levels.
ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". TI AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY TI. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM TI.
Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.