On the non-gaming side, the objective of video display architecture is to resolve the display limitations and solutions with minimal inputs of additional cost, energy, and time (time here refers to the response time of the display not necessarily the time to develop the solution). The solution is, of course, different depending on the display and the application. Even within a particular type of display, a multi-domain TFT LCD has different characteristics from an IPS mode LCD, so developing a “one size fits all” solution is difficult and producing a completely optimized solution is impossible without supplementing the display Electronic Digital ID (EDID) with additional information about display type and performance.
In TV display architectures, when a given image is provided, the normal process is to convert that image from whatever format into a yUV image to do cosmetic corrections. The usual process is to first do:
• Noise combing,
• edge identification for edge enhancement,
• motion estimation:
......for response judder recognition and elimination and
......response time improvement,
• facial identification:
......for ideal facial color mapping and
• blues stretch (enabling perceived blues outside of the normal color gamut of the display),
• green stretch,
• dynamic contrast enhancement (backlight dimming).
After the image modification is complete then it is converted to an rgb image and sent via the LVDS to the digital display. While all of this is going on the audio is being processed then held in a delay loop (the video processing for a real image takes long enough that there would be a noticeable timing difference between the audio and the video so the audio is held until the video is ready... gamers will notice that without a gaming mode that turns of the image processing and audio delay, an LCD TV responds at least 1/2 second behind their inputs, spoiling their performance). Once the video is received by the display, some further response time improvement is provided by the overdrive in the display’s embedded processor. Because different displays have different response times and because there are two processing circuits (one on the device side, one on the display side... that do not communicate with each other) handling response time improvement, there is necessarily some tuning that must be done to ensure that the combination of the device side response time improvement and the display side response time improvement do not produce any notable visual artifacts. This is particularly true if the device would have to interface with both computing LCDs (normally off-state white) and entertainment displays (usually off-state black). Finally, if the display has a “blinking backlight” or some form of dynamic contrast embedded in its own processing, then this becomes a further area of conflict between the device and the display that must be tuned further.