Image output method, computer device and readable storage medium

Abstract

The application relates to an image output method, a computer device and a readable storage medium. The method comprises the following steps: receiving an image processing request sent by a device end, performing image processing based on the image processing request, storing an image result in an image result address, sending the image result address to the device end, checking an image output confirmation instruction corresponding to the image result address when the image output confirmation instruction is received, processing the image result into a target image operable by the device end according to corresponding image format processing rules when the image output confirmation instruction is checked, sending the target image to the device end, enabling the device end to perform integrity checking on the target image, and outputting the target image when the checking is passed. The method can enable the device end to reliably output a cloud end image processing result.

Description

Technical Field

[0001] This application relates to the field of image processing technology, and in particular to an image output method, a computer device, and a computer-readable storage medium. Background Technology

[0002] The demand for image output from smart terminals continues to grow, covering various application scenarios such as display and printing. Traditionally, clients communicate with print servers via WebSockets to send print control commands, enabling remote printing from multiple clients. In edge-cloud collaborative scenarios, the cloud, after completing image processing, directly sends the image results to the device, or the device retrieves the image results and executes the output. However, the device may not be able to directly print or display the image results sent from the cloud, leading to output failures or output content that does not meet user requirements. Summary of the Invention

[0003] Therefore, it is necessary to provide an image output method, computer device, and readable storage medium that enable the device to reliably output image results, addressing the aforementioned technical problems.

[0004] In a first aspect, embodiments of this application provide an image output method applied in the cloud, comprising: receiving an image processing request sent by a device; performing image processing based on the image processing request; storing the image result at an image result address; sending the image result address to the device; when receiving an image output confirmation instruction from the device for the image result corresponding to the image result address; verifying the image output confirmation instruction; after the image output confirmation instruction passes verification, processing the image result into a target image operable by the device according to corresponding image format processing rules; sending the target image to the device so that the device performs integrity verification on the target image, and outputting the target image after the verification passes.

[0005] Secondly, embodiments of this application also provide a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in any one of the first aspects above.

[0006] Thirdly, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of the first aspects above.

[0007] In the above image output method, the cloud processes the image result into a target image operable by the device according to the corresponding image format processing rules and then sends it to the device. The device performs integrity verification on the target image and outputs it after the verification is successful. Since the target image is generated by the cloud according to the image format processing rules corresponding to the device, the device does not need to perform image format conversion itself. Therefore, it can adapt to devices with limited computing power and storage resources, avoiding the inability to output due to excessive image data volume or format mismatch. Since the cloud only processes and sends the image after receiving the image output confirmation instruction from the device and verifying it, it can avoid invalid output without confirmation. Since the device performs integrity verification on the target image before output, it can avoid outputting incorrect images due to data loss, truncation, or damage, thereby improving the reliability and stability of image output. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is an application environment diagram of the image output method in one embodiment; Figure 2 This is a flowchart illustrating an image output method in one embodiment; Figure 3 This is a schematic diagram of the module corresponding to the image output method in one embodiment; Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0010] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0011] In some embodiments, such as Figure 1The diagram illustrates an application environment for an image output method in one embodiment. The image output method provided in this application is applied to a system including a device and a cloud. The device (also referred to as a terminal) can be a smart companion terminal or other terminal with limited computing and storage resources, and may have a built-in printing module and / or display module for displaying, confirming, and outputting image results. The cloud is used to perform image processing, parameter decision-making, format conversion, and distribution. Communication between the device and the cloud can be established via a long connection (e.g., a WebSocket connection). The device and cloud are connected via a network; the device can initiate an image processing request to the cloud and receive the image result address returned by the cloud; the cloud can perform image processing and distribute a target image operable by the device to the device.

[0012] In some embodiments, such as Figure 1 The diagram shown illustrates the application environment of an embodiment of this application. The device and the cloud are connected via a network. The device can initiate an image processing request to the cloud and receive the image result address returned by the cloud. The cloud can perform image processing and send a target image that can be operated by the device to the device.

[0013] In some embodiments, such as Figure 2 As shown, an image output method is provided for cloud application, including the following steps: Step 202: Receive the image processing request sent by the device, perform image processing based on the image processing request, and store the image result at the image result address.

[0014] Image processing requests are sent from the device to the cloud and include image editing requests and image generation requests. An image editing request is a business request that uses an existing original image as a base to perform local modifications such as adjustments, transformations, redrawing, and color corrections. This request may include the address of the original image. An image generation request is a business request from the cloud to generate entirely new image resources from scratch based on original materials such as text and feature instructions. The image result is the result obtained by the cloud after performing corresponding image processing on the original image. The original image can be uploaded by the device or stored at a specified address on the device. The image result address is used to identify and access the image result; the cloud stores the processed image result at this address for subsequent retrieval.

[0015] Specifically, the cloud receives image processing requests for the original image sent by the receiving device, processes the original image based on the image processing requests, and stores the processed image result at the image result address.

[0016] Step 204: Send the image result address to the device. When the device receives the image output confirmation instruction for the image result corresponding to the image result address, verify the image output confirmation instruction.

[0017] The image output confirmation command is used to initiate image format processing and image delivery in the cloud, and is a trigger message that initiates subsequent image processing tasks in the cloud. After receiving the image result address, the device opens the address and displays the corresponding image result. After the user confirms the image result, the device generates an image output confirmation command and sends it to the cloud. The image output confirmation command carries the device identifier, the image result address, and the parameters reported by the device this time. The device identifier is used to uniquely identify the device; the cloud relies on this identifier to identify the device, read the device's bound service configuration, and distinguish between concurrent tasks from multiple devices.

[0018] Specifically, the cloud sends the image result address to the device. The device opens the image result address and displays the image result corresponding to the address. The device generates an image output confirmation command for the image result, and the cloud verifies this command. Verification may include: verifying the device's registration status and operating permissions; verifying the legality and resource accessibility of the image result address; and verifying the validity of the value ranges of the parameters reported by the device. After successful verification, the cloud obtains (e.g., downloads) the image result corresponding to the image result address for subsequent processing.

[0019] Step 206: After the image output confirmation command passes the verification, the image result is processed into a target image that can be operated on the device according to the corresponding image format processing rules.

[0020] The image format processing rules are a set of image format processing rules specific to the device to which the current image output confirmation command belongs and the parameters reported by the device. These rules may include processing rules for the target image's width, height, color mode, whether it is segmented, and the size of each segment. A device-operable target image refers to standardized image data that can be directly called by the device to execute output tasks, including but not limited to image data that can be displayed and image data that meets print output requirements.

[0021] Specifically, once the image output confirmation command passes verification, the cloud processes the image result into a target image that can be operated on the device according to the image format processing rules corresponding to the image output confirmation command.

[0022] Step 208: Send the target image to the device so that the device can perform integrity verification on the target image and output the target image after the verification is successful.

[0023] Integrity verification is used to check whether the received image data is complete and whether there is packet loss, truncation, transmission distortion, or tampering. It is used to determine whether the image data can be parsed, rendered, or output normally. Output includes display output and print output.

[0024] Specifically, the cloud sends the target image to the device, which then performs an integrity check on the image. If the integrity check passes, the target image is considered complete and without any missing parts, and the device can then display or print it. If the integrity check fails, the device discards the image output and reports the abnormal status to the cloud.

[0025] In this embodiment, the cloud receives and processes image processing requests from the device. After receiving and verifying the image output confirmation instruction from the device corresponding to the image result address, the cloud processes the image result into a target image operable by the device according to the corresponding image format processing rules and sends it to the device. The device then performs integrity verification on the target image before outputting it. Since the target image is generated by the cloud according to the image format processing rules corresponding to the device, the device does not need to perform image format conversion itself. Therefore, it can adapt to devices with limited computing power and storage resources, avoiding output failure due to excessive image data volume or format mismatch. Since the image output confirmation instruction is used as the trigger condition for processing and sending, invalid output without confirmation can be avoided. Since the device performs integrity verification before output, it can avoid outputting incorrect images due to data loss, truncation, or damage. This enables a closed-loop state of the image output link and verifiable results, improving the reliability and stability of image output.

[0026] In some embodiments, the image output confirmation instruction includes the parameters reported by the device this time. The image result is processed into a target image operable on the device side according to the corresponding image format processing rules, including: determining the target image parameters according to the hierarchical priority rules of the parameters reported by the device this time, the device model background configuration parameters, and the system default parameters; and scaling the image result proportionally using the target image parameters as boundaries to obtain a target image operable on the device side.

[0027] The parameters reported by the device in this instance refer to the output parameters reported by the device in real time, which are only effective for the current image output task and are used by the cloud to determine the specifications of the current output. The parameters reported by the device in this instance can be carried in the image output confirmation command in the form of tiled fields or nested objects.

[0028] Device model background configuration parameters are general output parameters preset by the cloud backend for the corresponding device model or product line. These are long-term fixed configurations for the device and are activated when no custom reporting parameters are available for this task; their priority is second only to the previous parameter set. System default parameters are fallback parameters built into the cloud program. They are automatically activated when neither the device's current reporting parameters nor the device model's background configuration parameters are found; their priority is the lowest. The hierarchical priority rules are used to determine the final image output specification parameters. Target image parameters are used to limit the specifications of the output image, such as output width and output height.

[0029] Specifically, the cloud makes decisions for each parameter individually, rather than requiring the device to report all parameters at once. The priority is as follows: first, the parameters requested by the device in this request; second, the parameters configured by the backend for this device model or product line; and third, the default code values. Parameters include maximum width, maximum height, whether to split into packets, and maximum bytes per packet. Color support, compression formats, and validation algorithms can be added later. The following example illustrates the process of determining target image parameters according to the hierarchical priority rules: If the device reports a maximum width of 200 but not a maximum height, the cloud first uses a width of 200. For the height, it checks the backend configuration. If the backend configures a height of 160, then 160 is used; otherwise, the default height is used. If the device reports a single packet size of 20 (chunkSize=20), which is lower than the minimum allowed value, this item is considered invalid, and the system reverts to the backend configuration or default value. This ensures compatibility as device capabilities are gradually upgraded.

[0030] During scaling, the original image's aspect ratio is maintained. The width and height scaling ratios are calculated, and the smaller ratio is used as the actual scaling ratio, ensuring the scaled image does not exceed the target area. Optionally, when the original image ratio differs from the target area ratio, proportional scaling with white space or centering is preferred to avoid cropping that could result in missing main content.

[0031] In this embodiment, the target image parameters are determined item by item according to the hierarchical priority rules of the parameters reported by the device, the device model background configuration parameters, and the system default parameters. When a parameter is missing or invalid, it automatically falls back to the next lower level parameter as a fallback. Therefore, the output link can be kept available even when the device capabilities are gradually upgraded or the parameters are incomplete, and the output failure is avoided due to the missing or invalid of a single parameter. Since the image result is scaled proportionally with the target image parameters as the boundary, the output image can meet the requirements of the device, avoid image distortion, and improve the stability of image output in scenarios with uncertain parameters.

[0032] In some embodiments, scaling the image result proportionally with the target image parameters as boundaries to obtain a target image operable on the device side includes: scaling the image result proportionally and converting it into a binary bitmap adapted to the device side to obtain a target image operable on the device side.

[0033] Binary bitmaps are bitmap images that use only two pixel values ​​(pixel binarization), representing the state of a single pixel with just 1 bit. The resulting image can be in a standardized image format, such as standard JPEG (Joint Photographic Experts Group) or an in-memory RGB (Red, Green, Blue) image. Specifically, the image is first downloaded to the cloud and converted to a standardized image format, then scaled proportionally. After scaling, the color image can be converted to grayscale, and then the pixels are converted to black and white points based on a pixel threshold to obtain a printable or displayable binary bitmap adapted for the device. For higher quality results, error diffusion or dithering algorithms can be added to make the grayscale levels more natural in monochrome output. The final binary format includes the header width and height and the pixel bit data scanned line by line.

[0034] In this embodiment, since the image result is scaled proportionally and converted into a binary bitmap using only two pixel values, the cloud image processing result can be converted into an image format that is compatible with low-power devices that only support monochrome output, without the need for image processing on the device side. Since grayscale conversion, threshold binarization, and optional error diffusion or dithering are used in the conversion process, the grayscale level of the image can be well maintained under monochrome output, so that the cloud image processing result can be directly output by the resource-constrained device side.

[0035] In some embodiments, scaling the image result proportionally with the target image parameters as boundaries to obtain a target image operable on the device side includes: scaling the processed image proportionally with the target image parameters as boundaries to obtain a proportionally scaled image; when the total number of bytes in the proportionally scaled image is greater than the maximum number of bytes in a single packet, performing packet processing on the scaled image to obtain a packetized image frame operable on the device side; and the device side performs integrity verification on the packetized image frame.

[0036] The processed image refers to the image data obtained by processing according to image format processing rules, i.e., the image data corresponding to the target image. The maximum number of bytes per packet indicates the maximum number of bytes transmitted in a single transmission; its value is related to the device's receive buffer size, link transmission capacity, and processing speed. Packet segmentation conditions are as follows: when the device declares support for packet segmentation, and the total number of bytes in the converted binary data is greater than the maximum number of bytes per packet, the cloud performs packet segmentation; if the device does not enable packet segmentation, or the total number of bytes does not exceed the maximum number of bytes per packet, it is sent as a single frame. The packet size prioritizes the device's current parameters, followed by the background configuration, and finally the default value. The segmented image frames are arranged sequentially. Except for the last frame, the number of bytes in each segmented image frame does not exceed the maximum number of bytes per packet, although the number of bytes in the last frame can be less than the maximum number of bytes per packet. The device accumulates and reassembles the segmented image frames in the receiving order for integrity verification.

[0037] In one specific embodiment, a smart companion terminal supports monochrome printing. The device reports a maximum width of 240 pixels, a maximum height of 160 pixels, supports packet splitting, and a maximum single packet size of 1024 bytes. The user generates a 960×1280 image and confirms printing. After downloading the image from the cloud, it is scaled proportionally to the target area of ​​240×160. Since the original image ratio is 3:4 and the target area ratio is 3:2, the cloud scales the image with a height limit of 160 pixels, resulting in an actual width of approximately 120 pixels and a height of 160 pixels, with a centered margin within the 240×160 area. If a 1bpp (1 bit per pixel) bitmap is ultimately generated from the 240×160 area, the number of bytes per row is (240+7) / / 8=30 bytes, the image body is 30×160=4800 bytes, and the total size after adding a 6-byte header is 4806 bytes. Since the maximum single packet size is 1024 bytes, 5 binary frames are required.

[0038] In this embodiment, since the image data is packetized when the total number of bytes of the proportionally scaled image exceeds the maximum number of bytes in a single packet, large-volume bitmap data can be transmitted in blocks. This ensures that the amount of data transmitted each time matches the receiving buffer and processing capacity of the device, avoiding the inability of the device to receive data due to excessively large data volume in a single transmission. Furthermore, since the device performs integrity verification on the packetized image frames, it can ensure that the image after reassembling multiple frames is complete and correct, enabling resource-constrained device terminals to reliably receive large-volume image data.

[0039] In some embodiments, the packetized image frame includes start metadata of the total number of bytes and the number of packets; the device-side integrity verification of the target image includes: Verify whether the cumulative number of bytes received for the target image is equal to the total number of bytes in the initial metadata; When the initial metadata contains the overall checksum, the checksum for the target image is recalculated, and the overall checksum is compared with the recalculated checksum. Parse the target image parameters and verify whether the image parameters conform to the format.

[0040] The start metadata declares the specifications of this binary data transmission to the device and serves as the basis for the device to perform integrity checks. The start metadata includes the total number of bytes and the number of packets, and may also include image width, height, whether it is segmented, packet size, data format, and an optional overall checksum. The overall checksum verifies the correctness of the data content and can be CRC (Cyclic Redundancy Check), MD5 (Message Digest Algorithm 5), or other checksums. Integrity check fields may include the total number of frames, total number of bytes, status code, or version number, used to confirm whether the output can be used by the device or downstream modules. Binary frames are sent sequentially. In the basic scheme, the frames themselves do not contain additional sequence numbers; the device accumulates them according to the order of receipt. In the enhanced scheme, a sequence number header can be added before each packet to support out-of-order checks. The end message indicates that the binary data transmission is complete; upon receiving it, the device compares the total number of bytes with the checksum.

[0041] Specifically, the device first checks whether the cumulative number of received bytes equals the total number of bytes in the initial metadata to detect packet loss or truncation; then it checks whether the actual number of received packets equals the number of packets in the initial metadata to detect missing or extra frames; if the initial metadata contains a complete checksum, the device recalculates the checksum for all binary data and compares it with the complete checksum in the initial metadata to detect data corruption or tampering; finally, it parses the target image parameters to confirm that the image parameters conform to the format, such as parsing the header width and height information and image volume data to confirm that the length conforms to the format formula. Only after all the above checks pass can the device determine that the target image is complete and usable.

[0042] Following the aforementioned embodiment, the cloud first sends initial metadata containing width=240, height=160, totalSize=4806 bytes, chunkSize=1024 bytes, and chunkCount=5 bytes, then sends 5 binary frames, and finally sends an end message. The device receives a total of 4806 bytes, verifies them, and prints the result.

[0043] In this embodiment, since the total number of bytes, the number of packets, and an optional overall checksum are carried in the initial metadata, and the device compares each item according to the cumulative number of received bytes, the number of packets, and the checksum, it is possible to detect packet loss, truncation, distortion, or tampering during transmission, ensuring that the data on which the device outputs is based is complete and correct, and making the output results verifiable. Since the enhancement scheme can add a sequence number header before each packet, it can support out-of-order verification, further improving transmission reliability.

[0044] In some embodiments, the image output confirmation command includes a device identifier, an image result address, and parameters reported by the device this time; verifying the image output confirmation command includes: Verify the device registration status and operation permissions corresponding to the device identifier; Verify the validity and resource accessibility of the image result address; Verify the validity of the value range of the parameters reported by each device this time.

[0045] The system comprises the following components: Device Identifier (for uniquely identifying the device), Image Result Address (for identifying the image result to be output), and Device Reported Parameters (for defining the output specifications). Verifying the device registration status and operating permissions corresponding to the device identifier involves determining whether the device is registered in the cloud and has the authority to initiate image output requests, thus preventing unregistered or unauthorized devices from using cloud resources to initiate output requests. Verifying the legality and resource accessibility of the Image Result Address involves verifying the validity of the protocol, host, path, and other formats of the Image Result Address, as well as whether the corresponding resources can be accessed (e.g., whether they are downloadable or require authentication), ensuring the cloud can obtain the image result to be output. Verifying the validity of the value range of each device reported parameter involves determining whether the values ​​of each parameter are within preset ranges, such as whether the maximum width and maximum height are positive and do not exceed the upper limit, whether the packet enabling status is a valid enumerated value, and whether the maximum number of bytes per packet is not less than the minimum allowed value. Parameters exceeding these ranges are considered illegal and are either rolled back or rejected.

[0046] Optionally, as a specific implementation of the parameters reported by the device this time, the confirmation request may include the following fields: body represents the business instruction, which is fixed as image result confirmation; userId or deviceId represents the unique identifier of the device; downloadUrl represents the address of the result image to be converted and printed; data represents the image editing prompt or remarks information for this time, which is only used for log investigation; imageBinWidth represents the maximum width for this print; imageBinHeight represents the maximum height for this print; imageBinChunkEnabled represents whether binary packet splitting is enabled; imageBinChunkSize represents the maximum number of bytes per binary frame. Alternatively, nested objects of imageBinOptions can be used to centrally express device capabilities, such as width, height, packet splitting enable (chunkEnabled), and single packet size (chunkSize). The system should be compatible with both tiled fields and nested fields, but in the event of a conflict in the same field, the device parameters explicitly declared in this request shall take precedence.

[0047] In this embodiment, since the cloud verifies the registration status and operation permissions corresponding to the device identifier, the legality and accessibility of the image result address, and the value range of the parameters reported by the device this time, it can exclude unregistered devices, invalid addresses, and illegal parameters before the image output process starts, thus avoiding invalid or illegal output requests from occupying cloud processing resources and ensuring the security of the output link and the effectiveness of resource utilization. Since it is compatible with flat fields and nested fields, it can adapt to scenarios where the capabilities of the device end are gradually upgraded.

[0048] In some embodiments, the method further includes: The receiving device sends a verification failure message and the reason for the failure when the integrity verification fails; Determine whether to allow retry based on the failure type corresponding to the failure reason, and resend the target image if retry is allowed; If an error is detected during the download, conversion, or sending process, an error message is sent to the device so that the device can clear its cache and prompt the user to regenerate or retry.

[0049] Reasons for verification failure include insufficient byte count, inconsistent checksums, and header errors. When verification fails on the device side, the device discards the temporary data, ends the receiving process, and reports the failure reason to the cloud. The cloud determines the corresponding failure type based on the failure reason and decides whether to allow retry based on the failure type. For example, transmission failures such as insufficient byte count or incorrect packet count can be considered recoverable failures and allowed for retry; data failures such as inconsistent checksums or header errors have limited retry value and can be considered unrecoverable failures. For failures that allow retry, the cloud retransmits the target image; the number of retries and the retry interval can be controlled by configuration, for example, the retry interval can be set to seconds to minutes to avoid repeated triggering or frequent requests. If the cloud detects an anomaly during download, conversion, or transmission, the cloud sends an error message to the device. Upon receiving the error message, the device clears its cache and prompts the user to regenerate or retry to prevent the device from continuing to output based on incomplete data.

[0050] In this embodiment, since the device reports the reason for the failure when the verification fails, the cloud determines whether to allow a retry based on the failure type. Therefore, it can automatically retry recoverable transmission errors and terminate and prompt the user in a timely manner for unrecoverable errors, thus avoiding invalid repeated transmissions. Since the device clears the cache after receiving the error message, it can avoid residual data occupying storage resources or affecting subsequent output tasks, thereby improving the stability of image output in long-term operation scenarios.

[0051] In some embodiments, the method further includes: Receive historical data requests sent by the receiving device. The historical data requests include device identifier, user identifier, and request parameters. Based on historical data requests, read the corresponding business configuration and historical status of the device. If parameters are missing or the status is abnormal, the system will proceed to the default parameter rollback or error response path. After the default parameter rollback or error response path is processed, the result is sent to the device and the status and logs are recorded synchronously for subsequent sessions or operation and maintenance backend review.

[0052] Historical data requests are used by the device to request processing based on historical information from the cloud. These requests include device identifiers, user identifiers, and request parameters. Business configurations are pre-configured business rules corresponding to devices or users in the cloud; historical states are historical state information recorded in the cloud corresponding to devices, users, or sessions. The device can send requests to the cloud via a persistent connection. The cloud parses the device identifier, user identifier, and request parameters, then reads the corresponding business configuration and historical state, thus reusing the historical context in the current processing and avoiding duplicate reporting of historical information by the device. When parameters are missing or the state is abnormal, the cloud enters a default parameter rollback or error response path. After processing through this path, the cloud sends the result to the device and synchronously records the state and logs for subsequent sessions or operation and maintenance backend review, thereby achieving multi-node state synchronization.

[0053] In one embodiment, the current session or current request context C, current business state S, output result R, time threshold or duration T, and quality or integrity verification result Q can be defined. When context C, state S, and quality verification Q simultaneously meet preset conditions, the system outputs result R; otherwise, it enters a rollback, waiting, or cleanup path. This relationship can be manifested in specific implementations as version comparison, fragment integrity verification, silent duration judgment, voiceprint sample validity judgment, or rights limit judgment. The state expiration time is determined by the business configuration to avoid long-term unfinished states occupying resources.

[0054] In this embodiment, since the cloud reads and reuses business configurations and historical states based on historical data requests, and synchronously records the state and logs after processing, it can maintain state consistency in multi-session, multi-device, and multi-user scenarios, reduce state crosstalk, and enable key outputs to be stably reused by the device or subsequent sessions; since it enters the default parameter rollback or error return path when parameters are missing or the state is abnormal, it can ensure the availability of the link; since the state and logs can be reviewed by subsequent sessions or the operation and maintenance backend, it can achieve full-process traceability.

[0055] In some embodiments, the image output method provided in this application is described in general using a smart companion terminal as a specific business scenario on the device side. The smart companion terminal sends an image generation or image editing request to the cloud via a long connection. After the cloud completes asynchronous image processing, it returns the image result address to the smart companion terminal. The smart companion terminal displays the image result. After user confirmation, the smart companion terminal sends an image editing result confirmation instruction to the cloud, carrying the device ID (Identifier), the result image URL (Uniform Resource Locator), and the current printing capability parameters. After receiving the confirmation instruction, the cloud downloads the result image and verifies the validity of the image URL, device ID, and parameters. The cloud determines the final output width, height, whether to split the image, and the size of each split according to the rule of "device parameters first, backend configuration second, and default code values ​​as a fallback." It standardizes the image to a processable format, scales it proportionally to the target size, and converts it into a monochrome binary bitmap that the device can print or display. The cloud first sends start metadata, then sends one or more binary frames, and finally sends an end message. After receiving binary data, the smart companion terminal verifies the integrity of the data based on the total number of bytes, number of packets, and image width and height in the initial metadata. If the verification is successful, it will print or display the data.

[0056] like Figure 3 The diagram shown is a schematic representation of the modules corresponding to the image output method in one embodiment. In the overall process described above, Figure 3The cloud platform utilizes a multi-tiered system, comprising an image result confirmation module, a device capability analysis module, an image standardization module, a monochrome bitmap conversion module, a packet metadata module, and a binary frame transmission module, to collaboratively complete each processing stage. State tracking is achieved through state storage and logs. Specifically, the image result confirmation module handles image result confirmation and transmits the results to downstream modules and the smart companion terminal. Its core function is not to perform isolated interface calls, but to provide reusable states for subsequent judgments, outputs, or write-backs. Similarly, the device capability analysis module handles device capability analysis and transmits the results to downstream modules. The image standardization module handles image standardization and transmits the results to downstream modules. The monochrome bitmap conversion module handles monochrome bitmap conversion and transmits the results to downstream modules. Its core function is not to perform isolated interface calls, but to provide reusable states for subsequent judgments, outputs, or write-backs. The packet metadata module handles packet metadata processing and passes the results to downstream modules. Its core function is not to perform isolated interface calls, but to provide reusable states for subsequent judgments, outputs, or write-backs. The binary frame sending module handles binary frame sending processing and passes the results to downstream modules. Its core function is not to perform isolated interface calls, but to provide reusable states for subsequent judgments, outputs, or write-backs. These modules form a multi-module state closed loop: every input, judgment, output, and write-back is traceable. After processing, the cloud sends the results to the smart companion terminal and synchronously records the status and logs for subsequent sessions or maintenance backend review, implementing rollback, verification, and write-back mechanisms.

[0057] In the overall process described above, the cloud organizes multiple previously dispersed processing steps into a traceable, rollback-friendly, and scalable technical closed loop. Specifically, this includes: First, establishing clear state sources and update rules, i.e., clearly defining state sources such as device identifiers, user identifiers, session identifiers, request parameters, and business configurations, and specifying the update timing of each state in each processing step; Second, reducing false triggers, duplicate triggers, or state crosstalk in the real-time link, i.e., setting cooldown or timeout periods for confirmation commands, and setting expiration times for processing states that have not been completed for a long time to avoid duplicate triggers or state residue; Third, enabling key outputs to be stably reused by the device or subsequent sessions, i.e., writing key outputs such as image results, target image parameters, and verification results into state storage or logs for reuse by subsequent sessions or the device; Fourth, forming a modular implementation scheme that can be jointly executed by the server, terminal, and management backend, i.e., the cloud is responsible for image processing, parameter decision-making, format conversion, and distribution; the device is responsible for confirmation, receiving verification, and output; and the management backend is responsible for parameter configuration, state query, and log review.

[0058] In this embodiment, by combining the specific business scenarios of the intelligent companion terminal with multi-module state closed-loop, rollback / verification / writeback mechanisms, and establishing clear state sources and state update rules, reducing false triggering / repeated triggering / state crosstalk, enabling stable reuse of key outputs, and forming a modular implementation scheme, the inconsistency of states and repeated triggering problems in real-time interaction scenarios can be reduced, and the stability of intelligent companion devices in multi-user, multi-device, long-connection, and asynchronous task scenarios can be improved. Compared with solutions that only perform single interface calls, this embodiment places greater emphasis on state closed-loop, parameter rollback, and verifiable results. Each processing step can be implemented by explicit steps in the server, terminal, or management backend, thereby improving the stability of real-time interaction, personalization accuracy, and long-term operational reliability.

[0059] In some embodiments, the cloud records status in layers according to device, user, session, or business dimensions; each processing module writes the processing results to the status storage for subsequent judgment, output, or write-back reuse, avoiding duplicate calculations and status crosstalk. For example, device status records the device's registration status, capability parameters, and output records; user status records the user's preferences and historical operations; and session status records the request parameters and processing progress of the current session. When subsequent sessions or device-side processing occur, the status of the corresponding dimension can be directly read without re-reporting or repeated processing.

[0060] In some embodiments, the cloud sets cooldown and timeout periods for image output-related processes. The cooldown period prevents the same device or user from repeatedly triggering image output confirmation commands or retry requests within a short period, while the timeout period clears up processing states that have been incomplete for extended periods. The state expiration time is determined by the service configuration to avoid long-term incomplete states consuming resources. Through this time control mechanism, false triggering and repeated triggering can be reduced in real-time processes, minimizing unnecessary cloud processing overhead.

[0061] In some embodiments, the various processing steps involved in the image output method are executed by at least one of the cloud, the device, or the management backend. The cloud is used to perform image processing, parameter decision-making, format conversion, and distribution; the device is used to perform image result confirmation, data reception, integrity verification, and output; and the management backend is used to configure device model backend configuration parameters, view status and logs, and perform operation and maintenance review. Each input, judgment, output, and write-back is recorded in the status or log, achieving full-process traceability.

[0062] In some embodiments, an image output device is also provided, applied in the cloud. The device includes: a request processing module, configured to receive an image processing request sent by a device, perform image processing based on the image processing request, and store the image result at an image result address; a confirmation instruction verification module, configured to send the image result address to the device and verify the image output confirmation instruction received from the device for the image result corresponding to the image result address; an image conversion module, configured to process the image result into a target image operable by the device according to the corresponding image format processing rules after the image output confirmation instruction verification is passed; and an image delivery module, configured to send the target image to the device so that the device can perform integrity verification on the target image and output the target image after the verification is passed.

[0063] In some embodiments, the image conversion module includes: a parameter decision unit, used to determine the target image parameters according to the hierarchical priority rules of the parameters reported by the device this time, the device model background configuration parameters, and the system default parameters; and a scaling unit, used to scale the image result proportionally with the target image parameters as the boundary to obtain a target image operable on the device.

[0064] In some embodiments, the image conversion module further includes a bitmap conversion unit, used to scale the image result proportionally and convert it into a binary bitmap adapted to the device, thereby obtaining a target image operable on the device.

[0065] In some embodiments, the image conversion module further includes: a packet processing unit, configured to perform proportional scaling on the processed image with the target image parameters as the boundary to obtain a proportionally scaled image, and to perform packet processing on the scaled image when the total number of bytes of the proportionally scaled image is greater than the maximum number of bytes in a single packet, so as to obtain a packetized image frame operable by the device side, for the device side to perform integrity verification on the packetized image frame.

[0066] In some embodiments, the image delivery module is further configured to send start metadata containing the total number of bytes and the number of packets to the device, so that the device can perform integrity verification on the target image based on the start metadata; the integrity verification includes: verifying whether the cumulative number of bytes received for the target image is equal to the total number of bytes in the start metadata; when the start metadata contains an overall check value, recalculating the check value for the target image and comparing the overall check value with the recalculated check value; parsing the target image parameters of the target image and verifying whether the image parameters conform to the format.

[0067] In some embodiments, the confirmation instruction verification module includes: a registration permission verification unit, used to verify the device registration status and operation permissions corresponding to the device identifier; an address verification unit, used to verify the legality and resource accessibility of the image result address; and a parameter verification unit, used to verify the validity of the value range of each parameter reported by the device this time.

[0068] In some embodiments, the apparatus further includes: an exception handling module, configured to receive a verification failure message and a failure reason sent by the device when the integrity verification fails, determine whether to allow retry based on the failure type corresponding to the failure reason, and resend the target image when retry is allowed; and, when an exception is found during download, conversion or transmission, send an error message to the device to enable the device to clear the cache and prompt the user to regenerate or retry.

[0069] In some embodiments, the device further includes: a status synchronization module, configured to receive historical data requests sent by the device, read the service configuration and historical status corresponding to the device according to the historical data requests; enter the default parameter rollback or error response path when parameters are missing or the status is abnormal, and send the result to the device after the default parameter rollback or error response path is processed, and synchronously record the status and logs for subsequent sessions or operation and maintenance backend review.

[0070] Each module in the aforementioned image output device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, 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.

[0071] In this embodiment, since the modules in each of the above device embodiments execute the steps in the corresponding method embodiments, the same technical effect as the corresponding method embodiments can be achieved.

[0072] In some embodiments, a computer device is provided, which may be a server (cloud), and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, input / output interfaces, and a communication interface. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data such as business configurations, historical states, and logs. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external devices via a network connection. When the computer program is executed by the processor, it implements the aforementioned image output method.

[0073] In some embodiments, the computer device may also be a device terminal, and its internal structure may be as follows: Figure 4 As shown, the computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device, and may also include a printing module. When the computer program is executed by the processor, it implements the image reception, integrity verification, and output steps on the device side.

[0074] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0075] In this embodiment, since the processor in the computer device executes the computer program stored in the memory to implement the above-described image output method, the same technical effect as the above-described method embodiment can be achieved.

[0076] In some embodiments, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps of any of the embodiments of the image output method described above.

[0077] In one embodiment, a computer program product includes a computer program that, when executed by a processor, implements the steps of any embodiment of the image output methods.

[0078] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0079] 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. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. The processors involved in the various embodiments provided in this application may be general-purpose processors, central processing units, graphics processors, digital signal processors, programmable logic devices, quantum computing-based data processing logic units, artificial intelligence (AI) processors, etc., and are not limited thereto.

[0080] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0081] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An image output method, characterized in that, Applied to the cloud, the method includes: The device receives an image processing request, performs image processing based on the request, and stores the image result at the image result address. Send the image result address to the device. When the device receives an image output confirmation instruction for the image result corresponding to the image result address, verify the image output confirmation instruction. Once the image output confirmation command passes the verification, the image result is processed into a target image operable by the device according to the corresponding image format processing rules. The target image is sent to the device so that the device can perform an integrity check on the target image and output the target image after the check passes.

2. The method according to claim 1, characterized in that, The image output confirmation command includes the parameters reported by the device this time; The step of processing the image result into a target image operable by the device according to the corresponding image format processing rules includes: The target image parameters are determined according to the hierarchical priority rules of the parameters reported by the device this time, the device model background configuration parameters, and the system default parameters. Using the target image parameters as boundaries, the image result is scaled proportionally to obtain an operable target image on the device side.

3. The method according to claim 2, characterized in that, The step of scaling the image result proportionally using the target image parameters as boundaries to obtain the target image operable on the device includes: The image result is scaled proportionally and converted into a binary bitmap adapted to the device to obtain a target image operable by the device.

4. The method according to claim 2, characterized in that, The step of scaling the image result proportionally using the target image parameters as boundaries to obtain the target image operable on the device includes: Using the target image parameters as boundaries, the processed image is scaled proportionally to obtain a proportionally scaled image; When the total number of bytes in the proportionally scaled image exceeds the maximum number of bytes in a single packet, the scaled image is divided into packets to obtain a packetized image frame that is operable on the device side. The device is used to perform integrity verification on the packetized image frames.

5. The method according to claim 4, characterized in that, The packetized image frame includes the total number of bytes and the starting metadata of the number of packets; The device-side integrity verification of the target image includes: Verify whether the cumulative number of bytes received for the target image is equal to the total number of bytes in the initial metadata; When the starting metadata contains an overall checksum, the checksum of the target image is recalculated, and the overall checksum is compared with the recalculated checksum. The target image parameters of the target image are parsed, and the image parameters are verified to conform to the format.

6. The method according to claim 1, characterized in that, The image output confirmation instruction includes the device identifier, the image result address, and the parameters reported by the device this time. The verification of the image output confirmation command includes: Verify the device registration status and operation permissions corresponding to the device identifier; Verify the legality and resource accessibility of the image result address; Verify the validity of the range of values ​​for the parameters reported by the device this time.

7. The method according to claim 1, characterized in that, The method further includes: Receive the verification failure message and the reason for failure sent by the device when the integrity verification fails; Determine whether to allow a retry based on the failure type corresponding to the failure reason, and resend the target image if a retry is allowed; If an error is detected during the download, conversion, or sending process, an error message is sent to the device so that the device can clear its cache and prompt the user to regenerate or retry.

8. The method according to claim 1, characterized in that, The method further includes: Receive historical data requests sent by the device, wherein the historical data requests include device identifier, user identifier, and request parameters; Based on the historical data request, read the service configuration and historical status corresponding to the device; If parameters are missing or the status is abnormal, the system will proceed to the default parameter rollback or error response path. After the default parameter rollback or error return path processing is completed, the result is sent to the device and the status and logs are recorded synchronously for subsequent sessions or operation and maintenance backend review.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

Images