Program design method of telescope image acquisition and camera control system

Abstract

The invention relates to the technical field of image processing, in particular to a program design method of a telescope image acquisition and camera control system, which comprises the following steps of: determining an image acquisition derivative header file and an image acquisition derivative source file participating in compiling by reading an automatic construction acquisition card configuration file according to an automatic construction engineering configuration file; the image acquisition module comprises an image acquisition interface class and an image acquisition derivation class, the corresponding image acquisition derivation class is selected for instantiation according to acquisition card information, and in the software initialization process, the camera communication module sends the image acquisition interface class and the image acquisition derivation class according to the configuration of a camera brand model reading a camera configuration file during operation; and selecting a corresponding camera communication derivation class for instantiation. According to the method, the program development workload is reduced, the code maintenance workload is reduced, the program debugging difficulty is reduced, the expandability of the camera and the acquisition card in the code is improved, and the software adaptation capability is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of image processing, and in particular provides a program design method for telescope image acquisition and camera control system. Background Art

[0002] Considering the telescope's intended use, multiple optical systems are often designed to meet the telescope's observation requirements for targets in different wavelength bands and fields of view. Each optical system may utilize a different camera brand and model. Due to a combination of cost and performance considerations, different image processing terminals may utilize multiple brands and models of acquisition cards. These cards require different drivers and programming interfaces. Even when the card brand, driver, and programming interface are the same, different cameras may use different control protocols. Even telescopes with the same design and functionality may need to replace cameras due to discontinuation of a particular brand or model, the need for enhanced detection capabilities, or different versions of the driver and programming interface may be required due to operating system or acquisition card upgrades. Considering the application environment, telescopes are often deployed in harsh environments such as plateaus and mountainous areas. Remote debugging is a common method for troubleshooting, but network latency and lag often significantly impact remote debugging efficiency. The optimal solution is for developers to debug locally at their workstations and remotely connect to the telescope's image processing terminal to compile and run the software. However, the acquisition cards, acquisition card drivers, and acquisition card programming interfaces used by each telescope image processing terminal and the local computer may be different.

[0003] In the three common situations described above, a telescope image processing program cannot be compiled and run on different image processing terminals. A common solution is to develop and maintain an image processing program for each optical system and debug the program remotely. Developing and maintaining an image processing program for each optical system makes it difficult to maintain multiple sets of image processing programs. For example, modifications made in one program must be synchronized with the other programs, resulting in a large workload, high maintenance costs, and prone to errors. Furthermore, direct remote debugging of the program is inefficient when there are network delays and freezes, and network interruptions can severely impact debugging progress. All of the above solutions suffer from the image processing program's poor scalability and adaptability to cameras and acquisition cards. Summary of the Invention

[0004] To address the above-mentioned issues, the present invention provides a programming method for a telescope image acquisition and camera control system. The automated construction of a project configuration file determines the image acquisition derived class header file and source file involved in compilation by reading an automated acquisition card configuration file. The image acquisition module includes an image acquisition interface class and an image acquisition derived class. The corresponding image acquisition derived class is instantiated based on acquisition card information. During software initialization, the camera communication module selects and instantiates the corresponding camera communication derived class based on the camera brand and model configuration read from the runtime camera configuration file. This method reduces program development workload, code maintenance workload, and program debugging difficulty.

[0005] The program design method for a telescope image acquisition and camera control system provided by the present invention includes: a camera communication module, an image acquisition module, an automated construction engineering configuration file, an automated construction acquisition card configuration file, and a runtime camera configuration file; When compiling: The automatic construction project configuration file finds the automatic construction acquisition card configuration file in the specified directory, loads the acquisition card information, the acquisition card programming interface header file directory, and the acquisition card programming interface link library, and the automatic construction project configuration file compiles the image acquisition derived class code corresponding to the acquisition card according to the acquisition card information. The image acquisition module reads the acquisition card information and instantiates the image acquisition derived class i, where i represents the serial number of multiple image acquisition derived classes; Runtime: The camera communication module finds the runtime camera configuration file in the specified directory and reads the camera brand and model information. The camera communication module instantiates the camera communication derived class j according to the camera brand and model information, where j represents the serial number of multiple camera communication derived classes.

[0006] Preferably, the automated construction engineering configuration file is integrated into the software code and deployed to the corresponding computer along with the software code.

[0007] Preferably, the automatically constructed acquisition card configuration file includes acquisition card information, an acquisition card programming interface header file directory, and an acquisition card programming interface link library.

[0008] Preferably, the automatic construction project configuration file determines the image acquisition derived class header file and the image acquisition derived class source file involved in the compilation by reading the automatic construction acquisition card configuration file.

[0009] Preferably, the interface design of the image acquisition module is completed during the program compilation process.

[0010] Preferably, a polymorphic programming method is adopted and an object-oriented programming language is applied to design the image acquisition module.

[0011] Preferably, the interface design of the camera communication module is completed during the initialization process after the software is running.

[0012] Preferably, a polymorphic programming method is adopted and an object-oriented programming language is applied to design the camera communication module.

[0013] Compared with the prior art, the present invention can achieve the following beneficial effects: The image acquisition and camera control system programming method provided by the embodiment of the present invention can adapt the same set of programs to multiple acquisition cards, and can also adapt to multiple versions of programming interfaces of the same acquisition card or multiple camera brands and models. The acquisition card configuration file and the runtime camera configuration file are automatically constructed and pre-configured in the image processing terminal. When compiling the image acquisition and camera control system, the compiler can selectively compile according to the actual acquisition card and the acquisition card programming interface. During the software operation, the image acquisition and camera control system sends control instructions according to the actual camera brand and model, thereby reducing the software development workload, reducing the code maintenance workload, reducing the difficulty of software debugging, improving the scalability of cameras and acquisition cards, and improving the software adaptability. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 2 is a schematic diagram of the composition of a multi-optical system and an image processing terminal provided according to an embodiment of the present invention; Figure 2 2. It is a schematic diagram of the software code compilation principle provided by an embodiment of the present invention; Figure 3 It is a schematic diagram of the program running initialization process provided according to an embodiment of the present invention. DETAILED DESCRIPTION

[0015] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and do not constitute a limitation to the present invention. Similar elements in different embodiments use associated similar element numbers. In the following embodiments, many detailed descriptions are intended to enable the present invention to be better understood. However, those skilled in the art can easily recognize that some of the features can be omitted in different situations, or can be replaced by other elements, materials, or methods. In some cases, some operations related to the present invention are not shown or described in the specification. This is to avoid the core part of the present invention being overwhelmed by too much description. For those skilled in the art, it is not necessary to describe these related operations in detail. They can fully understand the related operations based on the description in the specification and the general technical knowledge in the art.

[0016] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments of the present invention can be combined with each other to form various implementation methods. At the same time, the steps or actions in the method description can also be interchanged or adjusted in a manner that is obvious to those skilled in the art. Therefore, the various orders in the description and the drawings are only for the purpose of clearly describing a certain embodiment and are not intended to be a required order, unless otherwise specified that a certain order must be followed.

[0017] In the description of the present invention, it should be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", "clockwise", "counterclockwise" and the like indicate positions or positional relationships based on the positions or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention. In addition, the terms "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, features defined as "first", "second", etc. may explicitly or implicitly include one or more of the features. In the description of the present invention, unless otherwise specified, "multiple" means two or more.

[0018] In the description of the present invention, it should be noted that, unless otherwise expressly specified or limited, the terms "installed," "connected," and "connected" should be understood in a broad sense. For example, they can refer to fixed connections, detachable connections, or integral connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; and they can refer to internal connections between two components. Those skilled in the art can understand the specific meanings of the above terms in the present invention based on specific circumstances.

[0019] The present invention will be described in detail below with reference to the accompanying drawings and in combination with embodiments.

[0020] like Figure 1In the multi-optical system shown, the number of optical systems is assumed to be n. Each optical system includes a camera. The brands or models of the n cameras may be the same or different, and cameras of different brands or models typically use different camera control instructions. Each optical system includes an image processing terminal, which corresponds to n image processing terminals. Each image processing terminal is equipped with an image acquisition card (hereinafter referred to as an acquisition card). An acquisition card is typically a hardware card that plugs into a PCI Express (PCIe) slot on a computer motherboard. The acquisition card company provides the acquisition card with an acquisition card driver and an acquisition card programming interface to facilitate image acquisition by developers. Image processing software is deployed in the image processing terminal, and the image acquisition and camera control system is a submodule of the image processing software. Typically, the camera transmits image data to the image acquisition and camera control system via the acquisition card. The image acquisition and camera control system then sends camera control instructions to the camera via the acquisition card's virtual serial port link or the computer's actual serial port link. The software and software code referred to in the embodiments of the present invention refer to the software or software code corresponding to the telescope image acquisition and camera control system program, or to the software or software code corresponding to the program with the telescope image acquisition and camera control system as a subsystem of the present invention.

[0021] Figure 1 The n optical systems shown may belong to different types of optical systems of the same telescope, or may belong to the same type of optical systems of different telescopes. Although they differ in detection capability, optical field of view, and detection band, the functions of their image processing software are roughly the same.

[0022] In the case of different camera control instructions or acquisition card programming interfaces, it is difficult to deploy a single version of code to different terminals for compilation and execution. Figure 1 For the multi-optical system shown in the figure, a programming method for telescope image acquisition and camera control system is proposed. It is divided into the compilation process and the running process. The specific contents are as follows: The programming method of an embodiment of the present invention includes: a camera communication module, an image acquisition module, an automatically constructed project configuration file, an automatically constructed acquisition card configuration file, and a runtime camera configuration file, wherein the automatically constructed acquisition card configuration file includes acquisition card information, an acquisition card programming interface header file directory, and an acquisition card programming interface link library; the image acquisition module includes an image acquisition interface class and an image acquisition derived class; the runtime camera configuration file includes a configuration of a camera brand and model; and the camera communication module includes a camera communication interface class and a camera communication derived class.

[0023] In program development, the automated build configuration file determines which files need to be compiled, which files do not need to be compiled, and the compilation order of the files that need to be compiled. Common automated build configuration files include makefile, QT's pro file, etc. The embodiment of the present invention involves two automated build configuration files, namely an automated build project configuration file and an automated build acquisition card configuration file. In the embodiment of the present invention, the deployment method of the automated build configuration file is as follows: the automated build project configuration file is integrated into the software code. Specifically, when the software code is compiled on a certain computer, the automated build project configuration file is deployed to the corresponding computer along with the software code; the automated build acquisition card configuration file is related to the acquisition card and the acquisition card programming interface. The automated build acquisition card configuration file is deployed in a fixed directory in the computer file system. Unless the acquisition card changes or the acquisition card programming interface changes, the automated build acquisition card configuration file does not change.

[0024] The automatic construction of the capture card configuration file mainly defines the following three information: capture card information, capture card programming interface header file directory, and capture card programming interface link library. The automatic construction project configuration file includes the automatic construction of the capture card configuration file. The compiler selects the code related to the capture card for compilation based on the capture card information.

[0025] In an embodiment of the present invention, a runtime camera configuration file deployment method is as follows: the runtime camera configuration file is deployed in a fixed directory in a computer file system, recording the camera brand and model. Unless the camera brand and model change, the file does not change. That is, the runtime camera configuration file changes if and only if the camera brand and model changes.

[0026] The embodiment of the present invention applies an object-oriented programming language and adopts a polymorphic programming method to design an image acquisition module. Specifically, the image acquisition interface class is defined as an abstract class, which only provides function interfaces such as starting acquisition, stopping acquisition, and image acquisition callback. The functions specifically for different acquisition cards are implemented by each derived class, and the interface design of the image acquisition module is completed during the program compilation process.

[0027] The embodiment of the present invention applies an object-oriented programming language and adopts a polymorphic programming method to design a camera communication module. Specifically, the camera communication interface class is defined as an abstract class, which provides a function interface for setting camera parameters. The communication instructions specifically for cameras of different brands and models are implemented by each derived class, and the interface design of the camera communication module is completed during the initialization process after the software is running.

[0028] Typically, implementing interface design during software runtime requires only code modifications, making it simple to implement. However, implementing interface design during program compilation requires modifying the automated build project configuration file, which is cumbersome and error-prone. In this embodiment of the present invention, the camera communication module calls the operating system interface, allowing for runtime design. However, because the image acquisition module calls the interface of an external hardware driver, failure to implement interface design during program compilation would result in compilation errors and software inoperability. Therefore, interface design for the image acquisition module must be performed during program compilation. Specifically, interface design for the camera communication module can also be completed during program compilation.

[0029] like Figure 2 As shown, the software code compilation principle of the embodiment of the present invention is as follows: The automated construction project configuration file determines the image acquisition derived class header file and image acquisition derived class source file involved in the compilation by reading the automated construction acquisition card configuration file. The automated construction project configuration file finds the automated construction acquisition card configuration file in the specified directory, loads the acquisition card information, the acquisition card programming interface header file directory, and the acquisition card programming interface link library. The automated construction project configuration file compiles the image acquisition derived class code corresponding to the acquisition card according to the acquisition card information. The image acquisition module reads the acquisition card information and instantiates the image acquisition derived class i, where i represents the serial number of multiple image acquisition derived classes.

[0030] like Figure 3 As shown, the software initialization process of the embodiment of the present invention is as follows: The camera communication module finds the runtime camera configuration file in the specified directory and reads the camera brand and model information. The camera communication module instantiates the camera communication derived class j according to the camera brand and model information, where j represents the serial number of multiple camera communication derived classes.

[0031] Automatically build acquisition card configuration files and runtime camera configuration files, which can be pre-configured on the image processing terminal. The image acquisition and camera control system programs can be selectively compiled according to the actual acquisition card and acquisition card programming interface. During software operation, control instructions are sent according to the actual camera brand and model, which reduces the workload of software development, reduces the workload of code maintenance, reduces the difficulty of software debugging, improves the scalability of cameras and acquisition cards, and enhances the software adaptability.

[0032] The embodiment of the present invention uses two optical systems in a multi-optical system telescope device as an example for experimental verification: The two optical systems are medium-wave optical system and short-wave optical system. The data information of the two optical systems are as follows: the medium-wave optical system uses camera model GKTC_XX, with a resolution of The camera control protocol is Protocol_MIR (the protocol is provided by the camera manufacturer). The medium-wave image processing terminal uses a DALSA acquisition card for image acquisition. The driver (SDK) version number is 8.31.0.1287. The short-wave optical system uses a camera model LD_XX with a resolution of The camera control protocol is Protocol_SIR (the protocol is provided by the camera manufacturer). The shortwave image processing terminal uses a MATROX acquisition card for image acquisition. The driver (SDK) version number is 10.00.

[0033] The embodiment of the present invention is directed to the control of telescope image acquisition, and thus can be understood as an image processing system that processes images acquired by a telescope.

[0034] The two optical systems have similar working principles and operating methods. For example, camera control includes setting exposure time, frame rate, trigger mode, and gain, and image processing includes image preprocessing, target recognition, and target tracking. The differences before and after using the image processing system of the present invention are as follows: Using traditional image processing system design methods, due to differences in acquisition card models, acquisition card driver (SDK) versions, and camera control protocols, a single image processing system cannot be reused across both medium-wave and short-wave image processing terminals. This necessitates the maintenance of two separate code sets for both the medium-wave and short-wave image processing systems. Once the image acquisition and camera control modules in an image processing system are developed, modifications are extremely rare. Subsequent system upgrades primarily focus on image processing algorithms and operational procedures. After upgrading one image processing system, the changes must be manually synchronized with the other image processing systems. This inevitably leads to code differences after multiple manual synchronizations, making maintenance of multiple image processing systems increasingly difficult over time. Furthermore, because traditional image processing system design methods cannot accommodate different acquisition card models or driver (SDK) versions, system upgrades can only be verified through on-site code modifications, preventing local verification and remote deployment.

[0035] Using the system design method of the present invention, the image processing system automatically selects the corresponding driver (SDK) and camera control protocol during compilation and runtime, regardless of differences in capture card models, capture card driver (SDK) versions, and camera control protocols. This allows for reuse of a single image processing system on both medium-wave and short-wave image processing terminals, eliminating the need to maintain two sets of code. Later, iterative upgrades to the system's image processing algorithms and operational procedures require only a single code modification. Multi-terminal deployment allows for adaptability to different capture card models and driver (SDK) versions, enabling local modification and verification while enabling remote deployment.

[0036] For ease of explanation, the present invention uses only two optical systems as an example. In actual telescopes, there are typically more than two optical systems, and updates to camera protocols, acquisition card models, and driver (SDK) versions are common. Traditional programming methods increase exponentially in development and maintenance difficulty as the number of optical systems increases. The programming method of the present invention is of great significance in multi-optical telescopes, and the more optical systems there are, the more pronounced the effect.

[0037] Although the 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 may make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

[0038] The above specific embodiments of the present invention do not constitute a limitation on the scope of protection of the present invention. Any other corresponding changes and modifications made based on the technical concept of the present invention should be included in the scope of protection of the claims of the present invention.

Claims

1. A program design method for telescope image acquisition and camera control system, characterized in that: include: Camera communication module, image acquisition module, automated construction project configuration file, automated construction acquisition card configuration file, and runtime camera configuration file; When compiling: The automated construction project configuration file finds the automated construction acquisition card configuration file in a specified directory, loads acquisition card information, an acquisition card programming interface header file directory, and an acquisition card programming interface link library, the automated construction project configuration file determines the image acquisition derived class code corresponding to the acquisition card based on the acquisition card information, the image acquisition module reads the acquisition card information, and instantiates an image acquisition derived class i, where i represents a plurality of image acquisition derived class serial numbers; Runtime: The camera communication module finds the runtime camera configuration file in the specified directory and reads the camera brand and model information. The camera communication module instantiates the camera communication derived class j according to the camera brand and model information, where j represents the serial number of multiple camera communication derived classes.

2. The program design method for a telescope image acquisition and camera control system according to claim 1, wherein: The automated construction engineering configuration file is integrated into the software code and deployed to the corresponding computer along with the software code.

3. The program design method for telescope image acquisition and camera control system according to claim 1, characterized in that: The automatically constructed acquisition card configuration file includes acquisition card information, an acquisition card programming interface header file directory, and an acquisition card programming interface link library.

4. The program design method for a telescope image acquisition and camera control system according to claim 1, wherein: The automatic construction project configuration file determines the image acquisition derived class header file and the image acquisition derived class source file involved in the compilation by reading the automatic construction acquisition card configuration file.

5. The program design method for telescope image acquisition and camera control system according to claim 1, characterized in that: The interface design of the image acquisition module is completed during the program compilation process.

6. The program design method for a telescope image acquisition and camera control system according to claim 5, characterized in that: The image acquisition module is designed by adopting a polymorphic programming method and applying an object-oriented programming language.

7. The program design method for a telescope image acquisition and camera control system according to claim 1, wherein: The interface design of the camera communication module is completed during the initialization process after the software is running.

8. The program design method for a telescope image acquisition and camera control system according to claim 7, wherein: The camera communication module is designed by adopting a polymorphic programming method and applying an object-oriented programming language.

Images