Image acquisition processing method and device based on agent guidance, equipment and medium

Abstract

This invention relates to the field of image processing technology and can be applied to business scenarios such as fintech. It discloses a proxy-guided image acquisition and processing method, apparatus, device, and medium, comprising: providing a lightweight front-end corresponding to the user terminal's operating system environment; proxying the image acquisition component to obtain a real-time image preview stream; performing feature analysis on the real-time image preview stream to determine the key features of the acquisition target; displaying guidance information based on the key features and adjusting the operating parameters of the image acquisition component; acquiring the final image data; performing anomaly judgment and adding anomaly markers locally on the user terminal; and sending the final image data containing the anomaly markers to a management terminal via an intermediate connection protocol and receiving feedback information. This invention introduces a proxy mechanism into the lightweight front-end, realizing real-time image acquisition analysis guidance, local anomaly judgment marking, and synchronous transmission of data feedback, improving the standardization of acquisition results and reducing data flow delays and redundant processing.

Description

Technical Field

[0001] This invention relates to the field of image processing technology, and in particular to an image acquisition and processing method, apparatus, device, and medium based on agent guidance. Background Technology

[0002] In the field of commercial property insurance inspection technology, as inspection methods shift from offline to online mobile terminals, existing technologies are gradually revealing several shortcomings. Currently, inspection front-ends typically use single applications or browser-based web pages. Terminals under different operating system environments vary significantly in performance, startup methods, and interactive capabilities, making it difficult for inspection front-ends to run stably or use them inconveniently on some terminals. This affects merchants' enthusiasm for participating in inspections and results in insufficient inspection data coverage.

[0003] Regarding the collection of inspection images, current technologies mainly rely on merchants to take and upload images independently, lacking effective real-time guidance and constraint mechanisms. Merchants are prone to overlooking key areas related to risk assessment, or producing blurry or severely obscured images due to poor shooting conditions. Existing text prompts have inconsistent presentation effects across different operating systems, offering limited guidance and still generating a large number of non-compliant inspection images, increasing the burden of subsequent review and re-shooting.

[0004] Furthermore, existing technologies generally lack the ability to instantly assess and label inspection images at the acquisition end. Image quality and anomalies typically rely on manual review at the back end, resulting in a sluggish and inefficient process. Simultaneously, data synchronization between different terminals suffers from insufficient timeliness, making it difficult to obtain inspection results promptly at the management end, thus impacting the collaborative efficiency of inspection operations and overall management effectiveness. Summary of the Invention

[0005] The main objective of this invention is to provide an image acquisition and processing method, apparatus, device, and storage medium based on proxy guidance, aiming to solve the technical problems of existing technologies lacking unified adaptation capabilities for terminals with multiple operating systems, failing to effectively guide key content and quality control during image acquisition, and having untimely synchronization of acquisition results, thus affecting the availability and processing efficiency of inspection data.

[0006] To achieve the above objectives, the present invention provides an image acquisition and processing method based on proxy guidance, comprising: Provide a lightweight front-end that corresponds to the user terminal's operating system environment; In response to a capture command triggered on the lightweight front end, the image capture component of the user terminal is invoked through a proxy in the lightweight front end to obtain a real-time image preview stream of the capture target; Feature analysis is performed on the real-time image preview stream to determine the key features of the target being acquired; Based on the analysis results of the key features, the agent displays guidance information in the lightweight front end and adjusts the operating parameters of the image acquisition component based on the guidance information; The final image data of the target is obtained according to the adjusted operating parameters. The agent performs anomaly judgment on the final image data locally on the user terminal and adds anomaly marker to the final image data according to the anomaly judgment result. The final image data containing the anomaly identifier is sent to the management terminal via an intermediate connection protocol, and feedback information is received from the management terminal based on the final image data.

[0007] Furthermore, to achieve the above objectives, the present invention provides an image acquisition and processing apparatus based on proxy guidance, comprising: Lightweight front-end build module, used to provide a lightweight front-end that corresponds to the user terminal's operating system environment; The image acquisition scheduling module is used to respond to the acquisition command triggered on the lightweight front end, and call the image acquisition component of the user terminal through the agent in the lightweight front end to obtain the real-time image preview stream of the acquisition target; The preview feature analysis module is used to perform feature analysis on the real-time image preview stream to determine the key features of the acquisition target. The guidance and parameter control module is used to display guidance information in the lightweight front end through the agent based on the analysis results of the key features, and to adjust the operating parameters of the image acquisition component based on the guidance information. The local anomaly detection module is used to obtain the final image data of the target acquisition based on the adjusted operating parameters, perform anomaly detection on the final image data locally on the user terminal through the agent, and add anomaly identifier to the final image data according to the anomaly detection result. The intermediate protocol communication module is used to send the final image data containing the anomaly identifier to the management terminal through the intermediate connection protocol, and to receive feedback information returned by the management terminal based on the final image data.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a proxy-guided image acquisition and processing program stored in the memory and executable on the processor, wherein when the proxy-guided image acquisition and processing program is executed by the processor, it implements the steps of the proxy-guided image acquisition and processing method described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a proxy-guided image acquisition and processing program, wherein the proxy-guided image acquisition and processing program, when executed by a processor, implements the steps of the proxy-guided image acquisition and processing method described above.

[0010] Beneficial Effects: This invention relates to the field of image processing technology and can be applied to business scenarios such as fintech. It discloses a proxy-guided image acquisition and processing method, apparatus, device, and medium, comprising: providing a lightweight front-end corresponding to the user terminal's operating system environment; obtaining a real-time image preview stream by calling an image acquisition component through a proxy; performing feature analysis on the real-time image preview stream to determine the key features of the acquisition target; displaying guidance information based on the key features and adjusting the operating parameters of the image acquisition component; acquiring the final image data and performing anomaly judgment and adding anomaly markers locally on the user terminal; and sending the final image data containing the anomaly markers to a management terminal through an intermediate connection protocol and receiving feedback information. This invention, by introducing a proxy mechanism into the lightweight front-end, performs real-time analysis and guidance on the image acquisition process, completes anomaly judgment and marking locally, and then achieves synchronous transmission of data and feedback, thereby improving the standardization of image acquisition results and reducing delays and redundant processing in the inspection data flow process. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for an image acquisition and processing method based on proxy guidance according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the proxy-guided image acquisition and processing method of the present invention; Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the image acquisition and processing device based on proxy guidance of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The proxy-guided image acquisition and processing method provided in this invention can be applied to, for example... Figure 1In this application environment, the client communicates with the server via a network. The server can access a lightweight front-end corresponding to the operating system environment through the client, and obtain a real-time image preview stream by calling the image acquisition component through a proxy; perform feature analysis on the real-time image preview stream to determine the key features of the acquisition target; display guidance information based on the key features and adjust the operating parameters of the image acquisition component; acquire the final image data and perform anomaly judgment and anomaly labeling locally on the client; send the final image data containing the anomaly label to the management terminal through an intermediate connection protocol and receive feedback information. This invention improves the standardization of image acquisition results and reduces delays and redundant processing in the inspection data flow process by introducing a proxy mechanism in the lightweight front-end, performing real-time analysis and guidance on the image acquisition process, completing anomaly judgment and labeling locally, and then realizing synchronous transmission of data and feedback. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster composed of multiple servers. The invention will be described in detail below through specific embodiments.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the proxy-guided image acquisition and processing method provided by the present invention. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0015] like Figure 2 As shown, the image acquisition and processing method based on proxy guidance proposed in this invention includes the following steps: S10 provides a lightweight front-end that corresponds to the user terminal's operating system environment; In this embodiment, during the shop inspection process, user terminals may run on Android, iOS, or Harmony systems. These different systems differ in their application runtime containers, system permission models, startup methods, and resource management mechanisms. Using a uniform front-end design could easily lead to issues such as some terminals failing to start, loading slowly, or experiencing limited interaction. Therefore, it is necessary to provide a lightweight front-end design tailored to the user terminal's current operating system environment.

[0016] This process identifies the user terminal's operating system type and supported operating modes to determine how the front-end is hosted on the terminal side. For terminals that support browser operation, the front-end loads as a webpage; for terminals that support lightweight application containers, the front-end runs as a lightweight application; and for terminals that support atomic service mechanisms, the front-end is launched as a system-level service entry point.

[0017] Lightweight front-ends control the interface structure, resource size, and startup process during the build process, ensuring stable operation on low-configuration Android devices, iOS browsers or lightweight application environments, and the atomic service environment of the Harmony system. During front-end loading, script execution, resource loading order, and permission invocation methods are adapted to different operating systems to avoid loading failures or runtime anomalies caused by system differences.

[0018] By employing the above methods, the front-end can run in the corresponding form under various operating system environments, providing a consistent inspection entry point for user terminals and ensuring the availability and stability of the front-end environment on different systems.

[0019] In the Android system environment, the front end can run as a web page or be launched as a lightweight application. By reducing the local installation size and startup dependencies, low-performance terminals can smoothly enter the inspection interface.

[0020] In the iOS system environment, the front end can be presented as a webpage or a lightweight application. When launched, the resource loading method is adjusted according to system restrictions to avoid interface loading interruption caused by browser or system policies.

[0021] In the Harmony system environment, the front-end can run as an atomic service and be launched directly through the desktop entry, omitting the complete application loading process and improving the response speed when entering the inspection interface.

[0022] For different system environments, front-end resources can be tailored differently to ensure that the interface rendering and interaction logic match the capabilities of the terminal system.

[0023] This embodiment provides a lightweight front-end based on the user terminal's operating system environment, ensuring that the inspection entry points under different systems such as Android, iOS, and Harmony remain available and stable, reducing the impact of system differences on front-end operation, thereby improving access consistency and usage continuity in multi-terminal inspection scenarios.

[0024] S20, in response to the acquisition command triggered on the lightweight front end, the image acquisition component of the user terminal is invoked through the agent in the lightweight front end to obtain the real-time image preview stream of the acquisition target; In this embodiment, while the lightweight front-end runs on the user terminal, it needs to invoke image acquisition capabilities without compromising its lightweight nature. Since the lightweight front-end itself does not directly access the hardware image acquisition components, a proxy set up within the front-end acts as an intermediate control unit to receive and convert acquisition commands. When the user triggers an image acquisition-related operation in the lightweight front-end's interface, the operation is recognized as an acquisition command and received by the proxy within the front-end.

[0025] Upon receiving a data acquisition command, the agent parses the command to determine the current acquisition target and type. It then generates a call request that matches the system interface specifications, taking into account the user terminal's operating system environment. In an Android system environment, the agent initiates the call request through the system-provided image acquisition interface; in an iOS system environment, the agent accesses the image acquisition component through the system's authorization mechanism; and in a Harmony system environment, the agent invokes the image acquisition component through system service capabilities.

[0026] After the agent initiates the call request, the image acquisition component in the user terminal is activated, and the image sensor begins to continuously output raw image data frames. The agent receives and processes the data returned by the acquisition component, and organizes the continuously output image data into a real-time image preview stream. This allows the lightweight front-end to present the current state of the target image in real time without storing complete image files. In this way, the real-time image preview stream is continuously updated on the front-end side to reflect the imaging status of the target image at the current moment.

[0027] In some implementations, the acquisition command is triggered by interactive controls in the front-end interface. The proxy captures the command content by listening to changes in the control's state and generates the call parameters accordingly. In the Android terminal, the proxy obtains image frame data through the system camera service interface; in the iOS terminal, the proxy completes the call through the system image acquisition permission mechanism; in the Harmony terminal, the proxy obtains image acquisition capabilities through the system service interface.

[0028] In different terminal environments, the agent can adapt the image frame resolution, frame rate or data format to ensure the continuity and stability of the real-time image preview stream in the front end, and avoid preview interruption or delay caused by system differences.

[0029] This embodiment introduces a proxy within a lightweight front-end to receive acquisition commands and uniformly call the image acquisition component of the user terminal. This enables image acquisition behavior under different operating system environments to be triggered in a consistent manner and return preview results in real time, thereby achieving stable real-time image preview capabilities without increasing the front-end load.

[0030] S30, Perform feature analysis on the real-time image preview stream to determine the key features of the acquisition target; In this embodiment, since the real-time image preview stream is continuously output by the image acquisition component and updated in the lightweight front-end, it is necessary to analyze the image content in the preview stream to identify key features related to the acquisition target. The real-time image preview stream consists of consecutive image frames, each reflecting the imaging state of the acquisition target at the current moment. Therefore, feature analysis is carried out using image frames as the basic processing unit.

[0031] During feature analysis, the agent selects the currently valid preview frame from the real-time image preview stream and parses the image data in the preview frame. The parsing includes information about the regions, contours, and spatial distribution of the image related to the target. By analyzing the image's brightness distribution, edge variations, and regional structure, feature information describing the target's state can be extracted from the preview frame.

[0032] During the analysis of continuous preview streams, the agent not only processes individual preview frames but also considers the changes between adjacent frames to assess the stability of the target in terms of spatial location, completeness, and visibility. By comprehensively processing the feature extraction results of continuous image frames, a set of key features reflecting the structural characteristics and presentation state of the target is formed. These key features describe whether the target is fully presented, whether it is located within a reasonable shooting area, and whether there are obvious omissions or occlusions, thus providing a basis for subsequent processing.

[0033] In some implementations, the agent periodically selects preview frames from the real-time image preview stream and performs image preprocessing operations on the preview frames, including brightness normalization and noise suppression, to improve the stability of subsequent feature analysis. Then, edge detection and region segmentation operations are performed on the preview frames to obtain the contour information and spatial distribution of the target in the image.

[0034] During continuous frame processing, the agent can compare feature results in adjacent frames to determine whether the target object has undergone significant displacement or image shift, thereby filtering out representative key features. Under different terminal environments, this processing can adjust the preview frame sampling frequency according to terminal performance to balance analysis accuracy and terminal resource consumption.

[0035] This embodiment performs continuous feature analysis on the real-time image preview stream and extracts key information that reflects the structure and presentation status of the target, enabling the target to be effectively identified and described before formal imaging, providing a reliable status basis for subsequent processing.

[0036] S40, based on the analysis results of the key features, the agent displays guidance information in the lightweight front end, and adjusts the operating parameters of the image acquisition component based on the guidance information; In this embodiment, based on the key features already determined from the real-time image preview stream, the analysis results need to be transformed into guidance information that can be intuitively understood by the end user, and further applied to the operational status of the image acquisition component. The key features reflect the spatial location, completeness, and clarity of the target object in the current preview screen. This information is not directly presented to the user but serves as the input basis for guidance generation.

[0037] The agent parses key features within the lightweight front-end, mapping state information related to the capture quality of the target into guidance information. This guidance information indicates deviations in the current preview, such as target position misalignment, inappropriate shooting distance, or insufficient image clarity. This guidance information is displayed in the lightweight front-end in a format compatible with the terminal's operating system environment, providing users with immediate feedback without leaving the shooting interface.

[0038] Simultaneously with the generation of guidance information, the agent adjusts and controls the operating parameters of the image acquisition component based on the status results corresponding to key features. These operating parameters include basic configuration items that affect imaging quality. By adjusting these parameters, the image acquisition component is placed in a working state more suitable for acquiring the target image in the current acquisition scenario. A linkage exists between the guidance information and the operating parameter adjustments: the guidance information prompts the user's operational direction, while the operating parameter adjustments synchronously improve imaging conditions, thereby dynamically correcting the acquisition process during the preview stage.

[0039] In some implementations, the agent generates visual guidance elements in a lightweight front-end based on the spatial location of the target area reflected in the key features. The target area is then overlaid on the preview screen as a border or prompt area. Simultaneously, combined with the clear status information reflected in the key features, the focus or exposure parameters of the image acquisition component are automatically adjusted to adapt to the current shooting distance and lighting conditions.

[0040] The presentation of guidance information can be adapted to different operating system environments. For example, it can be displayed as a real-time prompt on Android devices, as a floating prompt on iOS devices, and in the Harmony environment, it can be displayed in a way that is closer to native interaction, taking into account system capabilities. The adjustment range of running parameters can be limited according to the terminal hardware capabilities to avoid putting additional load on low-performance devices.

[0041] This embodiment transforms the key feature analysis results into intuitive guidance information and simultaneously adjusts the operating status of the image acquisition component, enabling continuous correction during the preview stage of the acquisition process, effectively reducing imaging deviations caused by improper shooting position, clarity, or parameter settings.

[0042] S50: Obtain the final image data of the target based on the adjusted operating parameters; perform anomaly judgment on the final image data locally on the user terminal through the agent; and add an anomaly identifier to the final image data based on the anomaly judgment result. In this embodiment, after the operating parameters of the image acquisition component have been adjusted and stabilized, the image acquisition component performs an image capture operation according to the current operating parameters to obtain the final image data for subsequent processing. The final image data differs from the real-time preview stream; it meets the business requirements corresponding to the acquisition target in terms of resolution, compression strategy, and imaging stability, and is used to reflect the complete state of the acquisition target.

[0043] After the final image data is generated, the agent performs anomaly detection processing on the image data locally on the user terminal. Anomaly detection takes the image data itself as the analysis object, extracts image feature information related to the acquisition target, and compares it with a pre-defined anomaly judgment benchmark. The anomaly judgment benchmark is used to describe the image states that are allowed or not allowed in the current business scenario, such as missing, occluded, blurred, or significantly offset acquisition targets.

[0044] When there is a discrepancy between the image feature information and the anomaly determination benchmark, the agent generates a corresponding anomaly determination result and adds an anomaly identifier to the final image data accordingly. The anomaly identifier is used to mark the state of the image data, and it forms a correlation with the final image data, so that the image data carries additional state information that can be used for subsequent processing while keeping the original content unchanged.

[0045] In some implementations, the agent on the Android terminal calls local image processing capabilities to perform sharpness and integrity analysis on the final image data, and matches the analysis results with preset anomaly detection conditions to determine whether an anomaly flag needs to be generated. On the iOS terminal, the agent uses the system-provided image analysis interface to perform feature extraction and generates a status tag associated with the image data locally. On the Harmony terminal, it can leverage the device-side intelligent computing capabilities to quickly determine occlusion or missing information and write the anomaly flag on the terminal side.

[0046] The expression of the anomaly identifier can be a structured status field or additional information bound to the image data. It can be adjusted according to the storage method and performance conditions in different terminal environments, but the consistent association between the anomaly identifier and the final image data is maintained.

[0047] This embodiment enables image data to have clear state differentiation capabilities at the generation stage by completing the anomaly judgment and anomaly labeling of the final image data locally on the user terminal, thereby reducing the need for repeated judgments in subsequent processing stages and lowering the probability of invalid images entering the subsequent process.

[0048] S60, the final image data containing the anomaly identifier is sent to the management terminal via an intermediate connection protocol, and feedback information is received from the management terminal based on the final image data.

[0049] In this embodiment, after the final image data has been marked with anomaly indicators, the image data, along with the anomaly indicators, needs to be transmitted to the management terminal to support subsequent business processing and manual decision-making. To achieve stable communication between different terminals and the management side, an intermediate connection protocol is introduced as a unified communication mechanism for data interaction. The intermediate connection protocol defines the encapsulation format, transmission order, and communication session rules for image data, anomaly indicators, and related status information, thereby reducing the complexity of interaction between different operating systems and devices.

[0050] During the transmission phase, the final image data and anomaly identifier are combined into a unified data object and encapsulated according to the intermediate connection protocol specifications, forming a data carrier that can be transmitted over the network. This data carrier carries information related to the abnormal state while maintaining the original content of the image data, enabling the management terminal to directly identify the image status upon receipt without needing to perform image quality or risk assessment again.

[0051] During the receiving phase, after parsing the received data, the management terminal generates feedback information based on the image data content and anomaly indicators. This feedback information describes the processing results, confirmation status, or supplementary explanations on the management terminal side and is returned to the user terminal via the same intermediate connection protocol. This two-way communication mechanism creates a closed-loop relationship between the image data and the processing feedback, avoiding information fragmentation or status asynchrony.

[0052] In some implementations, the intermediate connection protocol establishes a communication channel based on persistent connections, enabling the user terminal to continuously receive feedback information from the management terminal after sending image data. In Android terminals, protocol session maintenance can be achieved through the system network interface; in iOS terminals, the system's network communication capabilities can be used for protocol encapsulation and parsing; and in Harmony terminals, system-level communication capabilities can be combined to achieve low-latency data interaction.

[0053] The content of the feedback information can be adjusted according to business needs, such as including processing confirmation marks, retake prompts, or status descriptions. Different terminal sides are uniformly parsed through an intermediate connection protocol to ensure that the feedback information can be correctly identified and displayed.

[0054] This embodiment achieves unified transmission of final image data and anomaly identifiers through an intermediate connection protocol, and synchronously receives feedback information returned by the management terminal, so that the image data remains consistent in state during cross-terminal transfer, reducing the cost of repeated communication and manual confirmation caused by information transmission delays.

[0055] In one embodiment, step S10 includes: S101, Identify the operating system environment parameters of the user terminal, wherein the operating system environment parameters include operating system type, version information, hardware performance indicators and specific system function support status; S102, determine the lightweight front-end form corresponding to the operating system environment parameters; S103, Obtain the program code and resource configuration file that match the lightweight front-end form; S104, Using the program code and loading the resource configuration file, instantiate the lightweight front-end on the user terminal; S105, based on the hardware performance indicators and specific system function support status in the operating system environment parameters, the lightweight front-end is adapted and adjusted in terms of memory allocation and loading priority to complete the deployment of the lightweight front-end in the operating system environment.

[0056] In this embodiment, the goal is to transform terminal-side differences into executable front-end form selection and assembly actions, enabling the same business entry point to form a runnable entity in Android, iOS, Harmony, and H5 formats, and mapping terminal resource constraints into controllable adjustments to loading order and memory usage. The meaning of a lightweight front-end is not limited to a single implementation form; it can manifest as an H5 page within a browser, a distributable lightweight application container on iOS, an atomic service entry point on Harmony, or a lightweight runtime shell or small-volume component set on Android. Their common features are a short startup chain, resource package splitting, on-demand loading, and permission request paths compressed to the necessary business scope.

[0057] Identifying the operating system environment parameters of the user terminal serves as the basis for environment quantification and traffic distribution. Operating system type determines the callable front-end hosting format and system capability entry points. For example, Android leans towards application runtime and system camera interface sets, iOS towards WebView or lightweight application containers and permission models, Harmony towards atomic service entry points and system component invocation methods, and H5 towards browser kernel and page lifecycle mechanisms. Version information is used to locate interface differences and compatibility paths. Different versions of the same operating system may exhibit differences in permission pop-up processes, media acquisition interface parameters, and rendering mechanisms. Version information is used to select compatibility layer implementations or alternative interface combinations. Hardware performance metrics characterize resource limits and fluctuation ranges. Sources can include device capability query interfaces provided by the operating system, runtime performance counters, memory levels, and available storage space reads, or detection records from the initial startup written to the local configuration. The specific system function support status is used to determine whether a specific capability switch or system-level component support is available. The source can be feature detection calls, permission request status, camera capability enumeration results, graphics acceleration capability identifiers, atomic service availability identifiers, etc. In inspection scenarios, this status will directly affect the choice of entry form and resource loading decisions. For example, on Harmony terminals that support atomic services, the desktop direct entry will be selected first. On iOS terminals, H5 or lightweight application containers will be selected based on system version and container restrictions. On low-resource devices, a smaller resource set and a more conservative loading strategy will be adopted. Typical cases include the difference in startup speed and resource consumption targets between "low-memory terminals for the elderly" and "high-performance terminals for work".

[0058] Determining the lightweight front-end form corresponding to the operating system environment parameters is a strategy implementation action. This can be achieved using mapping tables or conditional expressions, but outwardly, it combines the operating system type, version information, hardware performance indicators, and specific system function support status into a deterministic selection result. The lightweight front-end form can encompass two layers of meaning: the hosting type and the running mode. The hosting type determines whether it's H5, an iOS lightweight application container, a Harmony atomic service, or an Android lightweight runtime shell. The running mode determines whether to enable offline resource packages, incremental updates, weak network degradation, and simplified rendering paths, etc. To avoid fixing the selection result to a single device or system version, the form determination can be output as a set of options, sorted by priority, and then combined with actual availability verification to obtain the final form. This ensures that a runnable entry point remains even when system capability detection and permission granting results change.

[0059] The process involves acquiring program code and resource configuration files that match the lightweight front-end architecture to complete the executable assembly. The program code is not limited to a single language or a single build artifact; it can be H5 scripts and page logic, the runtime shell code of a lightweight application container, the entry code of atomic services, or component-based module code on the Android side. The resource configuration file describes resource loading relationships, dependency lists, route entry points, permission declarations, feature switches, caching strategies, static resource indexes, version identifiers, and integrity verification information. Its source can be server-side configurations, pre-configured local configurations, or a combined configuration. The acquisition process can be completed via network fetching or local reading. Network fetching can be split into a basic package and a differential package, carrying version numbers to avoid downloading the entire package each time. Local reading can utilize pre-configured resource directories or cache directories, and use validation fields to determine if an update is needed. To reduce the probability of entry point failure, the acquisition phase typically generates a minimum available resource set for fallback, such as a resource group containing only the homepage skeleton, minimal scripts, and necessary styles, to ensure that the basic interface can still be instantiated when resources are missing or the network is unavailable.

[0060] Instantiating a lightweight frontend on a user terminal using program code and loading resource configuration files falls under the category of runtime entity generation. The key is binding code artifacts and configuration artifacts into a startable frontend process or page instance. Instantiation can manifest as creating an H5 page runtime context and injecting configuration items, creating a lightweight application container instance and loading the entry route, creating an atomic service instance and completing capability registration, or creating a lightweight Android runtime shell and loading component modules. During instantiation, configuration parsing, dependency validation, resource path mapping, permission pre-checking, and startup parameter writing are typically performed to ensure that subsequent interactions can directly access the data collection interface without repeated, costly initialization. Here, "user terminal" emphasizes the terminal entity used on the business side, including both merchant-side terminals and survey-side terminals with higher performance and more permission configurations. The instantiation action itself remains consistent; the differences lie only in the configuration and resource sets.

[0061] Based on the hardware performance indicators in the operating system environment parameters and the specific system function support status, the lightweight front-end's memory allocation and loading priority are adapted and adjusted, which is reflected in the specific control of runtime resource scheduling and loading order. Memory allocation can be achieved by limiting the cache limit, limiting the number of preloaded resources, controlling the concurrent decoding of images and scripts, setting texture or bitmap cache thresholds, and releasing inactive modules as needed; these control points depend on the resource limits given by the hardware performance indicators, as well as real-time water level monitoring at runtime. Loading priority can be achieved by splitting resources into a startup-required set and a deferred loading set and setting a loading queue. The startup-required set contains the minimum resources required for entry rendering, while the deferred loading set contains non-critical materials, optional components, and enhanced capabilities; when the specific system function support status indicates that the terminal supports stronger capabilities, the loading queue can introduce enhanced resources in advance, such as higher-resolution bootstrap materials or more complex interface animations; when the capabilities are insufficient, a streamlined queue is maintained to avoid triggering system recycling and page exit. The meaning of deployment completion here can be reflected in the lightweight front-end reaching a stable state where it can be started, rendered, and responsive to interactions, and its resource consumption and loading order have been adjusted according to the terminal environment, so that subsequent triggering of collection commands no longer relies on repeated environment detection and large-scale resource loading.

[0062] This embodiment identifies the operating system type, version information, hardware performance indicators, and specific system function support status to drive the determination of the lightweight front-end form. Then, based on form matching, it obtains program code and resource configuration files and completes instantiation. At the same time, it adapts and adjusts memory allocation and loading priority according to hardware performance indicators and specific system function support status. This allows different terminals to form a running entity consistent with their system capabilities during the entry creation stage and controls resource consumption and loading order. This reduces the probability of multi-terminal entry unavailability and startup failure, and alleviates the problems of lag, exit, and insufficient resources on low-resource terminals during the loading stage.

[0063] In one embodiment, step S20 above includes: S201, an operable control is presented in the interactive interface of the lightweight front end, and a collection command is generated in response to the trigger operation of the operable control. S202, the acquisition command is received and parsed through the proxy in the lightweight front end to determine the calling parameters of the image acquisition component of the user terminal and generate the underlying calling command; S203, execute the underlying call instruction to start the image acquisition component of the user terminal, and control the image acquisition component to turn on the image sensor to capture the original image frame containing the acquisition target; S204, the original image frame is converted to generate a real-time image preview stream of the target.

[0064] In this embodiment, the lightweight front-end's interactive interface is responsible for the stable presentation of the data collection entry point and the standardized output of trigger events. The interactive interface can be the event layer of an H5 page, the page container of an iOS lightweight application, the card page of a Harmony atomic service, or the component page of a lightweight Android shell. The meaning of operable controls is not limited to a single button; it can also be a slider, a long-press area, a floating operation bar, a camera entry icon, or a group of combined controls. Their common feature is that they have triggerable interactive event sources and bindable event handling logic. When presenting operable controls, the interface side binds control identifiers, trigger types, trigger throttling parameters, and interface state constraints to the controls. Control identifiers are used to distinguish different data collection entry points such as fire facility inspection and electrical circuit inspection. Trigger types are used to distinguish between click, double-click, long-press, and gesture triggers. Trigger throttling parameters are used to suppress repeated calls caused by high-frequency triggers. Interface state constraints are used to restrict the generation of data collection instructions when permissions are not granted or the page has not been initialized. When a collection command is generated in response to a trigger operation on an operable control, the collection command is constructed into a structured data object. This object contains at least a collection target identifier, a collection mode identifier, a preview resolution preference, a frame rate preference, and a permission request flag. The collection target identifier binds the preview range and subsequent analysis object to the same business entity. The collection mode identifier distinguishes between preview-only and preview plus photo entry. The preview resolution preference and frame rate preference provide initial constraints for determining the call parameters. The permission request flag drives the subsequent selection of underlying interfaces and the linkage of permission pop-up processes. The collection command is generated on the lightweight front-end side. The output format can be a message object in memory, an inter-process message, or a bridge message between the page and the native container. In H5, it is commonly transmitted via a bridge layer after page event serialization. In iOS lightweight applications, it is commonly a container event callback. In Harmony atomic services, it is commonly an in-service event bus message. In Android, it is commonly a component event dispatch result.

[0065] The agent receives and parses acquisition commands to convert UI-layer business triggers into a set of call parameters that can directly drive the image acquisition component. The receiving action involves the agent reading acquisition commands from the lightweight front-end's event channel and performing deduplication and sequencing. Deduplication handles command stacking caused by consecutive triggers, while sequencing establishes a defined execution sequence between permission requests, component startup, and preview configuration. The parsing action involves the agent performing field validation and semantic decoding on the fields in the acquisition commands. Field validation includes validating the acquisition target identifier, the acquisition mode identifier, and the resolution and frame rate preference ranges. Semantic decoding maps the acquisition mode identifier to the preview session type and the permission request flag to the permission check path. When determining the call parameters for the image acquisition component, these parameters can be organized into a multi-dimensional parameter set, including at least camera selection parameters, preview output format parameters, preview session configuration parameters, and callback binding parameters. Camera selection parameters determine the front or rear camera and lens group selection; on terminals with multi-camera setups, this can be further refined into wide-angle, telephoto, or main camera selection. The preview output format parameter determines the pixel format or encoding format of the raw frame output by the image acquisition component, such as YUV family format, RGB family format, or compressed frame format. The format selection is constrained by the operating system interface and hardware capabilities and is directly related to subsequent conversion processing. The preview session configuration parameter determines the preview resolution, frame rate, initial exposure mode value, initial focus mode value, and initial image stabilization mode value. The initial values ​​can be derived from the intersection of the acquisition command's preference field and the terminal capability enumeration result, or from recommended configurations cached locally in historical acquisition records. The callback binding parameter sends the raw image frame output by the image acquisition component back to the receiving end of the lightweight front-end. The callback binding can be a function callback address, a message queue channel identifier, or a shared memory handle identifier; the choice depends on the lightweight front-end's hosting configuration and the operating system's process model. Once the call parameters are determined, the agent generates the underlying call instruction. The meaning of the underlying call instruction is not limited to a single command string, but is a call request entity that can be recognized by the image acquisition component interface. It contains the interface name, the set of call parameters, the permission context identifier, and the session identifier. The permission context identifier is used to align with the Android permission model, the iOS privacy authorization model, and the Harmony capability authorization model. The session identifier is used to associate the lifecycle events of a preview session with the same session instance.

[0066] Executing low-level call instructions to start the image acquisition component and control it to activate the image sensor is manifested in submitting a call request to the media acquisition entry on the operating system side and completing the sensor's working state switch. Starting the image acquisition component means completing component instance creation, resource allocation, and session initialization. Resource allocation includes obtaining the camera device handle, allocating the preview buffer, and establishing the graphics rendering channel. Activating the image sensor means switching the sensor from standby mode to exposure sampling mode and starting to continuously output frame data. To avoid sampling jitter, the startup phase is usually accompanied by a warm-up window control. The warm-up window can be implemented by discarding the first few frames or delaying the callback, thus ensuring that the raw image frames entering the lightweight front end are in a stable exposure and white balance state. Capturing raw image frames containing the acquisition target emphasizes that the raw image frame is the continuous output unit of the preview session. The raw image frame contains a pixel matrix, timestamp, frame number, and camera intrinsic parameters or equivalent descriptive information. The timestamp and frame number are used for subsequent frame synchronization and delay evaluation, and the camera intrinsic parameters or equivalent descriptive information are used to complete coordinate mapping or distortion correction when needed. The way the target is captured into the original image frame can rely on the user's alignment of the viewfinder, or on the interface's limitation and cropping configuration of the viewfinder area. The cropping configuration is sent as part of the calling parameters, which can limit the preview output to the area of ​​interest to reduce the amount of data.

[0067] The process transforms raw image frames to generate a real-time image preview stream, converting the underlying output frame format into a lightweight, renderable, transmittable, and subsequently consumed streaming data structure for feature analysis. The transformation process includes four operations: format conversion, size transformation, orientation correction, and frame encapsulation. Format conversion converts the underlying pixel format into a texture or image buffer format directly usable by the rendering layer. In H5, this might mean mapping the original frame to a Canvas-usable pixel buffer or video texture source; in iOS lightweight applications, it might mean mapping the original frame to a Metal texture or equivalent buffer; in Harmony atomic services, it might mean mapping the frame to a system image object; and in Android, it might mean mapping the frame to a Surface texture or equivalent buffer. Size transformation scales the original frame to the interface display resolution or analysis input resolution based on the preview resolution parameters. Scaling can be proportional and retain the main area of ​​the target data. Orientation correction rotates or flips the frame based on the orientation markers output by the device's attitude sensor or camera, ensuring the preview image matches the user's holding orientation and preventing directional deviations in subsequent analysis input. Frame encapsulation binds each frame to its timestamp, frame sequence number, and session identifier to form a frame message unit. These are then organized into a continuous sequence according to the increasing frame sequence number, forming a real-time image preview stream. The output of the real-time image preview stream is located on the lightweight front-end. It can be used as rendering input to directly drive the view preview display, or as an input source for subsequent feature analysis. Therefore, the preview stream is usually output in a dual-channel distribution manner, with one channel entering the rendering pipeline and the other entering the analysis pipeline. Both channels share the same frame sequence number and session identifier to maintain consistency.

[0068] This embodiment structures the action triggered by operable controls into acquisition commands in a lightweight front-end. The agent then receives and parses the acquisition commands to determine the calling parameters of the image acquisition component. Subsequently, it generates and executes the underlying calling commands to start the image acquisition component and activate the image sensor. At the same time, it performs format conversion, size transformation, orientation correction, and frame encapsulation on the original image frames to generate a real-time image preview stream. This creates a traceable parameter link between the acquisition entry point and the underlying camera capabilities. Furthermore, it unifies the preview data output into a renderable and reusable streaming structure. This reduces preview failures and frame format mismatches caused by inconsistencies between acquisition triggers and camera calls in multi-terminal scenarios, and improves the usability and consistency of the real-time image preview stream in interface display and subsequent processing.

[0069] In one embodiment, step S30 above includes: S301, Extract the current preview frame image from the real-time image preview stream; S302, the preview frame image is subjected to noise reduction and brightness enhancement processing to obtain an enhanced preview frame; S303, extract the edge geometric contour and spatial position of the target in the enhanced preview frame, perform feature analysis on the edge geometric contour and spatial position to obtain a basic feature vector set; S304, compare the basic feature vector set with the pre-stored reference feature template to obtain the feature comparison difference; S305, based on the feature comparison difference, the set of spatial coordinates representing the preset inspection points in the acquisition target and the visual attribute parameters are used as key features, and the missing state information, position offset value and occlusion ratio corresponding to the key features are determined.

[0070] In this embodiment, the real-time image preview stream includes preview frame images arriving in a time sequence. The current preview frame image is captured to select an analysis moment from the continuous frame input. The capture trigger condition can be provided by the frame number, timestamp, or interface-side trigger event of the preview frame image. The capture process requires a fixed analysis window to avoid result drift caused by multiple captures at the same time. The analysis window can be limited to a single frame or a small frame cluster, selecting the preview frame image with higher clarity as the current preview frame image. When the preview frame image enters the denoising and brightness enhancement processing, the denoising targets random noise, compressed noise, and weak light particle noise. The processing goal is to improve the continuity and separability of edge geometric contours. The denoising operation can be implemented based on spatial domain filtering, frequency domain denoising, or block-based noise estimation. During execution, high-frequency edge information needs to be preserved to support subsequent contour extraction. Brightness enhancement addresses insufficient contrast caused by underexposure, backlighting, and localized shadows. Enhancement operations can employ local contrast stretching, segmented brightness mapping, or gain adjustment based on histogram distribution. Enhancement parameters can be driven by brightness statistics of the preview frame image, such as mean brightness, brightness variance, and highlight ratio. The enhanced output forms an enhanced preview frame, which has clearer structural boundaries and a more stable grayscale gradient distribution at the pixel level, thus providing a higher signal-to-noise ratio input for subsequent geometric information extraction.

[0071] When extracting the edge geometric contours and spatial positions of the target in the enhanced preview frame, the edge geometric contours are used to characterize the target's external shape and internal structural boundaries, while the spatial positions are used to characterize the target's location in the image coordinate system. Edge geometric contour extraction can generate edge point sets based on gradient magnitude, direction consistency, and connectivity constraints, and then form contour curves or polyline sets through edge tracking. The contour representation can be a sequence of polygon vertices, a sequence of spline control points, or a pixel-level contour mask. Spatial position extraction requires mapping the contours to the preview frame image coordinate system. The spatial position can be expressed using bounding box coordinates, center point coordinates, keypoint coordinates, or the bounding rectangle of a region mask. The spatial position can also carry scale information to reflect the target's imaging size in the image. When performing feature analysis on edge geometric contours and spatial locations to obtain a basic feature vector set, the feature analysis transforms the geometric shape and positional distribution into a vectorized expression. The basic feature vector set can contain multi-dimensional components such as contour shape description vector, contour curvature distribution vector, edge density vector, position normalization vector, and scale ratio vector. The vectorization process requires unified dimensions and normalization rules to support consistent comparison across frames and devices. Normalization can be performed based on the preview frame image resolution, view area size, or equivalent parameters of the camera intrinsics, so that comparable basic feature vector sets can still be obtained for different Android, iOS, and Harmony devices with differences in resolution and field of view.

[0072] When comparing the basic feature vector set with a pre-stored reference feature template to obtain the feature comparison difference, the reference feature template provides the standard shape and standard positional relationship of the target structure. The source of the reference feature template can be the layout of inspection points defined by business specifications, the template statistical results extracted from historical qualified samples, or the template set issued by the management terminal. Templates can be distinguished according to the collection target category and managed by version number. The comparison operation needs to map the basic feature vector set and the reference feature template to the same feature space. The mapping action can include dimension alignment, scale alignment, and coordinate system alignment. Then, the difference is calculated to form the feature comparison difference. The feature comparison difference can be a single distance metric or a multi-component difference set. The components can reflect contour shape differences, position differences, scale differences, and local structural differences, respectively. The difference output needs to retain the traceable source of the components to support the subsequent determination logic of missing state information, position offset values, and occlusion ratio.

[0073] When using the spatial coordinate set of preset checkpoints and visual attribute parameters as key features based on feature comparison differences, the spatial coordinate set of preset checkpoints is used to pinpoint the areas of interest in the target data to specific coordinates. These spatial coordinates can be coordinates of several key points, the center coordinates of a key region, or the boundary coordinates of a key region. The coordinate set corresponds one-to-one with the checkpoints in the reference feature template, enabling subsequent guidance information to point to specific locations. Visual attribute parameters are used to express attributes related to image quality and target visibility. These parameters can include sharpness measurement, contrast measurement, brightness distribution measurement, edge intensity measurement, and texture consistency measurement. The values ​​of these visual attribute parameters can be obtained from statistics and local region measurements in the enhanced preview frame, or derived from local difference components generated during the comparison process. When further determining the missing status information, positional offset values, and occlusion ratios corresponding to key features, the missing status information is used to indicate whether the preset checkpoints can be located or confirmed. Missing status can be determined based on whether the local edge response of the checkpoint reaches a threshold, whether the local texture consistency meets the conditions, or whether the local difference components exceed the allowable range. The positional offset value is used to express the degree of offset of the checkpoint relative to the reference feature template. The positional offset value can be composed of the magnitude of the difference vector between the spatial coordinate set and the template coordinate set, the directional offset, or the normalized offset ratio, while retaining the directional component to support subsequent guidance information to provide the movement direction. The occlusion ratio is used to express the degree to which the key area of ​​the acquisition target is occluded by non-target objects. The occlusion ratio can be quantified by the edge breakage ratio within the key area, the proportion of abnormal textures within the area, and the proportion of foreground occlusion mask area. The occlusion ratio and the missing state information are jointly constrained to distinguish different states such as complete missing, partial occlusion, and visible but offset, so that the key features contain not only spatial orientation information but also availability and quality information.

[0074] Through the above steps, this embodiment transforms the preview image into a measurable, locatable, and decomposable structured result, thereby improving the consistent expression of key features across different terminal resolutions and viewing conditions, and providing a directional and quantitative basis for subsequent guidance and parameter adjustment.

[0075] In one embodiment, step S40 above includes: S401, the agent generates guidance information based on the analysis results of the key features; S402, determine the display mode of the guidance information in the lightweight front end according to the operating system environment of the user terminal; S403, The guide information is displayed in the lightweight front end through the agent according to the display mode; S404, Based on the analysis results of the key features and the operating system environment, the agent generates adjustment instructions for the operating parameters of the image acquisition component; S405, execute the adjustment command to adjust the operating parameters of the image acquisition component, and obtain the adjusted operating parameters.

[0076] In this embodiment, the analysis results of key features, used as input, need to have a structured expression that can be directly consumed, enabling the agent to use the same analysis results simultaneously for guidance information generation and runtime parameter adjustment. The analysis results of key features can be organized as a combination of checkpoint identifiers, checkpoint spatial coordinates, position offset values, occlusion ratios, missing status information, and visual attribute parameters, with each item accompanied by a timestamp and preview frame identifier. This facilitates maintaining the correspondence between guidance information and the current viewfinder in the lightweight front-end's interactive interface. After receiving the analysis results of key features, the agent discriminates and branches the missing status information, position offset values, and occlusion ratios, mapping them to an executable set of guidance targets. This set of guidance targets at least includes the direction that needs to be adjusted by the user, parameters that need to be compensated by the image acquisition component, and a set of checkpoint identifiers that need to be highlighted, thus converting the analysis results into an input carrier for subsequent actions.

[0077] The generation of guidance information revolves around a set of guidance targets. The agent needs to convert the set of spatial coordinates of checkpoints into interface coordinates that can be rendered by the lightweight front-end, and convert position offset values ​​into direction vectors or displacement prompts to form directional guidance information. The generation of interface coordinates can be based on the preview frame resolution, viewfinder cropping information, and screen pixel density, and coordinate system normalization can be performed for both portrait and landscape modes to ensure that the same checkpoint corresponds to a consistent interface position on different user terminals. The content structure of the guidance information can be divided into two parts: visual guidance data and interactive guidance data. Visual guidance data is used to express rendering elements such as selected areas, indicator arrows, focus points, and color mark levels. Interactive guidance data is used to express prompt statement template identifiers, interactive confirmation entries, retake entries, and confirmation switches related to the adjustment of running parameters. The generation of prompt statements can be achieved by concatenating template identifiers with placeholder parameters. The placeholder parameters are filled with position offset values, occlusion ratios, and missing status information to form prompt statements that describe the source of the current deviation and the direction of adjustment, avoiding redundant calculation of text content on the lightweight front-end.

[0078] The determination of the display mode depends on the user terminal's operating system environment, which can include operating system type, version information, rendering capabilities, camera interface capabilities, and system-level interactive capabilities. When determining the display mode, the proxy needs to consider both the operating system environment and lightweight front-end form constraints. For example, on Android, a combination of overlay layers and local highlighting can be used to implement bounding box selection and arrow overlay; on iOS, lightweight tooltips and viewfinder border emphasis can be prioritized to reduce rendering overhead; and on Harmony, a combination of system-provided service card entry points and viewfinder linkage components can achieve more direct tooltip presentation. The display mode can consist of a mode identifier and mode parameters. The mode identifier is used to select the rendering channel, such as a bounding box overlay channel, a text tooltip channel, or an interactive overlay channel. The mode parameters are used to control the rendering level, transparency gradient, tooltip refresh rate, and animation rhythm, thus enabling the display mode to cover differences across multiple platforms while allowing for fine-grained adjustments based on version information and performance characteristics within the same platform.

[0079] Displaying guidance information in a lightweight front-end requires three actions: rendering data assembly, rendering triggering, and rendering update. The proxy assembles the visual guidance data from the guidance information into a set of rendering instructions, which includes the target layer identifier, drawing element type, interface coordinate parameters, and refresh trigger conditions. It also assembles the interactive guidance data into an interaction binding set, which includes control identifiers, event types, and callback action identifiers. Upon receiving the rendering instruction set, the lightweight front-end writes it to the interface rendering queue and triggers an interface refresh, ensuring that the selected area, direction indicators, and prompts are presented synchronously. When the real-time image preview stream refresh causes changes in the analysis results of key features, the proxy performs incremental updates to the rendering instruction set, replacing only the changed coordinate and prompt parameters to avoid stuttering caused by a full redraw. During the display, the proxy maintains consistent binding between the guidance information and the preview frame identifier, ensuring that the guidance information seen by the user corresponds to the current view rather than a historical frame, reducing misunderstandings caused by latency.

[0080] The generation of adjustment instructions and the display of guiding information for operational parameters are controlled in parallel by the analysis results of key features and the operating system environment. However, the formation of adjustment instructions requires further integration with the capability set of the image acquisition component. The capability set can include a list of adjustable parameters, parameter value ranges, parameter activation delays, and mutual exclusion relationships, such as the combination constraints of focus mode and exposure compensation, and the linkage constraints of fill light switch and shutter speed. Based on missing state information, position offset values, occlusion ratio, and visual attribute parameters, the agent determines the operational parameter items that need to be adjusted and generates target values ​​or target ranges for each operational parameter item. For example, when the sharpness is insufficient and the brightness is low, it generates adjustment instructions to enable fill light and lock focus; when the highlight ratio is too high, it generates adjustment instructions to reduce exposure compensation and adjust the metering area; and when the position offset value is continuously large and the edge geometry is unstable, it generates adjustment instructions to enhance image stabilization and optimize shutter speed. At this stage, the operating system environment is used to select executable interface paths and permission paths. For example, different systems have different open ranges for camera control interfaces. The agent needs to select different instruction expression forms such as direct parameter writing, session parameter updating, or control command triggering according to the system capability characteristics to ensure that the adjustment instructions can be received and effective by the image acquisition component.

[0081] The execution of adjustment commands requires a lightweight frontend or proxy to trigger the underlying call entry point, completing parameter writing, readback verification, and state synchronization. During execution, the proxy breaks down the adjustment commands into atomically executable command units and submits them in the order of the image acquisition component's session state. For example, session-level parameter updates are submitted first, followed by frame-level parameter updates, to avoid invalid settings caused by parameter overwriting. After receiving the command unit, the image acquisition component updates its running parameters and returns the parameter effectiveness status or a snapshot of the current parameters. The proxy confirms the adjusted running parameters based on the returned results. The adjusted running parameters can be output as a set of parameter key-value pairs and written to the lightweight frontend's session context, allowing subsequent image capture actions to use the same adjusted running parameters without relying on recalculation. If there are parameter writing failures or unsupported capabilities, the proxy records the failure as a degradation flag and converges the adjustment commands into an executable subset without changing the guidance information generation logic, ensuring the continuous progress of the running parameter adjustment chain.

[0082] This embodiment uses a proxy to transform the analysis results of key features into a set of guidance targets and generate guidance information. Then, based on the user terminal's operating system environment, it determines the display mode and performs incremental rendering on a lightweight front-end, enabling the guidance information to be stably presented in a multi-terminal environment and consistent with real-time framing. At the same time, the proxy generates adjustment instructions based on the analysis results of key features and the operating system environment and executes them to the image acquisition component, outputting the adjusted operating parameters. This makes the adjustment of operating parameters and the presentation of guidance form a common driving force and a consistent closed loop, thereby improving the executability and traceability of the adjustment of operating parameters and providing a more stable acquisition state for the subsequent acquisition of final image data.

[0083] In one embodiment, step S50 above includes: S501, according to the adjusted operating parameters, control the image acquisition component to perform an image capture operation to obtain the final image data of the acquisition target; S502, The agent loads the preset anomaly judgment benchmark information locally on the user terminal; S503, The agent performs image analysis on the final image data to extract corresponding image feature information; S504, The image feature information is compared with the anomaly judgment benchmark information through the agent to determine the anomaly judgment result; S505, the agent generates an anomaly identifier based on the anomaly judgment result, and stores the anomaly identifier as metadata associated with the final image data.

[0084] In this embodiment, the adjusted operating parameters belong to a reusable control set formed by the image acquisition component after adjusting the operating parameters. This set includes parameters that directly affect image quality, such as focus mode, exposure compensation, fill light switch, shutter speed, and ISO, as well as parameters that indirectly affect stability, such as image stabilization switch, metering area, white balance mode, resolution level, and frame rate limit. The adjusted operating parameters can be saved as a set of parameter key values ​​on the user terminal side and bound to the session identifier of the image acquisition component, making the image capture action controllable. When the image acquisition component performs image capture operations according to the adjusted operating parameters, the agent sends a capture trigger command to the image acquisition component, simultaneously attaching a write command for the adjusted operating parameters or a session update command, enabling the image acquisition component to complete parameter activation and photosensitization within the same session. The image capture operation outputs the final image data, which can be a single-frame static image file, an image binary data block, or an image data object with container header information. The generation process can include processing links such as color space conversion, distortion correction, sharpening suppression, and compression encoding. However, the start, stop, and intensity of these processing links are constrained by the adjusted operating parameters to ensure that the quality characteristics and parameter configuration of the final image data have a traceable relationship.

[0085] The execution location for anomaly detection and anomaly tagging on the user terminal is within the local storage and computing resources of the user terminal. Data can be used for detection and tagging without first transmitting it to external nodes, thereby reducing link latency and improving immediacy. The user terminal can use a controlled storage area to carry anomaly detection benchmark information. The sources of this benchmark information can include pre-defined inspection specifications from the business side, judgment thresholds accumulated from historical audit conclusions, checkpoint configurations corresponding to different collection target types, and camera capability constraints formed for different operating system environments. The content structure of the anomaly detection benchmark information can adopt a benchmark entry set, which includes anomaly type identifiers, a set of judgment thresholds, sampling window configurations, a set of checkpoint identifiers, and feature field definitions aligned with image feature information. When loading the pre-defined anomaly detection benchmark information, the agent reads the benchmark entry set from the user terminal and performs version verification. Version verification can be based on the version number of the benchmark file, the summary verification value, or the effective timestamp. The benchmark entry set is then written to the local cache and bound to the collection target identifier, ensuring consistent judgment criteria are used for the same collection target within a single collection session.

[0086] When performing image analysis on the final image data to extract image feature information, the agent needs to establish a transformation link from the image pixel domain to the structured feature domain. Image feature information can cover dimensions such as sharpness, brightness distribution, contrast, noise level, motion blur degree, occlusion area ratio, target region integrity, key region visibility, and local texture stability near checkpoints. Sharpness features can be obtained from gradient energy statistics, frequency domain energy distribution, or local Laplacian response summation; brightness distribution features can be obtained from histogram quantiles, dark area ratio, and highlight ratio; and occlusion features can be obtained from foreground region connected component statistics, color clustering segmentation, or edge breakage rate. To reduce the impact of imaging differences between different devices on feature consistency, image analysis can first perform normalization processing, including resolution unification, grayscale or color channel standardization, noise suppression, and illumination compensation. Then, region cropping can be performed on the area where the target may be located. Region cropping can be based on a set of spatial coordinates of preset checkpoints or on the location results of significant regions within the image, thereby making the image feature information more focused on the areas related to the quality judgment of the target. The output of image feature information can be a set of feature key values ​​or a set of feature vectors. The set of feature key values ​​is suitable for direct alignment with the threshold field of the anomaly determination benchmark information, while the set of feature vectors is suitable for performing multi-condition combination determination and parallel determination of multiple anomaly types.

[0087] When comparing image feature information with anomaly detection benchmark information to determine the anomaly detection result, the agent maps the image feature information item by item to the feature field definition of the benchmark entry set and executes the judgment logic according to the anomaly type identifier. The judgment logic can include single threshold judgment, interval threshold judgment, combined condition judgment, and priority judgment. Combined condition judgment can require multiple features to be satisfied simultaneously or satisfy one of them under the same anomaly type. Priority judgment is used to determine the primary anomaly type when multiple anomaly types are satisfied simultaneously. The anomaly detection result includes at least an anomaly type identifier and a judgment confidence level or judgment level. The judgment confidence level can be obtained from the number of features that meet the conditions, the magnitude of exceeding the threshold, or the consistency statistics across multiple local regions. The judgment level can be obtained from threshold segmentation or by mapping the severity of the anomaly type. The anomaly detection result can be written to the session context locally on the user terminal, so that subsequent anomaly identifier generation and associated storage can refer to the same judgment output, avoiding repeated analysis of the final image data.

[0088] When generating and storing anomaly identifiers based on anomaly assessment results, these identifiers need to have a stable structure and resolvability, enabling management terminals or subsequent processing nodes to directly understand the anomaly attributes of the final image data. Anomaly identifiers can consist of an anomaly type identifier, a judgment level, a timestamp, a data acquisition target identifier, and a parameter summary associated with the adjusted operating parameters. The parameter summary can selectively compress and encode key parameters affecting image quality, thus preserving traceable information without increasing data volume. When anomaly identifiers are stored as metadata associated with the final image data, the metadata carrier can be an extended attribute field of the final image data file, an accompanying metadata file in the same directory, or an index record in a local database. The association is established through the file identifier, hash value, or session identifier of the final image data, ensuring that the anomaly identifier remains consistently bound to the final image data during transmission, copying, or reopening. The associated storage implementation can include write verification and readback confirmation. Write verification confirms that the anomaly identifier is correctly persisted, while readback confirmation confirms that the anomaly identifier can be parsed again by the proxy and used in subsequent links.

[0089] This embodiment drives image capture and forms final image data through adjusted operating parameters, establishing a traceable relationship between the generation process of the final image data and the configuration of operating parameters. By loading anomaly judgment benchmark information locally on the user terminal and extracting image feature information to complete the comparison and judgment, the anomaly judgment result can be obtained after the image data is generated. By generating anomaly identifiers based on the anomaly judgment results and storing them in association with the final image data in the form of metadata, the final image data carries clear anomaly attributes and judgment clues, thereby reducing the reliance on manual review in subsequent processing steps and reducing the additional overhead caused by repeated acquisition or repeated judgment.

[0090] In one embodiment, step S60 above includes: S601, the final image data containing the anomaly identifier is encapsulated according to the intermediate connection protocol to generate a transmission data packet; S602, a communication link is established through the intermediate connection protocol, and the transmission data packet is sent to the management terminal; S603, receive the feedback information data packet generated by the management terminal through the intermediate connection protocol; S604, parse the feedback information data packet to obtain the returned feedback information; S605, based on the feedback information returned, update the display status of the final image data in the lightweight front end.

[0091] In this embodiment, the final image data containing the anomaly identifier is a composite object after the image content and metadata are bound together. The anomaly identifier has been associated with the final image data as metadata in the previous step. Therefore, before sending, the two need to be expressed as a single transmission entity with a unified carrying structure to avoid the management terminal receiving only the image and being unable to recover the anomaly identifier, or receiving only the anomaly identifier and being unable to locate the final image data.

[0092] When encapsulating data and generating transmission data packets according to the intermediate connection protocol, the encapsulation process needs to map the final image data and anomaly identifiers to the field structure defined by the intermediate connection protocol. The field structure can include a header, payload, and checksum. The header identifies the data packet type, protocol version, sender identifier, destination identifier, session identifier, timestamp, and fragment sequence number. The session identifier is used to merge multiple data packets generated within a single acquisition session into the same logical link. The fragment sequence number is used for segmented transmission and reassembly when the final image data is large. The payload carries the image byte stream of the final image data and the metadata segment of the anomaly identifier. The metadata segment can be in the form of a key-value set or a structured object, and at least includes an anomaly type identifier, judgment level, acquisition target identifier, and a file identifier or hash value bound to the final image data. The checksum carries the checksum, which can overwrite the header and payload, allowing the receiving end to determine whether the transmission data packet has been truncated or tampered with before parsing. Once the data packet is generated, it can be written to the sending queue and a sending task entry can be generated. The sending task entry records the session identifier, the target management terminal identifier, the maximum number of retries, and the current sending status, which facilitates subsequent link control.

[0093] When establishing a communication link via an intermediate connection protocol and sending data packets to the management terminal, the communication link can manifest as a session connection or a message channel. The establishment process requires endpoint discovery, connection parameter negotiation, and session identifier binding. Endpoint discovery can be achieved through pre-set management terminal address information, dynamically distributed management terminal identifier mapping tables, or QR code binding relationships. Connection parameter negotiation can include maximum fragment size, concurrent sending window, heartbeat cycle, and timeout threshold. After the link is established, the sending action is written to the intermediate connection protocol's sending interface at the granularity of data packets. The sending interface can synchronously return the sending acceptance result and asynchronously return the delivery status, which can cover status types such as queued, sent, delivered, and require retry. To enable the management terminal to directly locate the business object after receiving the data packets, the sending end can maintain a mapping table between the final image data and the session identifier within the same session. This mapping table is used for the association of subsequent feedback information and status updates.

[0094] When receiving feedback information data packets generated by the management terminal via the intermediate connection protocol, the receiving action needs to maintain a session identifier consistent with the aforementioned session connection or message channel to ensure that the feedback information data packets can be merged into the correct acquisition session. The feedback information data packet may contain a feedback header and a feedback payload. The feedback header at least includes the associated session identifier, the associated final image data identifier or hash value, a feedback timestamp, and a feedback type identifier. The feedback type identifier is used to distinguish different processing paths, such as approval, reshooting requests, risk review opinions, and field correction suggestions. The feedback payload may contain structured feedback information, such as review conclusions, identifiers of checkpoints requiring reshooting, descriptions of the reasons for reshooting, risk level adjustment information, management terminal remarks, and suggestions for subsequent processing actions. After receiving the feedback information data packet, the receiving end can first perform a verification segment check, then write it to the receiving queue and mark the receiving time. The receiving queue entries and the sending mapping table are bound through the session identifier and the final image data identifier, thereby supporting multiple rounds of feedback for the same final image data.

[0095] When parsing feedback information data packets to obtain the returned feedback information, the parsing process needs to extract a set of fields that can be used for business display and status progression. Parsing can select different field sets to read based on the feedback type identifier. For example, for an approved feedback type, the parsing extracts the approval conclusion and confirmation marker; for a reshoot request type, it extracts the checkpoint identifier set and the reason for the reshoot; and for a risk review type, it extracts risk level adjustment information and remarks. To avoid mismatches between feedback information and final image data, the parsing process needs to look up the corresponding final image data record in the sending mapping table using the final image data identifier or hash value. If the lookup is successful, the set of feedback fields is written into the feedback field of that record, forming a structured representation of the returned feedback information locally. If the lookup fails, the feedback information data packet can be temporarily stored in a matching queue and retrieved again using the session identifier until a match is successful or the preset retention period is reached.

[0096] When updating the display status of the final image data in the lightweight frontend based on the feedback information, the display status serves as a visual representation of the processing progress and conclusions of the final image data. The update action requires mapping the feedback information into a presentable status model. The status model can include status codes, status text, status icon identifiers, timestamps, and a set of checkpoint prompts corresponding to reshoot requirements. Status codes support frontend logic branches, such as pending review, delivered, approved, reshoot required, and review required. Status text provides a concise processing conclusion to the user terminal, and the checkpoint prompt set triggers the frontend to display guidance information when a reshoot requirement exists. The update process can first write the status model to local data storage, then drive the lightweight frontend to refresh the display layer, causing the final image data list, details page, or prompt area to present a new display status. To maintain closed-loop consistency, the display status update can be persisted along with the session identifier and the final image data identifier, ensuring that the user terminal can restore the display status when re-entering the lightweight frontend and maintaining a consistent status progression with subsequent resending or re-collection actions.

[0097] This embodiment encapsulates the final image data containing the anomaly identifier and generates a transmission data packet through an intermediate connection protocol. This allows the final image data and the anomaly identifier to enter the transmission link with a unified bearer structure, facilitating the management terminal to directly recover the anomaly attributes and location information upon receipt. By establishing a communication link, the transmission data packet is sent and feedback information data packets are received, enabling the management terminal's processing conclusions to be returned to the user terminal as associative feedback information. By parsing the feedback information data packet to obtain the returned feedback information and updating the final image data display status in the lightweight front-end, the user terminal can promptly obtain feedback from the management terminal based on the display status and trigger corresponding operations, thereby reducing redundant communication and submissions caused by cross-terminal information lag.

[0098] In one embodiment, a proxy-guided image acquisition and processing apparatus is provided, which corresponds one-to-one with the proxy-guided image acquisition and processing method described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the proxy-guided image acquisition and processing device of the present invention. The modules include a lightweight front-end construction module 10, an image acquisition scheduling module 20, a preview feature analysis module 30, a guidance and parameter control module 40, a local anomaly detection module 50, and an intermediate protocol communication module 60. Detailed descriptions of each functional module are as follows: Lightweight front-end building module 10 is used to provide a lightweight front-end that corresponds to the user terminal's operating system environment; The image acquisition scheduling module 20 is used to respond to the acquisition command triggered on the lightweight front end, and call the image acquisition component of the user terminal through the agent in the lightweight front end to obtain the real-time image preview stream of the acquisition target; The preview feature analysis module 30 is used to perform feature analysis on the real-time image preview stream to determine the key features of the acquisition target. The guidance and parameter control module 40 is used to display guidance information in the lightweight front end through the agent based on the analysis results of the key features, and to adjust the operating parameters of the image acquisition component based on the guidance information. The local anomaly detection module 50 is used to obtain the final image data of the target acquisition based on the adjusted operating parameters, perform anomaly detection on the final image data locally on the user terminal through the agent, and add an anomaly identifier to the final image data based on the anomaly detection result. The intermediate protocol communication module 60 is used to send the final image data containing the anomaly identifier to the management terminal through the intermediate connection protocol, and to receive feedback information returned by the management terminal based on the final image data.

[0099] For specific limitations regarding the proxy-guided image acquisition and processing device, please refer to the aforementioned limitations on the proxy-guided image acquisition and processing method, which will not be repeated here. Each module in the aforementioned proxy-guided image acquisition and processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0100] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements the functions or steps of a proxy-guided image acquisition and processing method on the server side.

[0101] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements the client-side functions or steps of a proxy-guided image acquisition and processing method.

[0102] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Provide a lightweight front-end that corresponds to the user terminal's operating system environment; In response to a capture command triggered on the lightweight front end, the image capture component of the user terminal is invoked through a proxy in the lightweight front end to obtain a real-time image preview stream of the capture target; Feature analysis is performed on the real-time image preview stream to determine the key features of the target being acquired; Based on the analysis results of the key features, the agent displays guidance information in the lightweight front end and adjusts the operating parameters of the image acquisition component based on the guidance information; The final image data of the target is obtained according to the adjusted operating parameters. The agent performs anomaly judgment on the final image data locally on the user terminal and adds anomaly marker to the final image data according to the anomaly judgment result. The final image data containing the anomaly identifier is sent to the management terminal via an intermediate connection protocol, and feedback information is received from the management terminal based on the final image data.

[0103] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon. When the computer program is executed by a processor, it performs the following steps: Provide a lightweight front-end that corresponds to the user terminal's operating system environment; In response to a capture command triggered on the lightweight front end, the image capture component of the user terminal is invoked through a proxy in the lightweight front end to obtain a real-time image preview stream of the capture target; Feature analysis is performed on the real-time image preview stream to determine the key features of the target being acquired; Based on the analysis results of the key features, the agent displays guidance information in the lightweight front end and adjusts the operating parameters of the image acquisition component based on the guidance information; The final image data of the target is obtained according to the adjusted operating parameters. The agent performs anomaly judgment on the final image data locally on the user terminal and adds anomaly marker to the final image data according to the anomaly judgment result. The final image data containing the anomaly identifier is sent to the management terminal via an intermediate connection protocol, and feedback information is received from the management terminal based on the final image data.

[0104] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0105] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0106] It should be noted that if any software tools or components not belonging to this company appear in the embodiments of this application, they are merely illustrative examples and do not represent actual use. The embodiments described above are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

[0107] The user personal information involved in this application embodiment is all authorized (knowing and consenting) by the relevant parties or fully authorized by all parties, and the executing entity can obtain it through various open, legal and compliant means. The collection, storage, use, processing, transmission, provision and disclosure of the information, data and signals involved all comply with the relevant laws and regulations of the relevant countries and regions, and do not violate public order and good morals.

Claims

1. An image acquisition and processing method based on proxy guidance, characterized in that, Includes the following steps: Provide a lightweight front-end that corresponds to the user terminal's operating system environment; In response to a capture command triggered on the lightweight front end, the image capture component of the user terminal is invoked through a proxy in the lightweight front end to obtain a real-time image preview stream of the capture target; Feature analysis is performed on the real-time image preview stream to determine the key features of the target being acquired; Based on the analysis results of the key features, the agent displays guidance information in the lightweight front end and adjusts the operating parameters of the image acquisition component based on the guidance information; The final image data of the target is obtained according to the adjusted operating parameters. The agent performs anomaly judgment on the final image data locally on the user terminal and adds anomaly marker to the final image data according to the anomaly judgment result. The final image data containing the anomaly identifier is sent to the management terminal via an intermediate connection protocol, and feedback information is received from the management terminal based on the final image data.

2. The image acquisition and processing method based on proxy guidance as described in claim 1, characterized in that, Provides a lightweight front-end that corresponds to the user terminal's operating system environment, including: Identify the operating system environment parameters of the user terminal, including operating system type, version information, hardware performance indicators, and specific system function support status; Determine the lightweight front-end form corresponding to the operating system environment parameters; Obtain the program code and resource configuration files that match the lightweight front-end form; Using the program code and loading the resource configuration file, a lightweight front-end is instantiated on the user terminal; Based on the hardware performance indicators and specific system function support status in the operating system environment parameters, the lightweight front-end is adapted and adjusted in terms of memory allocation and loading priority to complete the deployment of the lightweight front-end in the operating system environment.

3. The image acquisition and processing method based on proxy guidance as described in claim 1, characterized in that, In response to a capture command triggered on the lightweight front-end, the image capture component of the user terminal is invoked through a proxy in the lightweight front-end to obtain a real-time image preview stream of the target, including: The lightweight front-end interactive interface presents operable controls and generates acquisition commands in response to the triggering operation of the operable controls. The lightweight front-end receives and parses the acquisition command through a proxy to determine the calling parameters of the image acquisition component of the user terminal and generate the underlying calling command. The underlying call instruction is executed to start the image acquisition component of the user terminal, and the image acquisition component is controlled to turn on the image sensor to capture the original image frame containing the acquisition target; The original image frames are converted to generate a real-time image preview stream of the target.

4. The image acquisition and processing method based on proxy guidance as described in claim 1, characterized in that, Feature analysis is performed on the real-time image preview stream to determine the key features of the target being acquired, including: Extract the current preview frame image from the real-time image preview stream; The preview frame image is subjected to noise reduction and brightness enhancement processing to obtain an enhanced preview frame; Extract the edge geometric contour and spatial position of the target in the enhanced preview frame, perform feature analysis on the edge geometric contour and spatial position to obtain a basic feature vector set; The basic feature vector set is compared with the pre-stored reference feature template to obtain the feature comparison difference; Based on the feature comparison difference, the set of spatial coordinates representing the preset inspection points in the target acquisition and the visual attribute parameters are used as key features, and the missing state information, position offset value and occlusion ratio corresponding to the key features are determined.

5. The image acquisition and processing method based on proxy guidance as described in claim 1, characterized in that, Based on the analysis results of the key features, the agent displays guidance information in the lightweight front end, and adjusts the operating parameters of the image acquisition component based on the guidance information, including: Based on the analysis results of the key features, the agent generates guidance information. Based on the operating system environment of the user terminal, determine the display mode of the guidance information in the lightweight front end; The agent displays the guidance information in the lightweight front end according to the display mode; Based on the analysis results of the key features and the operating system environment, the agent generates adjustment instructions for the operating parameters of the image acquisition component. The adjustment command is executed to adjust the operating parameters of the image acquisition component, resulting in the adjusted operating parameters.

6. The image acquisition and processing method based on proxy guidance as described in claim 1, characterized in that, The final image data of the target is obtained according to the adjusted operating parameters. The proxy performs anomaly detection on the final image data locally on the user terminal, and adds anomaly markers to the final image data based on the anomaly detection results. This includes: Based on the adjusted operating parameters, the image acquisition component is controlled to perform an image capture operation to obtain the final image data of the acquisition target; The agent loads preset anomaly detection benchmark information locally on the user terminal. The agent performs image analysis on the final image data to extract corresponding image feature information; The image feature information is compared with the anomaly determination benchmark information through the agent to determine the anomaly determination result; The agent generates an anomaly identifier based on the anomaly judgment result, and stores the anomaly identifier as metadata associated with the final image data.

7. The image acquisition and processing method based on proxy guidance as described in claim 1, characterized in that, The final image data containing the anomaly identifier is sent to the management terminal via an intermediate connection protocol, and feedback information is received from the management terminal based on the final image data, including: The final image data containing the anomaly identifier is encapsulated according to the intermediate connection protocol to generate a transmission data packet; A communication link is established through the intermediate connection protocol, and the transmission data packets are sent to the management terminal. The system receives feedback information data packets generated by the management terminal via the intermediate connection protocol. Parse the feedback information data packet to obtain the returned feedback information; Based on the feedback information returned, update the display status of the final image data in the lightweight front-end.

8. An image acquisition and processing device based on proxy guidance, characterized in that, The agent-guided image acquisition and processing device includes: Lightweight front-end build module, used to provide a lightweight front-end that corresponds to the user terminal's operating system environment; The image acquisition scheduling module is used to respond to the acquisition command triggered on the lightweight front end, and call the image acquisition component of the user terminal through the agent in the lightweight front end to obtain the real-time image preview stream of the acquisition target; The preview feature analysis module is used to perform feature analysis on the real-time image preview stream to determine the key features of the acquisition target. The guidance and parameter control module is used to display guidance information in the lightweight front end through the agent based on the analysis results of the key features, and to adjust the operating parameters of the image acquisition component based on the guidance information. The local anomaly detection module is used to obtain the final image data of the target acquisition based on the adjusted operating parameters, perform anomaly detection on the final image data locally on the user terminal through the agent, and add anomaly identifier to the final image data according to the anomaly detection result. The intermediate protocol communication module is used to send the final image data containing the anomaly identifier to the management terminal through the intermediate connection protocol, and to receive feedback information returned by the management terminal based on the final image data.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a proxy-guided image acquisition and processing program stored in the memory and executable on the processor. When executed by the processor, the proxy-guided image acquisition and processing program implements the steps of the proxy-guided image acquisition and processing method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a proxy-guided image acquisition and processing program, which, when executed by a processor, implements the steps of the proxy-guided image acquisition and processing method as described in any one of claims 1-7.

Images