Implementation method of liquid crystal smart television panel edge brightness demura compensation

Abstract

The application discloses a kind of liquid crystal intelligent television panel edge brightness demura compensation implementation method, comprising: step one, obtain the demura data format and original demura data of current screen;Step two, obtain the coordinate of screen edge with different brightness, make offset debugging, generate demura.bin file;Step three, demura.bin file is with original demura data and is handled by algorithm, obtains new demura data and is imported into display data after format conversion of main control chip and is handled;Step four, boot detection screen gray scale brightness is consistent;Step five, if the gray scale brightness of screen is not consistent, repeat the above steps.The application can realize the overall brightness consistency of screen by software method, solve the problem that screen edge brightness is inconsistent with overall brightness, improve the picture quality effect, and present a better picture quality experience for users.

Description

Technical Field

[0001] This invention relates to the field of LCD smart TV panel display technology, and specifically to a method for implementing edge brightness demura compensation for LCD smart TV panels. Background Technology

[0002] The manufacturing process of glass OCs for LCD TVs is complex, and uneven screen brightness and various defects can easily occur during production, severely impacting the user's viewing experience. These display defects are known as the mura phenomenon. To overcome this problem and ensure good brightness uniformity for each OC, screen manufacturers perform individual mura calibration on each OC during manufacturing, generating mura compensation data and storing it in the OC's memory.

[0003] Current demura solutions all use data processed by screen manufacturers. However, during the assembly process of screens processed by screen manufacturers into complete devices, due to factors such as the overall device manufacturing process or assembly molds, it is often found that the brightness gray field of the screen's four edges is different from that of the whole part, and the overall brightness of the screen does not appear uniform.

[0004] This situation significantly impacts the overall performance of LCD TVs. Existing technologies have provided some solutions to this problem. For example, Chinese invention patent CN114694552A discloses a display device and a method for handling display anomalies. This method involves storing two different demura data points in the display. When a display anomaly is detected and determined to be caused by the first demura data, the second demura data is acquired. The first demura data is used to compensate for the brightness of the first demura (brightness area) resulting from the combination of the backlight module and the display panel, while the second demura data is used to compensate for the brightness of the second demura (brightness area) of the display panel. The brightness of the abnormal brightness areas at the edges of the display is adjusted based on the second demura data. While this solution can adjust edge brightness using the second demura data, it cannot compensate for brightness issues caused by demura and bright edges resulting from components such as the backlight module in the display device, thus affecting the user experience. Summary of the Invention

[0005] One of the objectives of this invention is to provide a method that can dynamically adjust and generate new demura data according to actual conditions to perform demura compensation on the brightness of the LCD TV screen edge, thereby solving the problem of inconsistent brightness between the screen edge and the overall screen display brightness.

[0006] The present invention is implemented as follows:

[0007] A method for implementing edge brightness demura compensation in a liquid crystal smart TV panel includes:

[0008] Step 1: Obtain the demura data format and raw demura data for the current screen;

[0009] Step 2: Based on the current display status of the screen, obtain the grayscale image of the panel by taking a picture with a high-definition camera to obtain the coordinates of the screen edge with different brightness. Make offset adjustments based on the original demura data obtained in Step 1. After adjustment, make the brightness of the whole machine consistent. Make these adjusted data into a binary demura.bin file according to the current screen demura data format.

[0010] Step 3: During the demura data conversion process, the demura.bin file generated in Step 2 is processed with the original demura data to obtain new demura data. This new data is then used to convert the format of the main control chip before being imported into the display data for processing.

[0011] Step 4: Power on the device and check if the grayscale brightness of the screen is consistent;

[0012] Step 5: If the grayscale brightness of the screen is inconsistent, repeat steps 2 and 3 until the edge brightness of the screen is consistent with the overall screen brightness.

[0013] A further step is:

[0014] The current screen's demura data format includes the demura header format, the address and length of the LUT table, and other information.

[0015] A further step is:

[0016] Step one also includes obtaining the current FLASH size from the screen manufacturer.

[0017] A further step is:

[0018] The raw demura data is obtained from the screen via SPI communication.

[0019] A further step is:

[0020] Step two, offset adjustment specifically includes:

[0021] For coordinates with varying brightness at the screen edges, an offset is applied to the parameters of the current coordinates based on the original demura data obtained in step one. The offset data is recorded, and the process is repeated until a satisfactory result is achieved. Then, a demura.bin file is generated based on the final offset value and the demura data format of the current screen.

[0022] A further step is:

[0023] Step three specifically includes:

[0024] Place the demura.bin generated in step two into the corresponding screen parameter directory, such as / panelname / demura.bin, and verify demura.bin during boot.

[0025] According to the demura data format, obtain the size of the brightness data; obtain the size of the original demura data through the SPI interface. If the size of the compensated LUT data and the LUT data of the original demura data are the same, the verification passes and proceeds to the next step; otherwise, the size of the compensated LUT data does not match, and no demura compensation is performed.

[0026] After the verification is successful, the data in the LUT table in demura.bin is converted into Plane grayscale data according to the data format provided by the screen manufacturer.

[0027] The generated data is algorithmically compensated with the LUT data in the original demura data table to form new demura data. This new data is then used by the main control chip to generate the actual demura_out.bin file, which is then imported into the display data for processing.

[0028] A further step is:

[0029] The new demura data is generated according to the original demura data structure.

[0030] A further step is:

[0031] After generating demura_out.bin in step three, you also need to validate demura_out.bin and write the value into the attribute.

[0032] A further step is:

[0033] Step four specifically includes:

[0034] Upon restarting, the system verifies the attributes and reads a segment of data from the screen manufacturer's LUT table. It then checks for consistency using the CRC algorithm provided by the manufacturer. Once both conditions are met, the generated demura_out.bin file is directly used by the main control chip.

[0035] This invention adjusts the original demura data from the original OC (Optical Character Set) chip to create new demura data. This new data is then converted by the main control chip before being imported into the display data for processing. Through this solution, the invention achieves overall screen brightness consistency via software, resolving the issue of inconsistent brightness between screen edges and the overall brightness, thus improving image quality and providing users with a better viewing experience. Attached Figure Description

[0036] Figure 1 This is a flowchart illustrating a method for implementing edge brightness demura compensation in a liquid crystal smart TV panel according to an embodiment of the present invention.

[0037] Figure 2 This is a flowchart illustrating the power-on process for edge compensation brightness data according to an embodiment of the present invention. Detailed Implementation

[0038] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0039] As attached Figure 1 As shown, a method for implementing edge brightness demura compensation in a liquid crystal smart TV panel includes:

[0040] S1. Based on the screen model, obtain the current FLASH size and complete demura data storage format from the screen manufacturer, including the demura header format, LUT table address, length, and other information.

[0041] S2. Use commands to read the original demura data of the screen FLASH as a new reference for brightness adjustment;

[0042] S3. Obtain grayscale images of the panel by shooting with a high-definition camera, obtain the different brightness coordinates of the screen edge, refer to the demura data obtained in S2, and adjust the algorithm to make the brightness of the whole machine consistent. These adjusted data are made into a binary demura.bin file according to the format given by the manufacturer.

[0043] The specific process for algorithm debugging can be as follows:

[0044] A grayscale image of the panel is acquired by capturing images with a high-definition camera to obtain the coordinates of transitions or uneven brightness at the screen edges. Then, based on the previously acquired demura data (e.g., 127, which may result in uneven brightness), an offset is applied to the current parameter, such as 135 or 126. The offset is recorded, and other coordinates are calculated using this offset, creating a loop for continuous detection until a satisfactory result is achieved. Finally, the adjusted offset values ​​corresponding to these coordinates are obtained, and a binary demura.bin file is generated according to the current screen's demura format.

[0045] S4. Place the binary demura.bin generated in S3 into the corresponding screen parameter directory, for example, under / panelname / demura.bin;

[0046] This screen parameter directory is the location where the debugged demura.bin file is placed. The original demura data does not have a directory; it is stored in the screen's FLASH memory and read from the screen via SPI communication. This demura.bin file indicates the compensation algorithm used by this screen, performing compensation processing compared to the original demura data on the screen.

[0047] S5. When powering on, verify demura.bin and obtain the size of the brightness data according to the demura data format; obtain the size of the original demura data through the SPI interface. If they are the same, proceed to step S6; otherwise, if the compensation LUT data size does not match, no demura compensation is performed.

[0048] The purpose of this step is to determine whether the compensation data and the demura data format on the screen are the same, and whether the LUT data length is the same. Because the FLASH size is 4MB for the same CSOT screen, it's necessary to determine whether the demura.bin compensation data matches the current screen's storage format. Therefore, step S1 first obtains the screen manufacturer's demura data storage format. If the storage formats are inconsistent, such as a mismatch in LUT data size, then the current demura.bin compensation data cannot compensate for the original demura data.

[0049] After S6 and S5 verifications pass, the data in the LUT table in demura.bin is converted into Plane grayscale data according to the data format provided by the screen manufacturer. Because demura.bin stores data in 8-byte format, and Plane precision is 12-bit, it needs to be converted into actual Plane grayscale data.

[0050] For example, in the COST screen, the data is represented using 12 bits, with 10 bits representing positive numbers and 2 bits representing negative numbers; two 8-byte data bytes are converted into one 12-bit data byte.

[0051] For example, the demura data precision of Huaxing screens is 12-bit. Plane grayscale is represented by two bytes, with each row consisting of 128 bits, padded with 0s at the high end. Therefore, each row has 16 bytes. Three 8-byte values ​​are combined into two 12-bit Plane data, with the last one discarded. demura.bin converts Planes in the same way. Then, the Plane0 on the screen is added to the Plane0 in demura.bin with an offset, generating a Plane0 that only uses 12 bits. This 12-byte Plane0 is then converted back to 2 bytes.

[0052] For example: a line of original data: c3 3f fc c5 7f fc ca cf fc cf 2f fd d3 6f fd 0

[0053] A. The transformed Plane --> fc3 fc3 fc5 fc7 fca fcc fcf fd2 fd3 fd6

[0054] Compensation bin: c8 1f 0 8a 40 8 87 90 8 82 d0 7 85 80 7 0

[0055] B. Transformed Plane --> fc8 1 8a 84 87 89 82 7d 85 78

[0056] Last bin:

[0057] The value after A+B (take 12 bits) is: f8b fc4 04f 04b 051 055 051 04f 058 04E

[0058] Restore it to its previous state:

[0059] 8b 4f fc 4f b0 4 51 50 5 51 f0 4 58 e0 4 0

[0060] BOE follows the same method, using 12-bit precision according to its specifications. The only difference from CSOT is that it doesn't use a 128-bit group with high-order bits padded with 0s. Other conversion methods are similar.

[0061] The data generated by S7 and S6 are algorithmically compensated with the LUT data in the original demura data table to form new demura data. This new data is then used by the main control chip to generate the actual demura_out.bin file, which is then imported into the display data for processing.

[0062] Specifically, in S6, the converted Plane grayscale data is algorithmically compensated with the Plane grayscale data in the LUT table on the screen to form new demura data. Since the LUT data on the screen is also stored in 8-byte increments, it also needs to be converted into Plane grayscale data using the same method.

[0063] S8. Perform a verification on demura_out.bin and write the value into the attribute. The reason for this step is to avoid performing demura algorithm compensation every time the system boots up, thus saving boot time.

[0064] S9. Upon restarting, the system will verify the attributes of S8 and read a segment of data from the screen manufacturer's LUT table. It will then check for consistency using the CRC algorithm provided by the manufacturer. If both conditions are met, the generated demura_out.bin file will be directly used for the main control chip. Details of this step are attached. Figure 2 As shown.

[0065] As described above, the algorithm is run only once. If a new demura.bin file is needed, the algorithm is run again, and a new demura_out.bin file is generated. This step is used to determine whether demura.bin has been updated. Clearing environment variables or deleting demura_out.bin during manual debugging will cause the algorithm to run again to generate environment variables and the demura_out.bin file.

[0066] S10. If the verification of S9 does not meet the requirements, then re-execute S5, S6, S7, and S8 to generate new demura_out.bin data.

[0067] Although the present invention has been described herein with reference to illustrative embodiments, the above embodiments are merely preferred embodiments of the present invention, and the implementation of the present invention is not limited to the above embodiments. It should be understood that those skilled in the art can devise many other modifications and implementations, which will fall within the scope and spirit of the principles disclosed in this application.

Claims

1. A method for implementing edge brightness demura compensation in a liquid crystal smart TV panel, characterized in that... include: Step 1: Obtain the demura data format and raw demura data for the current screen; Step 2: Based on the current display status of the screen, obtain the grayscale image of the panel by taking a picture with a high-definition camera to obtain the coordinates of the screen edge with different brightness. Make offset adjustments based on the original demura data obtained in Step 1. After adjustment, make the brightness of the whole machine consistent. Make these adjusted data into a binary demura.bin file according to the current screen demura data format. Step 3: During the demura data conversion process, the demura.bin file generated in Step 2 is processed with the original demura data to obtain new demura data. This new data is then used to convert the format of the main control chip before being imported into the display data for processing. Step 4: Power on the device and check if the grayscale brightness of the screen is consistent; Step 5: If the grayscale brightness of the screen is inconsistent, repeat steps 2 and 3 until the edge brightness of the screen is consistent with the overall screen brightness. Step three specifically includes: Place the demura.bin generated in step two into the corresponding screen parameter directory, and verify demura.bin during boot; According to the demura data format, obtain the size of the brightness data; obtain the size of the original demura data through the SPI interface. If the size of the compensated LUT data and the LUT data of the original demura data are the same, the verification passes and proceeds to the next step; otherwise, the size of the compensated LUT data does not match, and no demura compensation is performed. After the verification is successful, the data in the LUT table in demura.bin is converted into Plane grayscale data according to the data format provided by the screen manufacturer. The generated data is algorithmically compensated with the LUT data in the original demura data table to form new demura data. This new data is then used by the main control chip to generate the actual demura_out.bin file, which is then imported into the display data for processing.

2. The method for implementing edge brightness demura compensation of a liquid crystal smart TV panel according to claim 1, characterized in that: The current screen's demura data format includes the demura header format, the address of the LUT table, and its length information.

3. The method for implementing edge brightness demura compensation of a liquid crystal smart TV panel according to claim 1, characterized in that: Step one also includes obtaining the current FLASH size from the screen manufacturer.

4. The method for implementing edge brightness demura compensation of a liquid crystal smart TV panel according to claim 1, characterized in that: The raw demura data is obtained from the screen via SPI communication.

5. The method for implementing edge brightness demura compensation of a liquid crystal smart TV panel according to claim 1, characterized in that: Step two, offset adjustment specifically includes: For coordinates with varying brightness at the screen edges, an offset is applied to the parameters of the current coordinates based on the original demura data obtained in step one. The offset data is recorded, and the process is repeated until a satisfactory result is achieved. Then, a demura.bin file is generated based on the final offset value and the demura data format of the current screen.

6. The method for implementing edge brightness demura compensation of a liquid crystal smart TV panel according to claim 1, characterized in that: The new demura data is generated according to the original demura data structure.

7. The method for implementing edge brightness demura compensation of a liquid crystal smart TV panel according to claim 1, characterized in that: The screen parameter directory is located under / panelname / demura.bin.

8. The method for implementing edge brightness demura compensation of a liquid crystal smart TV panel according to claim 6 or 7, characterized in that: After generating demura_out.bin in step three, you also need to validate demura_out.bin and write the value into the attribute.

9. The method for implementing edge brightness demura compensation of a liquid crystal smart TV panel according to claim 8, characterized in that: Step four specifically includes: Upon restarting, the system verifies the attributes and reads a segment of data from the screen manufacturer's LUT table. It then checks for consistency using the CRC algorithm provided by the manufacturer. Once both conditions are met, the generated demura_out.bin file is directly used by the main control chip.

Images