Signal source equipment test signal generation method and related equipment

Abstract

The invention discloses a signal source equipment test signal generation method and related equipment, and relates to the technical field of test signal generation, and the method comprises the steps: obtaining test demand information comprising a test signal identifier and the output resolution of signal source equipment; determining a corresponding XML file according to the test signal identifier, and obtaining graphic elements and parameters defined by each shape segment in the XML file; converting the parameter of each graphic element into an absolute pixel parameter according to the output resolution of the signal source equipment; drawing a corresponding graphic element on the canvas based on each converted absolute pixel parameter; converting the canvas drawn with all the graphic elements into target image data according to the output bit depth defined in the XML file; and generating a test signal based on the target image data. A unified and flexible test signal generation mechanism is formed, and the problems of signal file redundancy and complex management are efficiently solved while it is ensured that software is easy to maintain.

Description

Technical Field

[0001] This invention relates to the field of test signal generation technology, and in particular to a test signal generation method and related equipment for a signal source device. Background Technology

[0002] Signal source devices need to generate various test signals and send them to the device under test (DUT) for performance verification. Test signals are diverse, covering different geometric shapes, color patterns, and dynamic sequences to meet various testing scenarios. How to efficiently and flexibly define, manage, and generate these test signals in signal source devices, while ensuring easy software maintenance and controllable resource overhead, is a common technical challenge.

[0003] Currently, common implementation methods mainly fall into two categories. One method involves directly writing the specific parameters and generation logic of all test signals into the software source code of the signal source device. After compilation, this signal information is embedded within the program. The other method pre-calculates and generates each test signal as a complete, independent file (such as an image file or binary data file) containing the final pixel data. During runtime, the software loads the corresponding signal file as needed and outputs it directly.

[0004] However, all of the above-mentioned existing methods have significant limitations. For the method of writing signal information into the code, any addition, deletion, or parameter modification of a test signal requires changes to the source code and recompiling the entire software. This leads to frequent software version iterations, with the version history filled with numerous signal configuration updates unrelated to core functionality, severely interfering with the software's version management and maintenance. While using independent signal files achieves separation of signals from software, to adapt to different output resolutions, refresh rates, or color formats, test signals with the same logical meaning need to be pre-made into multiple copies of files of different specifications. This not only multiplies the number of signal files, complicating file storage and management, but also significantly increases the workload of signal library creation and subsequent maintenance.

[0005] Therefore, there is an urgent need for a new test signal generation method that can decouple the definition of test signals from the software implementation, avoiding the need to recompile the software due to signal changes. At the same time, the method should support flexible adaptation of signal definitions, avoiding the generation and storage of a large number of redundant signal files for different output specifications, thereby significantly reducing the complexity of test signal creation and maintenance while ensuring software stability. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to address the shortcomings of the prior art, and specifically provides a method for generating test signals for a signal source device and related equipment, as detailed below: 1) In a first aspect, the present invention provides a method for generating test signals for a signal source device, the specific technical solution of which is as follows: The process involves: acquiring test requirement information, including the test signal identifier and the output resolution of the signal source device; determining the corresponding XML file based on the test signal identifier, where the XML file defines at least one graphic element used to constitute the test signal and the parameters of each graphic element; acquiring the graphic elements and parameters defined in each shape segment of the XML file; converting the parameters of each graphic element into absolute pixel parameters based on the output resolution of the signal source device; drawing the corresponding graphic element on the canvas based on each converted absolute pixel parameter; converting the canvas with all graphic elements drawn on it into target image data based on the output bit depth defined in the XML file; and generating the test signal based on the target image data.

[0007] The beneficial effects of the signal generation method for a signal source device provided by this invention are as follows: By identifying the corresponding XML file based on the test signal identifier, the specific components of the test signal are defined as graphical elements and parameters and stored in a separate XML file, achieving complete decoupling between the test signal information and the signal source device software code. When adding, modifying, or deleting test signals, only the corresponding XML file needs to be edited or replaced, without touching or recompiling the software source code, thus effectively maintaining the purity and stability of the software version. Furthermore, the parameters of the graphical elements in the XML file can be defined using proportional values ​​relative to the image width or height, allowing the same set of signal definitions to be dynamically converted into corresponding absolute pixel parameters based on the output resolution of the signal source device acquired in real time. This feature enables a single XML file to adapt to multiple different output resolutions, eliminating the need to pre-create and store separate complete signal files for each resolution, thereby significantly reducing the number of signal files that need to be maintained and fundamentally reducing the workload of building and maintaining the signal library. The entire methodology, from parsing test requirements to generating the final target image data, forms a unified and flexible test signal generation mechanism, efficiently solving the problems of signal file redundancy and complex management while ensuring easy software maintenance.

[0008] Based on the above scheme, the method for generating test signals for a signal source device according to the present invention can be further improved as follows.

[0009] Furthermore, it also includes: when drawing graphic elements on the canvas, if the drawn graphic element overlaps with an existing graphic element on the canvas, the pixel values ​​of the overlapping area are calculated for transparency blending based on the transparency parameter of the currently drawn graphic element.

[0010] The beneficial effect of adopting the above-mentioned further solution is that when graphic elements overlap, the pixel values ​​of the overlapping area are synthesized based on the transparency parameter of the current graphic elements, achieving a natural fusion of color and hierarchy. This expands the expressive power of the test signal, allowing the generation of test patterns containing complex visual features such as semi-transparency effects and color gradient overlays, thereby enabling a more comprehensive and precise evaluation of the device under test's ability to process and display mixed images and transparency levels.

[0011] Furthermore, the parameters of the graphic element include relative parameters representing the position and / or size of the graphic element, which are fractional values ​​representing the proportion of the image width or image height relative to the output resolution of the signal source device.

[0012] The beneficial effect of adopting the above-mentioned further solution is that defining the relative parameters of the position and size of graphic elements in fractional form makes these parameters proportional values ​​relative to the image width or height. This definition method allows the test signal description in the same XML file to be independent of the specific output resolution. When the signal source device needs to generate the same test signal at different resolutions, the system can directly and dynamically calculate the corresponding absolute pixel parameters based on the current output resolution, without needing to create and maintain separate signal definition files for each resolution. This greatly enhances the versatility and reusability of signal definitions and effectively reduces the complexity and maintenance cost of the signal library.

[0013] Furthermore, the graphic elements defined in the XML file include at least one of rectangles, circles, windows, color bars, grayscale, single-pixel signals, checkerboard patterns, and external images.

[0014] The beneficial effects of adopting the above-mentioned further solution are: it allows XML files to define various graphic elements such as rectangles, circles, windows, color bars, grayscale, single-pixel signals, checkerboard patterns, and external images. This technical feature greatly enriches the composition capabilities and representation forms of test signals. Users can flexibly construct various test signals, ranging from simple geometric shapes to complex composite patterns, by combining these basic graphic elements. This avoids writing separate code or pre-generating a large number of image files for each possible test pattern, enabling a unified description mechanism to cover a wide range of test scenario requirements. This approach improves the expressiveness and efficiency of signal definition while maintaining the ability to comprehensively evaluate the performance of various display devices.

[0015] 2) In a second aspect, the present invention also provides a signal generation system for a signal source device, the specific technical solution of which is as follows: The system includes a test requirement information acquisition module, a file determination module, a graphic element and parameter acquisition module, a first conversion module, a drawing module, a second conversion module, and a test signal generation module. The test requirement information acquisition module acquires test requirement information, including the test signal identifier and the output resolution of the signal source device. The file determination module determines the corresponding XML file based on the test signal identifier. The XML file defines at least one graphic element used to constitute the test signal and the parameters of each graphic element. The graphic element and parameter acquisition module acquires the graphic elements and parameters defined in each shape segment of the XML file. The first conversion module converts the parameters of each graphic element into absolute pixel parameters based on the output resolution of the signal source device. The drawing module draws the corresponding graphic element on the canvas based on each converted absolute pixel parameter. The second conversion module converts the canvas containing all graphic elements into target image data based on the output bit depth defined in the XML file. The test signal generation module generates the test signal based on the target image data.

[0016] Based on the above scheme, the signal generation system for a signal source device of the present invention can be further improved as follows.

[0017] Furthermore, the drawing module is also used to: when drawing graphic elements on the canvas, if the drawn graphic element overlaps with an existing graphic element on the canvas, perform transparency mixing calculation on the pixel values ​​of the overlapping area based on the transparency parameter of the currently drawn graphic element.

[0018] Furthermore, the parameters of the graphic element include relative parameters representing the position and / or size of the graphic element, which are fractional values ​​representing the proportion of the image width or image height relative to the output resolution of the signal source device.

[0019] Furthermore, the graphic elements defined in the XML file include at least one of rectangles, circles, windows, color bars, grayscale, single-pixel signals, checkerboard patterns, and external images.

[0020] 3) In a third aspect, the present invention also provides an electronic device, the electronic device including a processor coupled to a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to enable the electronic device to implement any of the above-mentioned signal source device test signal generation methods.

[0021] 4) In a fourth aspect, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described signal source device test signal generation methods.

[0022] It should be noted that the beneficial effects of the technical solutions of the second to fourth aspects of the present invention and their corresponding possible implementations can be found in the above description of the technical effects of the first aspect and its corresponding possible implementations, and will not be repeated here. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below: Figure 1 This is a flowchart illustrating a method for generating test signals for a signal source device according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of a signal source device test signal generation system according to an embodiment of the present invention. Detailed Implementation

[0024] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0025] The technical solution of the present invention and how the technical solution of the present invention solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0026] like Figure 1 As shown, an embodiment of the present invention provides a method for generating test signals for a signal source device, comprising the following steps: S1. Obtain test requirement information including test signal identifier and output resolution of signal source device. The specific implementation process is as follows: S10. The operator or automated test script initiates a test request through the human-machine interface or application programming interface provided by the signal source device. In this step, the operator needs to explicitly specify two key parameters. The first parameter is the type of the required test signal, which is done by selecting from the device's built-in signal library list or directly entering a string. This selection or input is internally mapped to the corresponding test signal identifier. The second parameter is the desired output resolution of the signal source device. The operator can typically select from a preset resolution list (such as 720p, 1080p, or 4K), or manually enter custom width and height pixel values. The user interface is responsible for receiving these two sets of input data.

[0027] S11. The control software includes a dedicated configuration management module that maintains a mapping database or configuration file. This database records the association between each valid test signal identifier and its corresponding XML configuration file in the device's storage system. When the control software receives the test signal identifier and output resolution parameters submitted by the operator from the user interface, it first verifies the validity of the test signal identifier, i.e., checks whether the identifier exists in the mapping relationship. Simultaneously, it also verifies whether the output resolution parameters conform to the format range supported by the device hardware.

[0028] S12. After passing the validity check, the control software packages the two parameters—the test signal identifier and the output resolution of the signal source device—along with necessary session information (such as timestamps, request sources, etc.) into an internal data structure. This data structure is the complete test requirement information. Specifically, this data structure can be defined as a record containing multiple fields. The field Signal_ID stores the string-type test signal identifier; the field Output_Width stores the integer-type output image width in pixels; and the field Output_Height stores the integer-type output image height in pixels. For example, a test requirement requesting the generation of a "color bar overlay grayscale test" pattern and outputting it at a resolution of 1920×1080 would be internally represented as: {Signal_ID:"Test_Pattern_007",Output_Width:1920,Output_Height:1080}. This structured test requirement information object is then passed to the test signal generation module as input and basis for the entire generation process, thereby driving subsequent operations such as XML file reading, parameter conversion, and graphic drawing.

[0029] The test signal identifier is a string or code that uniquely identifies the target test signal. In the software system of the signal source device, each available test signal is pre-associated with a unique test signal identifier. This identifier typically corresponds to the name or internal ID of an XML file describing the specific composition of the test signal. When the operator or the upper-level control system needs to generate a specific test signal, it doesn't directly describe all the details of the signal; instead, it informs the system of the target signal's identity by providing this test signal identifier. For example, the operator can select the "Color Bar Overlay Grayscale Test" option in the user interface, and the corresponding test signal identifier could be "Test_Pattern_007". By parsing this test signal identifier, the system can locate the configuration file named "Test_Pattern_007.xml" stored in a specific directory of the device, thereby obtaining all the graphical element definitions for generating the signal.

[0030] The test requirement information is a structured dataset that encapsulates all the initial parameters necessary to initiate a test signal generation task. The core components of the test requirement information are the test signal identifier and the output resolution of the signal source device. Depending on the complexity of the system design, it may also include other information such as output interface type, frame rate, and color space. However, in the context of this technical solution, output resolution is one of the most critical dynamic parameters. The output resolution of the signal source device defines the pixel size of the final generated image, i.e., the total number of pixels in the width and height directions, for example, 1920×1080 pixels. This parameter directly determines the benchmark for converting the relative position and size parameters in the XML file into actual pixel values ​​in subsequent steps. Therefore, preparing the test requirement information essentially establishes a clear target specification and content index for all subsequent calculation and rendering steps.

[0031] S2. Determine the corresponding XML file based on the test signal identifier. The XML file defines at least one graphic element used to constitute the test signal and the parameters of each graphic element.

[0032] The specific implementation process of S2 is as follows: S20. Establish and maintain the mapping relationship between test signal identifiers and XML file paths. During the software initialization or configuration file loading phase of the signal source device, a global mapping configuration file is read. This mapping configuration file can be a separate index file, such as a JSON or INI format file, or a built-in database table. The mapping relationship is stored in the form of key-value pairs, where the key is the test signal identifier and the value is the complete path of the corresponding XML file in the device's file system. For example, a mapping entry might be: "ColorBar_Test": " / SignalPatterns / ColorBar_Test.xml". The establishment of this mapping relationship provides a basis for quickly locating the file based on the identifier.

[0033] S21. Parse the received test signal identifier and retrieve the corresponding XML file path. The test signal generation module extracts the test signal identifier field from the structured test requirement information received from upstream. The management unit within the module uses this extracted test signal identifier as a query key to search within the established mapping relationship. The search process is a string matching process. If a completely matching key is found, the search operation is successful, and the XML file path string bound to the test signal identifier is obtained. If no match is found, the test signal identifier is determined to be invalid, the process terminates, and an error message is returned upstream.

[0034] S22. Call the file input / output interface to attempt to open and read the XML file pointed to by the path. The file loading process includes an existence check, confirming that the file exists at the specified path. After the file is successfully read into memory, the system calls the XML parser to perform syntax validation on the file content, checking whether it conforms to basic XML format specifications, such as whether tags are closed and whether attribute values ​​are formatted correctly. Furthermore, the system verifies whether the file root node is a predefined image segment and checks whether it contains the necessary bit depth parameter bit_depth definition. File validation ensures that subsequent parsing operations are based on a correctly structured and valid configuration source.

[0035] S23. After the XML file passes validation, the system begins parsing its Document Object Model (DOM). The parsing process starts from the root node, the `image` segment, and sequentially traverses its child nodes. All `shape` segment nodes are identified. For each `shape` segment, its `type` attribute is read to determine the type of graphic element, such as rectangle, circle, or bar. Simultaneously, all other attributes defined within the `shape` segment are extracted as parameters for the graphic element, forming a parameter set. During extraction, the system pays special attention to position and size parameters expressed as fractions, such as `start_x` (the starting position of the graphic element in the horizontal direction, i.e., the X-axis, a value relative to the entire image width), `width` (the width of the graphic element, i.e., its horizontal dimension, a value relative to the entire image width), and `region_height` (the height of the drawing area). These attributes can have values ​​like "1 / 2" or "3 / 4". These fractional strings are preserved as is in the parameter set, to be converted in subsequent steps based on the output resolution of the specific signal source device. All `shape` segments and their parameters are extracted sequentially and stored in an ordered list, the order of which reflects the drawing order of the graphic elements on the final image. At this point, the process of identifying the corresponding XML file based on the test signal identifier and extracting the graphical element parameter definitions from it is complete, preparing the data for the next step of parameter conversion.

[0036] The test signal identifier is represented by an XML file, a text configuration file stored in Extensible Markup Language (XML) format. This file is physically stored in the non-volatile memory or accessible file system of the signal source device. Each XML file uniquely corresponds to a test signal identifier, and its filename is typically strictly consistent with the identifier or associated through a mapping table. The XML file's content defines all the graphical element information required to construct a test signal using structured tags, including the type, geometric attributes, color attributes, and overlay relationships of the graphical elements. By reading and parsing this file, the system can determine how to generate the corresponding test signal without modifying the software code.

[0037] In this context, the parameters of a graphic element are attribute key-value pairs defined within the `shape` section of the XML file, used to precisely describe the visual characteristics and spatial attributes of a graphic element. Parameters include type parameters, geometric parameters, and color parameters. For example, the parameters of a rectangular graphic element might include `type="rectangle"`, `start_x="1 / 4"`, `width="1 / 2"`, and `red` component `red="1023"`. Among these parameters, the relative parameters representing position and size are particularly important, as they form the basis for achieving resolution adaptation. Relative parameters are used to represent the relative position and / or size of a graphic element, specifically as a fractional value representing the proportion of the image width or height corresponding to the output resolution of the signal source device. The concept that "relative parameters are fractional values ​​representing the proportion of the image width or height corresponding to the output resolution of the signal source device" means that some parameter values ​​of a graphic element are not given as direct pixel counts, but rather as a fraction consisting of a numerator and a denominator. The result of this fraction calculation is a proportion relative to the width or height of the entire target image. For example, the parameter `start_x="1 / 4"` indicates the horizontal starting position of the top-left corner of the graphic element, located at one-quarter of the horizontal width of the entire image. If the output resolution of the signal source device corresponds to an image width of 1920 pixels, then the absolute pixel position after conversion of this relative parameter is 1920 pixels multiplied by one-quarter, which is 480 pixels. This representation decouples the layout definition of the graphic element from the specific resolution of the final output, allowing the same set of parameters to adapt to different output resolutions.

[0038] S3. Obtain the graphic elements and parameters defined in each shape segment of the XML file. The specific implementation process is as follows: S30. After successfully loading the XML file content into the memory buffer, the system calls a function of an XML parsing library to parse the file content into a tree-structured Document Object Model (DOM). From this DOM, the system first obtains the root node, i.e. Node. Verifying that the root node exists and has the correct name is fundamental to all subsequent parsing operations.

[0039] S31, Read the root node The `bit_depth` attribute value is read as a string and then converted to an integer value, denoted as `bit_depth_global`. This `bit_depth_global` value is stored in a global variable or context structure in memory because it serves as the bit depth reference for subsequent parsing of color value parameters (such as the intensity values ​​of the red, green, and blue components, the alpha channel value, the start color value, and the end color value) in all shape segments. For example, if `bit_depth_global` is 10, the maximum valid value for color parameters in the XML file should be 10. .

[0040] S32. Starting from the root node, traverse all its child nodes. For each child node, check if its node name is "shape". Collect all nodes named "shape" and place them into an ordered list or array according to their order of appearance in the document. This ordered list is crucial, as it defines the drawing order of the graphic elements.

[0041] S3. Process each shape node iteratively, extracting the graphic element type and basic parameters. Specifically, enter a loop and process each collected shape node sequentially. For the currently processed shape node: First, read the string value of its `type` attribute, which directly indicates the type of graphic element, such as "rectangle", "circle", "greyscale", "image", etc. Next, read all other attribute name and value string pairs defined on the node, forming a raw "parameter name-value" mapping table. For example, for a circle node, you can read key-value pairs such as the horizontal coordinate of the center `center_x="1 / 2", the vertical coordinate of the center `center_y="1 / 3", the outer radius `radius_out="1 / 10", and `red="1023"`.

[0042] S34. After obtaining the basic parameter mapping table, the system enters different parsing logic branches based on the extracted type value. Each branch targets a specific type of graphic element and expects a specific set of parameters. The system checks whether the parameter names required for that type exist in the parameter mapping table. For example, for the "rectangle" type, it checks whether start_x, start_y, width, height, red, green, blue, and alpha exist; for the "greyscale" type, it checks the horizontal starting position region_x of the grayscale pattern at the top left corner of the drawing area, the vertical starting position region_y of the grayscale pattern at the top left corner of the drawing area, the width region_width of the grayscale pattern, the height region_height of the grayscale pattern, the number of rows row_num, the number of columns column_num, the starting grayscale value start_color, the ending grayscale value end_color, and the transparency alpha, etc. For the "image" type, it also checks whether the image file pointed to by the path exists and is readable. The parameter values ​​remain in their original string form at this stage, but basic format validation is performed (such as whether the fraction format satisfies "a / b", and whether the numeric string can be converted to an integer).

[0043] S35. For each successfully parsed shape node, the system generates a graphical element description object. This object contains the following fields: graphical element type (type), original parameter mapping table (attributes), and bit depth reference value inherited from the global scope (bit_depth_global). This description object is then added to the graphical element list specific to this signal generation task. This loop continues until all shape nodes have been processed.

[0044] S36. After all shape nodes have been traversed and processed, an ordered list containing all graphic element description objects is constructed. This list completely represents all graphic elements and their parameters defined in the XML file. This list, as the output of this step, is passed to subsequent steps in the technical solution, namely, preparing for parameter transformation and drawing. At this point, the process of obtaining the graphic elements and parameters defined in each shape segment of the XML file is complete.

[0045] The graphic elements defined in the XML file include at least one of the following: rectangle, circle, window, color bar, grayscale, single pixel signal, checkerboard, and external image.

[0046] The `shape` segment is a child node located under the `image` root node in the XML file, used to encapsulate the complete definition of an independent graphic element. Each `shape` segment begins with... <shape> Starting with tags,< / shape>The tag ends. Within the shape section, a graphic element is described using a set of predefined attributes. Among these attributes, the type attribute specifies the type of graphic element, such as rectangle or circle. Other attributes define the specific parameters of the graphic element, such as position, size, color, and transparency. An XML file can contain multiple shape sections, and their order of appearance directly determines the order in which these graphic elements are superimposed and drawn on the final generated test signal image.

[0047] Grayscale is a test graphic element used to generate a series of rectangular areas with a smooth or stepped transition in brightness from dark to light. In the `shape` section, when the `type` attribute is "greyscale", a grayscale graphic element is defined. Its parameters, in addition to defining the drawing area's `region_x`, `region_y`, `region_width`, and `region_height`, also include `row_num` (number of rows), `column_num` (number of grayscale levels per row), `start_color` (starting grayscale value), and `end_color` (ending grayscale value). Based on these parameters, the system divides the specified rectangular area into multiple sub-rectangles and fills each sub-rectangle with a calculated grayscale value, thus forming a pattern used to test the grayscale reproduction capability of the display device.

[0048] A single-pixel signal is a test graphic element used to generate a grid pattern of extremely fine lines, often used to evaluate the focusing performance or pixel structure of display devices. In the `shape` section, when the `type` attribute is "fence", it indicates that a single-pixel signal graphic element has been defined. Its key parameters include `region_x`, `region_y`, `region_width`, `region_height` (defining the drawing area), `direction` (0 for vertical, 1 for horizontal), and `pix_width` (the pixel width of the lines). Based on the direction parameters, the system alternately draws lines and spaces of the specified width within the area to generate a grid pattern.

[0049] An external image is a test graphic element that allows bitmap file images stored externally to the signal source device to be inserted as subimages into the generated test signal. In the `shape` section, when the `type` attribute is "image", it indicates that an external image element has been defined. Its parameters include the insertion position (`start_x`, `start_y`), scaling ratios (`scale_w`, `scale_h`), scaling references (`base_w`, `base_h`), and the path to the image file (`path`). This enables referencing and flexible integration of complex pre-stored image resources.

[0050] S4. Based on the output resolution of the signal source device, convert the parameters of each graphic element into absolute pixel parameters. The specific implementation process is as follows: S40. Extract the output resolution of the signal source device from the received test requirement information, specifically including two integer values: the total width of the output image in pixels, denoted as... The total height in pixels of the output image is denoted as... Simultaneously, the system receives output from the upstream step, which is an ordered list containing all graphical element description objects. Each description object contains the graphical element type, the original parameter mapping table, and the global bit depth. These data constitute all the inputs for the parameter transformation.

[0051] S41. Sequentially read the first description object in the list of graphic elements and enter a loop processing flow. In each loop iteration, process an independent graphic element description object. The system retrieves its original parameter mapping table from the current description object; most of the values ​​in this mapping table are stored in string format. The system also retrieves the global bit depth associated with the object. As a benchmark for color conversion.

[0052] S42. Create a new empty mapping table to store the converted absolute pixel parameters. Then, the system iterates through each key-value pair in the original parameter mapping table. For each parameter value string, the system needs to determine whether it is a relative or absolute parameter. The determination is based on whether the string contains the character " / ". If the string contains " / ", then it is a relative parameter represented as a fraction. The system splits the string into two parts by the " / " character and parses each part into an integer numerator. and integer denominator Next, the system needs to determine the total width to use based on the name of the current parameter. Or total height As a benchmark for proportional calculation.

[0053] S43. Maintain a predefined rule table that specifies the base dimension for each parameter name. Parameters related to horizontal position or width have the total width as their base. Absolute pixel value The calculation formula is: in, This indicates rounding to the nearest integer to ensure that pixel coordinates are integers. Similarly, parameters related to vertical position or height, such as start_y, center_y, height, region_height, base_h, etc., are based on the total height. The calculation formula is: For the scale_w and scale_h parameters of the external image element, which represent the scaling ratio relative to the image's own base size, their transformation involves additional steps. First, the scaling factor is obtained using the fractional analytical method described above. Then, it is combined with its corresponding base parameter base_w or base_h (which has been converted to a pixel-based base value in this loop). ), and the corresponding dimension at the current output resolution ( or ), calculate the final absolute drawing size : For scale_w, This is the original design value of base_w (e.g., 1920); for scale_h, This is the original design value of base_h (e.g., 1080). If the parameter value string does not contain " / ", the system attempts to parse it directly as an integer and assumes it is already an absolute pixel parameter.

[0054] S44. Color-type parameters in the original parameter mapping table, such as red, green, blue, alpha, start_color, and end_color, although their values ​​are numeric strings, have a valid range that extends from the global bit depth. Definition. To avoid precision loss during internal rendering using a uniform high bit depth (e.g., 16 bits), these values ​​need to be converted. Let the original parameter value be... The converted 16-bit value The calculation formula is: This calculation linearly maps the maximum value at the original bit depth to the maximum value at 16 bits (65535).

[0055] S45. Calculate the absolute pixel parameters. and the converted color parameters As a new integer value, its corresponding parameter name is used as the key and stored in the newly created transformed parameter mapping table. Once all key-value pairs in the original mapping table have been processed, the system replaces the original parameter mapping table in the current graphic element description object with this new mapping table, which contains all absolute pixel parameters and transformed color parameters. After processing the current graphic element, the system iterates to the next graphic element description object in the list.

[0056] S46. The loop ends after all descriptive objects in the graphic element list have been processed. At this point, the geometric parameters in the parameter mapping table carried by each graphic element descriptive object in the list have been converted to values ​​based on the current output resolution. and The absolute pixel parameters and color parameters have been converted to uniform 16-bit depth values. This list, containing a complete set of graphic elements directly usable for drawing operations, is passed as the output of this step to the subsequent graphics drawing module. At this point, the process of converting the parameters of each graphic element to absolute pixel parameters based on the output resolution of the signal source device is complete.

[0057] Absolute pixel parameters are geometric parameters defined by integer pixel values. During graphics rendering, absolute pixel parameters directly define the precise position, size, or radius of a graphic element on the canvas. For example, the top-left corner of a rectangle has a horizontal coordinate of 480 pixels, a vertical coordinate of 270 pixels, a width of 960 pixels, and a height of 540 pixels; these values ​​are absolute pixel parameters. They are calculated from relative parameters defined in the XML file using the output resolution of the signal source device and are the fundamental data driving the underlying graphics rendering engine to perform pixel-level operations.

[0058] S5. Based on each converted absolute pixel parameter, draw the corresponding graphic element on the canvas. When drawing graphic elements on the canvas, if the drawn graphic element overlaps with an existing graphic element on the canvas, perform transparency mixing calculation on the pixel values ​​of the overlapping area according to the transparency parameter of the currently drawn graphic element.

[0059] The canvas is a two-dimensional pixel data buffer allocated in the memory of the signal source device, used for temporary storage and synthesis of the final test signal image. The canvas size strictly corresponds to the output resolution of the signal source device, and its width includes... Each pixel, height includes Each pixel on the canvas consists of four channels: red, green, blue, and alpha. The bit depth of each channel is uniformly set to a high precision (e.g., 16 bits) during initialization. The canvas is typically initialized to full transparency or a specific background color at the start of drawing. Then, the various graphic elements are drawn onto the canvas sequentially according to a defined order, ultimately forming a complete composite image. The canvas is arranged contiguously in memory in row-major order, with the four channels of each pixel stored tightly for fast sequential access and computation.

[0060] The specific implementation process of S5 is as follows: S50. Based on the output resolution of the signal source device, i.e., the width and height Allocate a contiguous storage area in memory. The size of this area is... Bytes (assuming each channel uses 16 bits, or 2 bytes, for storage). The position of each pixel in the canvas. (in , Each of these corresponds to a data structure containing four 16-bit unsigned integers, representing the red components. Green components Blue component and Alpha component During initialization, the alpha component of all pixels... It is usually set to 0, indicating complete transparency, while the color component... It can be set to any value (such as 0), because color values ​​have no effect when the canvas is completely transparent. The origin of the canvas's coordinate system is located at the top left corner, with the x-axis increasing to the right and the y-axis increasing downwards.

[0061] S51. Process each graphic element description object sequentially according to its order in the list. This order determines the stacking hierarchy of the graphic elements; the first graphic element drawn is at the bottom layer, and later graphic elements can be drawn on top of the earlier ones. The system maintains a circular index, starting from the first element of the list, processing one graphic element description object at a time until the end of the list.

[0062] S52. For the currently processed graphic element description object, the system first reads its graphic element type and the converted absolute pixel parameter mapping table. Then, based on the graphic element type, it calls the corresponding underlying drawing function. The drawing function calculates the pixel area covered by the current graphic element based on the geometric parameters. For example, for a rectangle, the drawing function iterates through the rectangular area defined by the parameters, traversing the coordinates of each pixel within that area using two nested loops. For each pixel, the color value is directly set to the color specified by the parameters red, green, and blue, and the temporary alpha value of that pixel is recorded as... (The alpha value from the parameter is converted to a 16-bit value). For a circle, calculate the distance from each pixel to the center of the circle. Determine whether it satisfies The function assigns values ​​to pixels that meet the conditions. For patterned elements such as color bars and grayscale, the drawing function generates the color of each pixel within the area defined by region_x, region_y, region_width, and region_height, according to a specific algorithm. For example, for vertical color bars, the region width is divided into equal parts by colorbar_num, and each divided region is filled with a color from a predefined color sequence. All drawing calculations produce a set of "new pixel" data, including the new color. and new transparency Here It is the 16-bit representation of the alpha value in the current graphic element parameters, and its theoretical maximum value. The value indicates that the current graphic element is completely opaque, with a minimum value of 0 indicating complete transparency. For efficient processing, drawing functions typically generate a temporary list of pixel fragments or directly mark the new values ​​of the affected pixels in an auxiliary buffer the same size as the canvas.

[0063] S53, after determining the set of pixel positions affected by the current graphic element. and its corresponding new pixel value Then, the system needs to match these new pixel values ​​with the existing old pixel values ​​at the corresponding positions on the canvas. Perform synthesis. System traverses the collection. Each pixel position in For each location, perform the following blending calculation: for the color channel (represent (any one of them), assuming the old value of that channel at that location on the canvas is... The new value of the current graphic element at this position for this channel is The transparency parameter of the current graphic element at this position is The resulting value of this channel after mixing. Calculated using the following formula: in, This represents the maximum value of the Alpha channel, which is 65535. This indicates a floor function, used to ensure the result is an integer. The formula means the new color value... According to its transparency Weighting is applied to the old color values. according to Opaque complement Perform a weighted sum, then divide by . The normalized result is obtained, and then rounded down. This calculation is performed independently for the red, green, and blue color channels simultaneously.

[0064] Regarding the alpha channel value of pixels on the canvas In a blending model with pre-multiplied alpha, the alpha value stored on the canvas represents the overall opacity of that pixel. This overall opacity needs to be updated after each blend. The update formula can be derived based on the principle of opacity stacking. Let the old alpha value of the current canvas pixel be... The new Alpha value generated by the current graphic element The overall opacity of the blended pixels. It can be calculated as follows: After each blend, the alpha value of the canvas pixels is... Set directly to the new alpha value used in the current hybrid computation. However, this only applies when the current element completely covers the old content. For generality, the above overlay formula can be used in the implementation, or the overlay mode can be adjusted accordingly. Set as It is a normalized form. Importantly, color mixing must strictly adhere to the given... Formula execution.

[0065] S54, For sets Each pixel in After completing the calculations for the three color channels and the alpha channel, the calculated results will be... And the updated Write back the position of the corresponding pixel in the canvas memory. This is a direct memory write operation that updates the data in the canvas buffer. In this way, the effect of the current graphic element is integrated with the existing content on the canvas. For pixels not covered by the current graphic element, the data at the corresponding position on the canvas remains unchanged.

[0066] S55. After completing the drawing and blending of the current graphic element, the system returns to S51 to continue processing the next graphic element description object in the list. S52 to S54 are repeated until all graphic elements in the list have been sequentially drawn and blended into the canvas. Each loop performs the next blending based on the currently updated canvas state, thus achieving the correct overlay of multiple semi-transparent layers.

[0067] S56. After all graphic elements have been processed, the pixel data stored in the canvas memory is the final image resulting from the superposition and synthesis of all graphic elements in the defined order. This canvas, containing complete RGBA data, will be passed as the output of this step to the next module in the technical solution for subsequent processing such as bit depth conversion. At this point, the process of drawing the corresponding graphic elements on the canvas based on each converted absolute pixel parameter and performing transparency blending calculations is complete.

[0068] In another possible implementation, when drawing graphic elements on the canvas, if the drawn graphic element overlaps with an existing graphic element on the canvas, the pixel values ​​of the overlapping area are calculated for transparency blending based on the transparency parameter of the currently drawn graphic element. The specific implementation process is as follows: 1) Based on the type attribute of the graphic element, dynamically select the corresponding transparency blending function from a predefined set of blending modes. The blending mode set includes at least three modes: normal blending, additive blending, and multiply blending. Each mode corresponds to an independent mathematical calculation model. The specific implementation process is as follows: ① During the software startup of the signal source device or the initialization of the test signal generation module, the system creates a globally accessible blending mode configuration table in memory. This configuration table is a data structure, such as a hash table or enumeration map, where the keys are the type attribute strings of the graphic elements, and the values ​​are function pointers or identifiers pointing to specific transparency blending functions. The type attribute directly uses the type field value in the graphic element description object, such as "rectangle", "circle", "colorbar", etc. The blending mode configuration table is read from the configuration file or defined internally, establishing at least three mappings: mapping some graphic element types to the "normal blending" mode, another part to the "additive blending" mode, and a third part to the "multiply blending" mode. For example, the system can be configured to use normal blending for all basic shape elements (such as rectangles and circles), while using additive blending for all custom types related to highlight or halo effects, and using multiply blending for graphic elements used to simulate filter effects.

[0069] ② When processing specific graphic elements, read their type attribute and query the mapping. When the system traverses the list of graphic elements and prepares to draw and blend the current graphic element, it retrieves the value of its type attribute from the graphic element's description object, denoted as... .use Used as the query key, a lookup is performed in the established hybrid mode configuration table. The query operation returns a hybrid mode identifier. This identifier clearly indicates the hybrid calculation method that the current graphic element should use, and its value can be an enumerated constant such as "NORMAL", "ADDITIVE" or "MULTIPLY".

[0070] ③ Maintain a hybrid function dispatcher, where each hybrid mode is identified. Each function predefines a specific, optimized mathematical computation function. These functions are the concrete code implementations of the transparency hybrid computation model. For example, the function associated with the "NORMAL" flag implements the regular hybrid model, and its internal logic follows the formula... The functions associated with the "ADDITIVE" flag implement an additive mixed model, whose internal logic follows the formula. ,in This represents the maximum value of the color channel (e.g., 65535 in 16-bit). Functions associated with the "MULTIPLY" flag implement the multiply blending model, and their internal logic follows the formula... Or more directly The distributor is based on The value of directs the pixel data processing flow of the current graphic element to the corresponding mathematical calculation function.

[0071] ④ After completing the function association, the system enters the actual pixel traversal and blending stage. For each pixel position covered by the current graphic element, the system calls the selected transparency blending function. This function receives the necessary parameters: the source pixel color value obtained from the current graphic element. and transparency and the target pixel color value read from the canvas. The function internally performs calculations according to its bound mathematical model and returns the synthesized color value. The system will then... Write back to the canvas. This process ensures that different types of graphic elements can be blended according to predefined, differentiated optical overlay effects, thereby enriching the customizability and expressiveness of the test signal.

[0072] 2) Obtain the pixel data of the currently drawn graphic element in the overlapping area, including the source pixel values ​​of each color channel. With transparency parameter Simultaneously, it reads the existing target pixel value from the corresponding position on the canvas. , specifically: ① Determine the overlapping area between the current graphic element and existing content on the canvas. The system calculates the precise pixel area it covers based on the transformed absolute pixel parameters of the current graphic element. This is typically a rectangular or polygonal region. Simultaneously, the system maintains a valid area within the canvas that already contains non-transparent content. By calculating the geometric intersection This process yields the pixel regions that actually require the blending calculation. If the intersection is empty, there's no need to obtain overlapping pixel data; the non-overlapping regions can be drawn directly. Calculating the intersection involves comparing coordinate ranges. For example, for two rectangular regions, the coordinates and dimensions of the overlapping rectangle are obtained by comparing their top-left corner coordinates, width, and height, generating a list of pixel coordinates to be processed. .

[0073] ② Traverse the overlapping region pixels and calculate the source pixel value System Sequential Processing List Each pixel coordinate For each coordinate, the system calculates or retrieves the color value corresponding to that coordinate point based on the type and parameters of the current graphic element. For basic shapes such as rectangles and circles, the color value defined in the parameters is used directly. As this pixel For pattern elements such as color bars and grayscale, the system needs to calculate the color value of a pixel based on its relative position within the pattern area using interpolation or lookup table algorithms. For example, for grayscale, a linear calculation is performed based on start_color, end_color, and the pixel's row and column indices in the grayscale matrix. All these calculated color values ​​are normalized to the bit depth range used by the system's internal processing, such as 16 bits. It is actually a vector containing three components: red, green, and blue, with each component being a 16-bit integer. Simultaneously, the system extracts the transparency parameter from the parameters of the graphic elements. This value is also an integer that has been converted to the system's internal bit depth (e.g., 16 bits), ranging from 0 to the maximum value. between.

[0074] ③ Read the target pixel value from the canvas For the same pixel coordinate The system needs to read the existing color data at that location from the current canvas's memory buffer. The canvas buffer is organized in row-major order, and each pixel stores a 16-bit value for the red, green, blue, and alpha channels. The system then uses the coordinates... Calculate memory offset The data is processed by first taking bytes (assuming 2 bytes per channel), and then directly reading the three 16-bit color channel values ​​from that offset address, denoted as follows: , , These three values ​​together constitute the target pixel value. The alpha channel values ​​stored in the canvas are not typically used for blending calculations in this step, but the system can read them for use by a specific blending model.

[0075] ④ For each pixel within the overlapping region, a complete set of data was obtained: source pixel color value Transparency parameters Target pixel color value The system encapsulates this data in a temporary data structure, such as a structure containing six integer fields. This data structure is either immediately fed into the selected transparency blending function for calculation, or added to a small batch queue for efficiency. This process is repeated until the list is reached. All pixel coordinates have been processed, thus preparing all the input data needed for transparency blending calculations for all pixels in the entire overlapping area.

[0076] 3) , and The input is fed into the mathematical calculation model corresponding to the selected blending mode for pixel-by-pixel calculation. For the regular blending mode, a formula is used. Perform calculations; for additive mixed modes, use the formula. Perform calculations, where This represents the maximum value of the pixel channel, specifically: ① The transparency blending function accepts three input parameters: source pixel value (A vector containing red, green, and blue components), transparency parameter (A scalar integer), target pixel value (A vector that also contains red, green, and blue components). The function first checks the current blending mode identifier. If marked "NORMAL", the calculation branch for the normal blending mode is executed; if marked "ADDITIVE", the calculation branch for the additive blending mode is executed; if marked "MULTIPLY", the calculation branch for the multiply blending mode is executed. The calculation process is performed independently for each color channel.

[0077] ② For each of the three color channels—red, green, and blue—let's denote it as channel A. The function performs the following operations: First, it takes an integer input value. , , and constants Convert to floating-point numbers for high-precision calculations, where It is the maximum value of the color channel in the current internal representation, such as in a 16-bit system. Next, the normalized transparency is calculated. Then, strictly follow the formula. Perform floating-point operations. Finally, output the floating-point result. Round to the nearest integer, and ensure its value is within [0, 100]. Within the range of ], this integer is the final output result of this channel.

[0078] ③ For each of the three color channels—red, green, and blue—let's denote it as channel A. The function performs the following operations: First, it performs integer multiplication. .because and All are in the range [0, Integers, product The range can reach [0, Therefore, a sufficiently large integer type (such as 32-bit or 64-bit) is needed to store the intermediate results to prevent overflow. Next, the addition is calculated. Here will Multiply It is to make the formula The terms in the formula are consistent with those in the conventional mixed formula on a numerical scale; in fact, the standard implementation of this formula is more commonly expressed as follows: Therefore, a more precise implementation is to first calculate the normalized product. (Use integer division or floating-point numbers), then calculate Finally, the minimum value function is applied. .result This is the final integer output value of the channel.

[0079] ④ For each of the three color channels—red, green, and blue—let's denote it as channel . The function performs the following operations: First, it calculates... and product Next, calculate the ratio of this product to the square of the maximum value, i.e. This can be achieved using floating-point or fixed-point integer arithmetic. Then, this normalized product result is used as an influencing factor, combined with transparency. One implementation model is: Another, more direct model (as before) is: Regardless of the specific formula variant used, after the calculation is complete, the result needs to be rounded to an integer and clamped to [0, 1]. Within the specified range. For each processed pixel, the function outputs a result vector containing the new red, green, and blue channel values. This result value will be immediately written back to the canvas, or submitted in batches along with the results of other pixels to complete the compositing of that pixel in the specified blending mode.

[0080] 4) Calculate the composite result value for each pixel. Write the corresponding location in the canvas memory to complete the drawing of the graphic element, and retain the updated canvas state for subsequent graphic elements to be overlaid. Specifically: ① For each pixel that has completed the blending calculation, the system receives its output result—a result vector. The vector contains three 16-bit integer components, each representing a value from the red channel. Green channel result value and blue channel result values These components have been calculated and clamped within the valid numerical range [0, ...]. [Inside, among which] This is the maximum value of the color channel represented internally by the system. The system also holds the coordinates of this pixel on the canvas. The information, these coordinates, were already specified in the previous steps of determining the overlapping area.

[0081] ② The canvas memory is organized as a contiguous, row-major array of bytes. The system uses the following formula to calculate the starting byte offset of the target pixel data in memory. : in, These are the row coordinates of the pixels. These are the column coordinates of the pixels. This refers to the total number of bytes occupied by each row of data in the canvas, typically for memory alignment. It can be greater than . It represents the number of bytes each pixel occupies on the canvas, in a 16-bit per channel, four-channel (RGBA) configuration. Bytes. Calculation result. It is an integer in bytes that points to the starting storage location of the red component data of that pixel in the canvas buffer.

[0082] ③ Based on the calculated memory offset This involves performing low-level memory writes. Since color components are 16-bit integers, and memory is measured in bytes, write operations must consider the system's byte order (big-endian or little-endian). For example, in a little-endian system, for a 16-bit value... Its lower 8 bits are stored at address The high 8 bits are stored at address The system will sequentially... , , These three 16-bit values ​​are written to the address according to the predefined channel order of the canvas (e.g., red, green, blue, alpha). The starting contiguous memory location. The alpha channel value of this pixel in the canvas. This step typically remains unchanged unless the hybrid model explicitly requires it to be updated. Write operations are ensured to be atomic or protected to avoid data races in a multi-threaded environment.

[0083] ④ While writing pixel data to memory, the system needs to update the data structures used to optimize and record the canvas state. A key update is merging the drawing areas of the current graphic elements. This information is stored in the canvas's "Updated Areas" or "Dirty Rectangles" record. This record tracks which parts of the canvas have changed since the last full read, improving efficiency in subsequent localized processing or display. Additionally, if the system maintains a fast access cache or thumbnails of canvas pixels, this cached data needs to be invalidated or updated accordingly.

[0084] ⑤ When the overlapping area list Once all pixels have completed the aforementioned write operations, the drawing process for the current graphic element is considered complete. At this point, all positions in the canvas memory affected by this graphic element have been updated to the latest composite color value. The system marks the canvas (i.e., the pointer to the canvas buffer and its metadata) as updated and passes this updated canvas object as the currently valid drawing context to the next graphic element in the processing flow. In this way, the drawing and blending calculation of the next graphic element will be based on this latest canvas state containing the effects of all previous graphic elements, thus achieving the correct sequential overlay of graphic elements.

[0085] S6. Based on the output bit depth defined in the XML file, convert the canvas containing all graphic elements into target image data. The specific implementation process is as follows: S60. It is necessary to re-access the loaded XML document object model, or retrieve the global bit-depth parameter read during the parsing phase from the stored context. Specifically, the system locates the root node of the XML document. And read the value of its bit_depth attribute. This attribute value is parsed into an integer, denoted as . .this This refers to the output bit depth, which is the target precision reference for this conversion operation. For example, the value read can be 8, 10, or 12.

[0086] S61. Based on the output resolution of the signal source device, i.e., the width and height and output bit depth A new memory buffer is calculated and allocated to store the target image data. The layout of the target image data buffer needs to be determined according to the interface requirements of the subsequent output module; for example, it could be a contiguous array of RGB pixels. The conversion process is implemented through a nested loop, with the outer loop iterating through each row of the canvas (y-coordinate from 0 to...). The inner loop iterates through each column (x-coordinate from 0 to...). For each pixel position on the canvas. The system reads its current 16-bit channel data from the canvas memory: the red component. Green components Blue component and Alpha component .

[0087] S62. Since the color values ​​on the canvas are stored with 16-bit high precision, while the target output bit depth can be lower than 16 bits, a down-conversion is required. For each color channel value (taking the red channel as an example)... For example, the corresponding target depth value Calculated using the following formula: In this formula, This indicates the floor function. It is the maximum value (65535) with 16-bit precision. This is the maximum value within the target output bit depth. This formula will calculate the value within a 16-bit range. Linear scaling to the target bit depth range. The same calculation is applied independently to the green channel. and the blue channel , respectively obtained and Alpha channel data Scaling the output is typically not performed at this step because the final image data format usually only contains RGB information, with alpha information only used in the compositing stage.

[0088] S63. The division and multiplication operations described above may produce floating-point numbers or non-integer results. Rounding down ensures the result is an integer. The system needs to ensure that the calculated result... , , The value is within the valid range of the target bit depth. Within this range, since it's linear scaling, theoretically there shouldn't be any overflow. However, as a robustness check, a clamping function can be implemented to limit the result to this range. For example, if the calculated result is negative, set it to 0; if the calculated result exceeds the maximum value, set it to the maximum value.

[0089] S64. The storage format of the target image data in memory or a file needs to be explicitly defined. A common format is to store each pixel... , , Values ​​are stored contiguously. Since the target bit depth may not be a multiple of 8 (e.g., 10 bits), byte alignment may need to be considered during storage. For example, for a 10-bit output bit depth, one storage method is to pack 30 data bits (3 channels × 10 bits) for every two pixels into 4 bytes (32 bits). The system needs to assemble the calculated multi-channel integer values ​​for each pixel into the correct positions in the target image data buffer according to a predetermined byte order and bit stuffing rules. This process involves bitmasking and shifting operations.

[0090] S65. After the inner loop completes the transformation and packing of one pixel, it continues processing the next pixel in the current row. Once all pixels in a row have been processed, the outer loop moves on to the next row. This process repeats until all pixels in the canvas are processed. Each pixel is processed and packed into the target image data buffer.

[0091] S66. After all pixels have been traversed and packaged, the target image data buffer stores the final converted result. This data block is a contiguous byte array, the contents of which are entirely determined by the output bit depth. and output resolution The definition represents the test signal image in the RGB color space. This target image data block, as the output of this step, is passed to the signal output module, which is responsible for the final digital-to-analog conversion or digital interface transmission. At this point, the process of converting the canvas into target image data according to the output bit depth defined in the XML file is complete.

[0092] The output bit depth is an integer parameter defined in the `image` section of the root node of the XML file. It specifies the number of bits used for each color channel (red, green, blue) in the target image data. For example, an output bit depth of 10 means that the value of each color channel is represented by a 10-bit unsigned integer, with a value ranging from 0 to... This parameter, set by the test signal designer in an XML configuration file, determines the accuracy and dynamic range of the final generated image data and must match the hardware input specifications of the signal source device's back-end output module.

[0093] S7. Based on the target image data, generate a test signal. The specific implementation process is as follows: S70. Based on the technical specifications of the signal source device's output module, determine the encoding format of the target image data. Key parameters of the format include color space (e.g., RGB), channel order (e.g., red-green-blue), total data length per pixel, and byte order. For example, the output module may require a packedRGB format, where the red, green, and blue components of each pixel are stored consecutively, and the number of bits occupied by each component is determined by the output bit depth. Decision. The system determines the width based on the output resolution. and height Based on the number of bytes per pixel, the total number of bytes required for the target image data buffer is calculated. A typical calculation method is to first calculate the total number of bits per pixel. Then calculate the number of bytes for each line of data after alignment to the byte boundary. ,at last . This indicates rounding up. The system allocates a memory space of size [size missing]. A contiguous buffer is created and all its bits are initialized to zero.

[0094] S71. Traverse each pixel on the canvas in row-major order. For the pixel at position n... line, number List( , For each pixel, the system reads the 16-bit values ​​of its three color channels from the canvas memory: red... ,green and blue The alpha channel data in the canvas is not read in this step because the target image data typically does not contain transparency information. This traversal process is accomplished using a nested loop, with the outer loop controlling the row coordinates. Incrementing from 0 to Inner loop controls column coordinates Incrementing from 0 to .

[0095] S72. For each 16-bit color channel value read, the system uses the output bit depth obtained from the XML file. Perform the conversion. Taking the red channel as an example, the conversion formula is: In the formula, It is the 16-bit value of the red channel in the canvas, ranging from 0 to 65535. It is the maximum value under the target bit depth, for example when At that time, the value was 1023. It is the maximum value of 65535 at 16-bit depth. This represents the floor function. This formula achieves a linear mapping from the 16-bit dynamic range to the target bit-depth dynamic range. The same calculation is applied independently to the green and blue channels, yielding the following results: and These result values ​​are integers and satisfy the following conditions: .

[0096] S73. Pack the target color value into the data buffer. This involves bit-level operations, requiring the three integer values ​​of the current pixel to be packed into the data buffer. , , Write the data to the target image data buffer according to the predetermined format. Because... It doesn't necessarily have to be a multiple of 8; multiple channels of data for a single pixel can cross byte boundaries. The system maintains a "bit pointer" or byte / bit offset pointing to the current write position in the buffer. For each channel value, the system treats it as a... A binary number of bits is gradually filled into the corresponding positions in the buffer through shift and OR operations. For example, if the format is RGB and each channel is 10 bits, then one pixel is 30 bits. When writing, it may be necessary to first... Write the high 8 bits into one byte, then... The lower 2 bits and The high 6 bits are combined to form the next byte, and so on. This process continues until... , , All bits are stored sequentially in the buffer. The system then updates the bit pointer to point to the starting position of the next pixel.

[0097] S74. Many hardware interfaces require the starting address of each row of image data to be aligned in memory by a specific number of bytes (e.g., 4 bytes, 8 bytes). Therefore, after packing all the pixels of a row, the system checks whether the current "bit pointer" position has reached the theoretical bit length of that row. If this isn't achieved, it means the data for the last pixel hasn't completely filled a full end byte. The system needs to calculate the number of padding bits and set those bits to 0 until the "bit pointer" moves to the predetermined aligned start address of the next row. This ensures that each row of data is of consistent length and aligned in memory, facilitating DMA transfers or direct hardware reads.

[0098] S75. After packing all pixels of a row and padding at the end of the row, the outer loop increments the row number. The system moves to the area allocated for the next row in the target image data buffer, repeating steps S71 to S74. This process continues until all... The row pixel data is converted and packed into a buffer.

[0099] S76. After all rows have been processed, the target image data buffer in memory contains complete, formatted image frame data. The system sets the starting address and size of this buffer. The target image data is encapsulated in a data structure, such as a descriptor containing data pointers and metadata (e.g., width, height, bit depth, row span). This data structure constitutes the final target image data. The system outputs this target image data to the signal output module of the signal source device. The signal output module, based on the data's format description, sends it out through a specific hardware interface. At this point, the entire implementation process of the target image data is complete.

[0100] Optionally, the above technical solution also includes: S8. Send the test signal to the device under test (DUT) to perform the test and obtain the test results. The specific implementation process is as follows: S80: The signal output module of the signal source device initializes the corresponding physical interface hardware according to the output format (such as HDMI, DisplayPort, SDI, etc.) and timing parameters (such as resolution, frame rate) specified in the test requirements information. Simultaneously, the signal output module receives the generated target image data from upstream. The target image data is loaded into the frame buffer or direct memory access buffer of the signal output module, ready for continuous signal generation.

[0101] S81 continuously reads target image data from its buffer at a stable frame rate and converts it into a serial data stream conforming to the target interface's electrical protocol and timing specifications. For digital interfaces, this involves encoding, scrambling, and parallel-to-serial conversion; for analog interfaces, it involves digital-to-analog conversion and amplification. The generated physical signal is stably transmitted to the corresponding input port of the device under test via cable or wireless channel. This process typically lasts for a preset time to ensure that the device under test has sufficient time to stabilize its display and facilitate measurement.

[0102] S82. To obtain test results, external test equipment is needed to measure the output of the device under test. External test equipment can be a color analyzer, photometer, camera, or oscilloscope, etc. The system synchronously starts these external test devices via software commands or hardware trigger signals. For example, when the signal source device begins sending a specific test frame (such as full white field), a command to start measurement is sent to the connected color analyzer via a universal interface bus or Ethernet, ensuring precise synchronization between the measurement timing and the transmission of the test signal.

[0103] S83. External testing equipment, depending on its type, measures the response of the device under test (DUT) under test excitation by a test signal. For example, a color analyzer is placed in front of the screen of the display device under test to measure the chromaticity coordinates of a specific area on the screen (such as a color block in a grayscale pattern). and brightness (Unit: nits). A network analyzer can measure the frequency response of the video processing circuitry in a device under test (DUT). A high-resolution camera can capture a digital photograph of the entire screen of the DUT, obtaining a digital image of the displayed image. Each pixel contains red, green, and blue components. The acquired raw measurement data is either temporarily stored on external testing equipment or uploaded to a control computer.

[0104] S84. The test analysis software in the control computer receives the raw measurement data uploaded from the external test equipment. The software also possesses the "ideal expected data" of the test signals sent in this test. For image testing, the ideal expected data is the generated target image data. The corresponding ideal physical behavior. The analysis process involves complex calculations. Taking geometric distortion testing as an example, the software uses image recognition algorithms to analyze photos taken by a camera. In the process, the corner positions of the checkerboard test pattern are identified and recorded as their actual coordinates. ,in and This is the corner index. The corresponding ideal coordinates. It can be calculated directly from the target image data. Then, the geometric distortion error is calculated. For example, using the root mean square error formula: in, This refers to the total number of corner points. For color testing, the software will use the chromaticity measured by the color analyzer. Standard chromaticity value corresponding to this region in the target image data Compare and calculate color difference For example, approximate calculations can be performed using the CIE1976LAB color difference formula.

[0105] S85. Based on the calculated error indicators (like , (such as brightness unevenness) and the preset qualified threshold. The comparison is performed. For each test metric, a Boolean result is generated. The rules are as follows: The software integrates all the raw measurement values ​​of the test indicators, the calculated error values, the judgment results, and the test conditions (such as test signal identifiers, output resolution, and measurement timestamps) into a structured test report document or data object. This report document is the final, formatted test result.

[0106] S86. The generated test results are displayed to the operator through a human-machine interface, typically including a summary of pass / fail conclusions, detailed data tables, and a map marking potential problem areas. Simultaneously, the test results are automatically stored in the database of the signal source device or network server for historical tracking, statistical analysis, and test certificate generation. This concludes the complete process of "sending test signals to the device under test for testing and obtaining the test results from the device under test."

[0107] The device under test (DUT) is a type of electronic device that receives and processes test signals generated by a signal source device to evaluate its performance or functionality. Common DUTs include various displays (such as LCDs, OLEDs, and televisions), projectors, video processing equipment (such as video matrix switchers and image scalers), image acquisition equipment (such as industrial cameras and camcorders), and terminal products containing display modules (such as smartphones, tablets, in-vehicle infotainment system screens, and medical monitor displays). These devices receive test signals such as color bars, grayscale, and geometric patterns to verify various performance indicators, including color reproduction accuracy, brightness uniformity, contrast ratio, geometric distortion, and signal compatibility.

[0108] The principle and flow of the technical solution of this invention are as follows: The definition information of the test signal is maintained in an independent XML file. Various types of graphic elements, such as rectangles, circles, windows, color bars, grayscale, single-pixel signals, checkerboard patterns, and external images, can be written in the XML file. Each XML file is associated with a unique test signal identifier through its name. When the signal source device needs to generate a test signal, the system first obtains the test requirement information containing the test signal identifier and output resolution. Subsequently, the system locates and opens the corresponding XML file based on the test signal identifier and reads all the graphic elements and parameters defined therein. The parameters of the graphic elements can be described using a combination of absolute and relative parameters; relative parameters are expressed in fractional form, and their values ​​are proportional to the image width or image height corresponding to the output resolution of the signal source device. The system converts all parameters of the graphic elements into absolute pixel parameters according to the current actual output resolution. Then, the system draws each graphic element on the canvas in the order they are defined in the XML file. During the drawing process, if the currently drawn graphic element overlaps with an existing graphic element on the canvas, the system performs a transparency mixing calculation on the pixel values ​​of the overlapping area based on the transparency parameter of the current graphic element. After all graphic elements are drawn, the system converts the canvas data into the final target image data according to the output bit depth defined in the XML file, and generates test signals based on this, sending them to the test signal output module. This method allows each test signal to be represented independently by a separate XML file, thus avoiding writing test signal information into the software source code. When adding or modifying test signals, only the corresponding XML file needs to be manipulated. Furthermore, because relative position and size parameters are used in the XML file, only one XML file needs to be maintained for the same type of test signal. The signal source device can dynamically generate the same type of test signal at different output resolutions using this single XML file according to real-time test requirements. This significantly reduces the number of test signal files that need to be pre-made and stored, substantially reducing the overall workload of test signal creation, modification, and maintenance, and effectively achieving compatibility with test signals at different resolutions.

[0109] In the above embodiments, although the steps are numbered S1, S2, etc., they are only specific embodiments given by the present invention. Those skilled in the art can adjust the execution order of S1, S2, etc. according to the actual situation. The scheme after adjusting the order is also within the protection scope of the present invention. It can be understood that in some embodiments, some or all of the above embodiments may be included.

[0110] like Figure 2As shown, an embodiment of the present invention provides a test signal generation system 200 for a signal source device, which includes a test requirement information acquisition module 201, a file determination module 202, a graphic element and parameter acquisition module 203, a first conversion module 204, a drawing module 205, a second conversion module 206, and a test signal generation module 207. The test requirement information acquisition module 201 is used to: acquire test requirement information including test signal identifiers and the output resolution of the signal source device; The file determination module 202 is used to: determine the corresponding XML file based on the test signal identifier, wherein the XML file defines at least one graphic element used to constitute the test signal and the parameters of each graphic element; The graphic element and parameter acquisition module 203 is used to: acquire the graphic elements and parameters defined in each shape segment of the XML file; The first conversion module 204 is used to convert the parameters of each graphic element into absolute pixel parameters according to the output resolution of the signal source device. The drawing module 205 is used to: draw the corresponding graphic elements on the canvas based on each converted absolute pixel parameter; The second conversion module 206 is used to convert the canvas with all graphic elements drawn on it into target image data according to the output bit depth defined in the XML file. The test signal generation module 207 is used to generate a test signal based on the target image data.

[0111] Optionally, in the above technical solution, the drawing module is further used to: when drawing graphic elements on the canvas, if the drawn graphic elements overlap with existing graphic elements on the canvas, perform transparency mixing calculation on the pixel values ​​of the overlapping area according to the transparency parameter of the currently drawn graphic elements.

[0112] Optionally, in the above technical solution, the parameters of the graphic element include relative parameters representing the position and / or size of the graphic element. The relative parameters are fractional values ​​representing the proportion of the image width or image height relative to the output resolution of the signal source device.

[0113] Optionally, in the above technical solution, the graphic elements defined in the XML file include at least one of rectangle, circle, window, color bar, grayscale, single pixel signal, checkerboard, and external image.

[0114] It should be noted that the beneficial effects of the signal source device test signal generation system 200 provided in the above embodiments are the same as those of the signal source device test signal generation method described above, and will not be repeated here. Furthermore, the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the system can be divided into different functional modules according to the actual situation to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, and will not be repeated here.

[0115] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-described signal source device test signal generation methods.

[0116] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described signal source device test signal generation methods.

[0117] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0118] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for generating test signals for a signal source device, characterized in that, include: Obtain test requirement information, including test signal identifiers and the output resolution of the signal source device; The corresponding XML file is determined based on the test signal identifier. The XML file defines at least one graphic element used to constitute the test signal and the parameters of each graphic element. Obtain the graphic elements and parameters defined in each shape segment of the XML file; Based on the output resolution of the signal source device, the parameters of each graphic element are converted into absolute pixel parameters; Based on each transformed absolute pixel parameter, draw the corresponding graphic element on the canvas; Based on the output bit depth defined in the XML file, the canvas containing all graphic elements is converted into target image data; A test signal is generated based on the target image data.

2. The method for generating test signals for a signal source device according to claim 1, characterized in that, Also includes: When drawing graphic elements on the canvas, if the drawn graphic element overlaps with an existing graphic element on the canvas, the pixel values ​​of the overlapping area are calculated for transparency blending based on the transparency parameter of the currently drawn graphic element.

3. A method for generating test signals for a signal source device according to claim 1 or 2, characterized in that, The parameters of the graphic element include relative parameters representing the position and / or size of the graphic element, wherein the relative parameters are expressed as fractions and are proportional values ​​of the image width or image height relative to the output resolution of the signal source device.

4. A method for generating test signals for a signal source device according to claim 1 or 2, characterized in that, The graphic elements defined in the XML file include at least one of rectangles, circles, windows, color bars, grayscale, single-pixel signals, checkerboard patterns, and external images.

5. A signal generation system for a signal source device, characterized in that, It includes a test requirement information acquisition module, a file determination module, a graphic element and parameter acquisition module, a first conversion module, a drawing module, a second conversion module, and a test signal generation module; The test requirement information acquisition module is used to: acquire test requirement information including test signal identifier and output resolution of signal source device; The file determination module is used to: determine the corresponding XML file according to the test signal identifier, wherein the XML file defines at least one graphic element for constituting the test signal and the parameters of each graphic element; The graphic element and parameter acquisition module is used to: acquire the graphic elements and parameters defined in each shape segment of the XML file; The first conversion module is used to: convert the parameters of each graphic element into absolute pixel parameters according to the output resolution of the signal source device; The drawing module is used to: draw the corresponding graphic elements on the canvas based on each converted absolute pixel parameter; The second conversion module is used to convert the canvas with all graphic elements drawn on it into target image data according to the output bit depth defined in the XML file. The test signal generation module is used to generate test signals based on target image data.

6. The signal generation system for a signal source device according to claim 5, characterized in that, The drawing module is also used to: when drawing graphic elements on the canvas, if the drawn graphic element overlaps with an existing graphic element on the canvas, perform transparency mixing calculation on the pixel values ​​of the overlapping area according to the transparency parameter of the currently drawn graphic element.

7. A signal generation system for a signal source device according to claim 5 or 6, characterized in that, The parameters of the graphic element include relative parameters representing the position and / or size of the graphic element, wherein the relative parameters are expressed as fractions and are proportional values ​​of the image width or image height relative to the output resolution of the signal source device.

8. A signal generation system for a signal source device according to claim 5 or 6, characterized in that, The graphic elements defined in the XML file include at least one of rectangles, circles, windows, color bars, grayscale, single-pixel signals, checkerboard patterns, and external images.

9. An electronic device, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the test signal generation method for a signal source device as described in any one of claims 1 to 4.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements a method for generating test signals for a signal source device as described in any one of claims 1 to 4.

Images