Debugging experience-Image

Debugging experience-Image

With the development of chip technology, embedded devices also have strong image processing capabilities. Among them, DaVinci provides powerful image processing functions.
During the use of The DaVinci platform, we encountered several image-related problems:
1. Poor Image Quality;
2. The image color displayed on the upper computer is incorrect;
3. color components;
4. YUV data cropping during transmission.

I. Poor Image Quality

Background:
Before describing the problem, describe the development process of our embedded devices.
The main board is designed by hardware developers according to the principle diagram of the dm6446 Development Board. The software is developed using dvsdk1.3 as a development tool. The video input is a SD analog video, and the display can be connected to the output end of the video to view the image. After receiving the input image, arm sends it to the DSP. After the DSP analyzes the image, it returns the result to arm. Arm adds some results to the output image in OSD mode.
For a brief description of the buffer of the image:
The input buffer of dm6446 and the output buffer are in two different memory regions. The overlay OSD information is implemented in the output buffer.
In addition, there is a configuration software on the PC that can be configured on the device. One of the screenshot functions is to use the configuration software on the PC to issue the capture image command, and the embedded program executes the capture, that is, a YUV image is taken from the input image buffer and uploaded to the PC.

Symptom:
On the dm6446 platform, the analog video input of SD is connected to the monitor at the video output end to view the image. The following figure shows that the image quality is poor:
The movement of short colored bars is blurred. The movement of the moving objects in the attachment of the row where the short bars are located is jittery (the shape of the short colored bars is similar to the character information OSD that we overlay );
Not only does OSD cause image movement, but other eye-catching objects also have blurred images.
For a single screenshot, the image is also colored.
The bottom of the image is black and there is no image.

Further test:
Using the comparison method, the normal program runs, which includes both video input and video output, and many other functions. We simplified the system functions and compared and run tests in the same hardware environment.
Video loop program: input and output are available at the same time. The input image is directly sent to the output, and the output image is superimposed by OSD. At this time, the captured image still has an OSD image, and there is no image at the bottom of the image.
Video decoding and display program: this is a routine in the dvsdk. It decodes the video and outputs the video. The image is clear and complete.

Analysis:
The image has shadow movement, which is the interference of analog signals. When only video output is performed, the image is clear, indicating that there is no problem with the line of the video output part, and there is a problem with the line of the video input part.
Color bars are also available for captured images, indicating that video output has an impact on video input. OSD is only used for output, while image capture only applies to input images.
There is no image at the bottom of the image, which is a problem with the image settings of embedded software.

Cause:
The problem is divided into two parts: one is shadow moving on the image, and the other is no image at the bottom of the image.

Shadow on the image:
The video output line of the Board reversely goes through the entire board. One of them is very close to the input line and interferes with the input signal.
For this problem, we later learned that there is another test method to separate the input and output problems: vpbe can be set to color bar output to distinguish whether the source of output image display problems is image or driver.

No image at the bottom of the image:
An error occurred when setting Image Parameters. Because the OSD layer uses a half-byte representation of a pixel, the width of the OSD layer must be 32-byte aligned, resulting in a problem: 720/2 = 360 is not a multiple of 32. Therefore, you must use a multiple of 32 that is greater than 360 and closest to 384. In this system, is used:
OSD attribute layer: 384x576
When setting the transparency, the original set is 720 × 576/2, changed to 768 × 576/2, restored varinfo. yres = 576, images and OSD can be displayed in full screen.

The following table briefly describes the buffer of the video output:

Device name data content buffer size per pixel
/Dev/FB/0 --> OSD content 1440 × 576 2 (rgb565)
/Dev/FB/2 --> OSD transparency 384 × 576 0.5 (row width 384, effective use 360)
/Dev/FB/3 --> video image 1440x576 2 (uyvy)

2. The image color displayed on the host computer is incorrect.
Symptom:
On the display screen connected to the output end of the embedded device, the image is displayed normally. The images displayed are not normal when you capture images using the configuration software on the PC.
Analysis:
Abnormal image display is often the brightest place on the screen, possibly because some values are out of bounds during conversion,
Cause:
The analysis code is in the dm6446 System and the YUV is used, while the RGB is displayed on the PC. During format conversion, some values are out of bounds. For example, in an RGB color system, three 255 are white. If one of them crosses the border, two 255 S and one 0 s become yellow.

3. color components

High-definition image output, with three color components Y, CB, Cr, and output, with an external display with a chromatic aberration distribution line.

Component y, CB, Cr
Green, blue, and red with color lines

There is a big difference from what we usually call RGB. RGB's full 0 is black and the full 255 is white.

The typical colors of YCbCr are as follows:

0, 0, 0 green
Pink 255,255,255
255, yellow
255,255, 0 bright baskets

Iv. Cutting during YUV Data Transmission

Both bt656 and bt1120 cannot use 0 and 255. When 0 is encountered, it should be converted to 1; When 255 is encountered, it should be converted to 254.
No data is cut between the vport In and Out ports of dm6467. The kernel driver is used to Crop Data.

For example, in dvsdk1.4, if YUV data is transmitted using vport, no cropping is performed. In dvsdk3.10, the cropping between 0 and 255 is realized.

When data is cropping, it may lead to new problems. For example, if I want to overwrite the first line of YUV to transmit some information, data is not the original meaning.
At this point, we can use the data conversion method, that is, let 0 and 255 do not appear. In a simple method, I use two bytes to represent a byte: 0-253. I use 1 for the high byte, and 1-254 for the low byte, I can set the height byte to 2 and the low byte to 1-2.

Debugging experience-Image