An image acquisition method of a medical image device
Patent Information
- Application Number
- CN202610832546.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-10
- Publication Date
- 2026-09-15
Smart Images
Figure CN122765313A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of medical image acquisition, and in particular to an image acquisition method for a medical imaging device. Background Technology
[0002] In medical examinations, doctors often need to use advanced image acquisition software to capture and display real-time images from medical imaging equipment in order to perform various precise procedures. For example, in ophthalmological examinations, it is necessary to capture and display real-time images from ophthalmic equipment to perform tasks such as focusing, eye position adjustment, meibomian gland observation, tear film observation, and ocular surface examination. Such medical imaging equipment includes slit lamps, fundus cameras, corneal topography systems, ultrasound biological microscopes, and some endoscopic or microscope systems.
[0003] In such application scenarios, upper-layer image acquisition software not only needs to stably display real-time video, but also typically needs to support simultaneous image capture and recording functions during video preview. Currently, upper-layer image acquisition software usually uses an image capture method that is equivalent to screenshotting to achieve image capture. That is, when the user clicks the image capture button, the system directly reads a frame of pixels from the current rendering buffer or preview frame buffer, and then completes color conversion, JPEG / PNG encoding, and file writing in the same thread. The recording function obtains the H.264 / H.265 video file by calling the encoder to recompress the RGB / YUV pixel frames waiting to be decoded. Although the image capture method is simple, the image capture process simultaneously occupies the OpenGL context and rendering thread. The recording method of decoding first and then encoding means that the encoder needs to be run again for each recording. Image capture, recording, and real-time preview block each other, often causing the preview screen to stutter, drop frames, or have increased latency at the moment of image capture and recording. This makes it difficult to meet the stringent requirements of low latency, high stability, and concurrent acquisition actions in medical examination scenarios such as ophthalmology. Summary of the Invention
[0004] This application addresses the aforementioned problems and technical needs by proposing an image acquisition method for medical imaging equipment. The technical solution of this application is as follows: An image acquisition method for a medical imaging device, the image acquisition method of the medical imaging device comprising: The image acquisition software sends the received preview command to the image acquisition toolkit. The image acquisition toolkit establishes a video data channel with the corresponding medical imaging equipment based on the device address in the preview command. After preprocessing the real-time video stream sent by the medical imaging equipment through the video data channel into a compressed bitstream, the compressed bitstream is decoded and rendered to obtain a real-time preview image, which is then output to the image acquisition software for real-time display. When the video capture software receives a recording command, it sends the recording command to the video capture toolkit. While decoding and rendering the compressed stream to obtain a real-time preview, the video capture toolkit responds to the recording command by directly encapsulating the compressed stream into a video file. When the image acquisition software receives a capture command, it sends the capture command to the medical imaging device via the capture link between the software and the medical imaging device, and receives the target image frame extracted and returned by the medical imaging device in response to the capture command.
[0005] A further technical solution involves the image acquisition toolkit preprocessing the real-time video stream received from medical imaging equipment via the video data channel into a compressed stream, including: The image acquisition toolkit parses the received real-time video stream to obtain raw encoded data based on the media description information of the medical imaging equipment. It then converts the raw encoded data format into a predetermined data structure, retains the timestamp information corresponding to the real-time video stream, and adds the video encoding format identifier of the real-time video stream contained in the media description information to obtain a compressed bitstream with a predetermined data structure.
[0006] A further technical solution involves the image acquisition toolkit parsing the received real-time video stream based on the media description information of the medical imaging equipment to obtain raw encoded data, including: After receiving the real-time video stream via the RTP over TCP video data channel with the medical imaging equipment, the image acquisition toolkit parses and segments the real-time video stream according to the TCP byte stream format used to obtain RTP data packets. Based on the media description information of the medical imaging equipment, the segmented RTP data packets are decapsulated using RTP to obtain raw encoded data.
[0007] A further technical solution involves the image acquisition toolkit decoding and rendering the compressed stream to obtain a real-time preview image, including: The image acquisition toolkit uses the decoder corresponding to the video encoding format identifier carried in the compressed bitstream to perform low-latency decoding of the compressed bitstream, and then renders the decoded video frames to obtain a real-time preview.
[0008] A further technical solution involves rendering the decoded video frames to obtain a real-time preview, including: The GPU is used to upload textures to the decoded video frames according to the texture upload method corresponding to the pixel format, and then the shading rendering is completed to obtain a real-time preview screen.
[0009] Its further technical solution is that the image acquisition toolkit establishes a video data channel with the medical imaging equipment in response to preview commands, including: The image acquisition toolkit establishes a TCP connection with the medical imaging equipment based on the device address carried in the preview command, and sends a private CMD media description request to the medical imaging equipment; After the medical imaging equipment completes the legality verification of the received private CMD media description request, it returns a private CMD media description response carrying media description information to the image acquisition toolkit. After the image acquisition toolkit completes the legality verification of the received private CMD media description response, it parses the media description information of the medical imaging device and initiates a video data channel establishment request to the medical imaging device to establish a video data channel with the medical imaging device.
[0010] A further technical solution involves the image acquisition toolkit and the medical imaging device storing the same pre-shared authentication factor. The image acquisition toolkit, in response to a preview command, establishes a video data channel with the medical imaging device, which also includes: The image acquisition toolkit generates a random number and the current timestamp, and uses the stored pre-shared authentication factor to combine the random number and timestamp to obtain a request digest. Based on the random number, timestamp and request digest, an encrypted authentication request header is formed and carried in the private CMD media description request and sent to the medical imaging device. The medical imaging equipment parses the encrypted authentication request header of the private CMD media description request to obtain a random number, a timestamp, and a request digest. When the timestamp exceeds the allowed time window, the validity verification of the private CMD media description request is determined to have failed. When the timestamp is within the allowed time window, the equipment uses the stored pre-shared authentication factor to combine the random number and timestamp to obtain a response digest. When the response digest matches the request digest, the validity verification of the private CMD media description request is determined to have been completed. The response digest and media description information are then included in the private CMD media description response and returned to the image acquisition toolkit. When the image acquisition toolkit determines that the response digest in the private CMD media description response matches the locally computed request digest, it confirms that the private CMD media description response has been validated.
[0011] A further technical solution is that the image acquisition software receives the target image frame extracted and returned by the medical imaging device in response to the image capture command, including: The image acquisition software receives multiple consecutive image frames extracted and returned by the medical imaging device in response to the image capture command, and selects the image frame with the best image quality as the target image frame.
[0012] The further technical solution is that the image acquisition software and the medical imaging equipment establish an image capture link through an independent image capture interface. The independent image capture interface can be implemented in any of the following ways: HTTP interface, private CMD image capture command, direct callback of device driver library, or independent image capture service deployed on the acquisition machine.
[0013] A further technical solution is that the image acquisition method of medical imaging equipment also includes: The image acquisition software and image acquisition toolkit perform status callbacks and display the working status in real time during the preview, screenshot, and recording processes.
[0014] The beneficial technical effects of this application are: This application discloses an image acquisition method for medical imaging equipment. This method utilizes the video data channel between the image acquisition toolkit and the medical imaging equipment to form a video pipeline to complete real-time preview and recording operations. By using an independent image capture link between the image acquisition software and the medical imaging equipment, the video pipeline is bypassed to avoid blocking the real-time preview thread. The real-time preview branch and the recording encapsulation branch within the image acquisition toolkit are executed in parallel. The recording encapsulation branch directly encapsulates and compresses the bitstream without re-encoding and decoding to reduce the impact of recording on the real-time preview link. Thus, neither image capture nor recording can block the real-time preview, and high-quality image capture and recording can be completed without affecting the real-time preview.
[0015] This method uses a unified real-time video stream parsing and standardized format conversion within the image acquisition toolkit to obtain a compressed bitstream with a predetermined data structure. Subsequent real-time preview and recording encapsulation branches only process this unified compressed bitstream, thereby converging the differences between different medical imaging devices, different encoding formats, and different payload parameters within the image acquisition toolkit. This eliminates the need for the image acquisition software to parse the real-time video stream, media description information, or distinguish between different underlying encapsulation differences. Therefore, the image acquisition software does not need to change the upper-level process for each newly connected medical imaging device, making this method convenient for use in different application scenarios.
[0016] This method uses a triple mechanism of low-latency RTP over TCP direct acquisition, low-latency decoding, and GPU rendering to control the end-to-end preview latency to within 100ms, thus meeting the low-latency preview requirements for real-time preview images.
[0017] This method performs private CMD encryption authentication before establishing a video data channel between the image acquisition toolkit and the medical imaging equipment, preventing abnormal device streams or replay requests from directly entering the acquisition process and ensuring the legitimacy of the access.
[0018] This method allows medical imaging equipment to return multiple consecutive image frames to the image acquisition software through an independent image capture interface, and then select the image frame with the best image quality as the target image frame. This helps to improve the image capture quality and reduce the number of times images need to be captured again. The effect is particularly prominent in ophthalmological examination scenarios where the image capture quality is easily affected by blinking, momentary defocusing, eyelash obstruction, or reflection. Attached Figure Description
[0019] Figure 1 This is a flowchart of the image acquisition method in Embodiment 1 of this application.
[0020] Figure 2 This is a flowchart of the method for performing legality verification before establishing a video data channel in Embodiment 4 of this application. Detailed Implementation
[0021] The specific embodiments of this application will be further described below with reference to the accompanying drawings.
[0022] The image acquisition method for medical imaging equipment disclosed in this application is applied to an image acquisition system, which includes medical imaging equipment, an image acquisition toolkit, and image acquisition software, wherein: Medical imaging equipment can output real-time video streams and provide an independent capture interface. In one embodiment, the independent capture interface is implemented as any one of the following: HTTP (Hypertext Transfer Protocol) interface, private CMD capture command, direct callback from the device driver library, or an independent capture service deployed on the acquisition machine.
[0023] The image acquisition software is the upper-level software, used to receive various operation commands and trigger corresponding operations. It is also used for displaying images and summarizing and maintaining data, including maintaining inspection information, image storage paths, and acquisition records. In one embodiment, the image acquisition software receives operation commands through various human-computer interaction methods, including mouse and keyboard input, voice, gestures, external foot switch, HIS (Hospital Information System) commands, or automated scripts.
[0024] The image acquisition toolkit is a real-time media SDK (Software Development Kit) for video stream access from medical imaging equipment. It uniformly encapsulates various development tools and exposes interfaces for image acquisition software to use. Optionally, the interface between the image acquisition software and the image acquisition toolkit can be any of the following: direct C++ calls, platform bridging, or inter-process communication. Platform bridging includes any of Qt signal-slot, JNI, or Objective-C bridging, while inter-process communication includes any of gRPC, Local Socket, or shared memory.
[0025] The actual type of medical imaging equipment in this application can vary, but regardless of the specific type of medical imaging equipment, the image acquisition toolkit and image acquisition software must implement real-time video acquisition preview, image capture, and recording functions for the medical imaging equipment. In one application example, the medical imaging equipment is an ophthalmic device.
[0026] Example 1: The image acquisition method of the medical imaging equipment disclosed in this example includes the following steps, please refer to... Figure 1 The flowchart shown is as follows: Step 1: The image acquisition software sends the received preview command to the image acquisition toolkit. The preview command contains the device address of the medical imaging equipment.
[0027] In practical applications, after entering the acquisition page of the image acquisition software, the user configures the device address of the medical imaging equipment. The image acquisition software then obtains the device address based on the current device configuration. However, the image acquisition software does not directly parse the device's video stream from the device address. Instead, it sends a preview command to the image acquisition toolkit through its open interface to initiate a connection. This separates device protocol processing from image acquisition operations. Additionally, the image acquisition software typically loads various medical examination information and storage path information. When the medical imaging equipment is ophthalmic, the loaded medical examination information includes the patient, eye, and eyelids, while the loaded storage path information includes image and video recording directories.
[0028] Step 2: The image acquisition toolkit establishes a video data channel with the corresponding medical imaging equipment based on the device address in the preview command.
[0029] Step 3: The image acquisition toolkit receives the real-time video stream sent by the medical imaging equipment via the video data channel and preprocesses the real-time video stream into a compressed bitstream.
[0030] Step 4: The real-time preview branch inside the image acquisition toolkit decodes and renders the compressed bitstream to obtain a real-time preview image, which is then output to the image acquisition software for real-time display.
[0031] Step 5: During the process of the image acquisition toolkit outputting a real-time preview image to the image acquisition software for real-time display, when the image acquisition software receives a recording command, it sends the recording command to the image acquisition toolkit. While the image acquisition toolkit uses its real-time preview branch to decode and render the compressed stream to obtain the real-time preview image, it simultaneously encapsulates the compressed stream directly into a video file using its internal recording encapsulation branch in response to the recording command. The encapsulated video file can be written to the local storage of the medical imaging device's acquisition unit or a separate storage device.
[0032] This application employs a recording method that directly packages the compressed bitstream into the recording container format. It does not wait for decoded image frames or re-encode the live preview image. Therefore, the increased recording overhead primarily involves bitstream writing to the file and container encapsulation, without significantly consuming decoding and rendering resources in the live preview branch. Optionally, the recording container can be MP4, MOV, AVI, MKV, or other encapsulation formats acceptable to medical acquisition systems.
[0033] In practical implementation, when the video acquisition software receives a start recording command, it generates a temporary recording file path and calls the start recording interface of the video acquisition toolkit. The video acquisition toolkit then begins writing the compressed bitstream into the recording encapsulation branch. When the video acquisition software receives a stop recording command, it calls the stop recording interface of the video acquisition toolkit. The video acquisition toolkit ends container encapsulation and releases the recording resources. The video acquisition software moves or copies the temporary recording file to the official filename, generates the corresponding acquisition record, and refreshes the acquisition list. During the above recording process, the real-time preview branch inside the video acquisition toolkit continues to receive the compressed bitstream and perform decoding and rendering. The real-time preview is not paused due to recording, and because the recording does not rely on the re-encoding of the decoded image frames, the impact of recording on the real-time preview link can be reduced.
[0034] Step 6: During the process of the image acquisition toolkit outputting a real-time preview screen to the image acquisition software for real-time display, when the image acquisition software receives a capture command, it sends the capture command to the medical imaging device via the capture link between the image acquisition software and the medical imaging device, and receives the target image frame extracted and returned by the medical imaging device in response to the capture command.
[0035] The image acquisition software and medical imaging equipment establish an image capture link through a separate image capture interface. This separate image capture interface provided by the medical imaging equipment is independent of the video data channel. Instead of relying on real-time preview screenshots, the image acquisition software directly calls this interface, bypassing the decoding and rendering buffering of the real-time preview. This separate image capture interface avoids blocking the real-time preview thread caused by synchronously reading the OpenGL (Open Graphics Library) frame buffer and writing image encoding data to disk.
[0036] In addition, to avoid repeated triggering, when the image acquisition software receives a capture command, it first checks whether a capture task is already being executed. If a capture task is detected, it does not respond to the capture command and maintains the current capture state to avoid repeated triggering. If no capture task is currently being executed, it generates an image file name and save path based on the current medical examination information and calls the independent capture interface of the medical imaging device to capture the image.
[0037] In summary, this application utilizes the video data channel between the image acquisition toolkit and the medical imaging equipment to form a video pipeline for real-time preview and recording operations. By using an independent image capture link between the image acquisition software and the medical imaging equipment, the video pipeline is bypassed to avoid blocking the real-time preview thread. The real-time preview branch and the recording encapsulation branch within the image acquisition toolkit are executed in parallel. The recording encapsulation branch directly encapsulates and compresses the bitstream without re-encoding and decoding to reduce the impact of recording on the real-time preview link. As a result, neither image capture nor recording blocks the real-time preview, and high-quality image capture and recording are completed without affecting the real-time preview.
[0038] In Example 2, in step 3 of Example 1 above, when the image acquisition toolkit preprocesses the real-time video stream into a compressed bitstream, it first parses the received real-time video stream to obtain raw encoded data based on the media description information of the medical imaging device. Then, after converting the raw encoded data into a predetermined data structure, it retains the timestamp information corresponding to the real-time video stream and adds the video encoding format identifier of the real-time video stream contained in the media description information to obtain a compressed bitstream with a predetermined data structure.
[0039] The image acquisition toolkit outputs the compressed bitstream to the internal processing chain via a unified callback or queue. Subsequent real-time preview and recording encapsulation branches only process this unified compressed bitstream: In the real-time preview branch, the compressed bitstream is first decoded using the decoder corresponding to the video encoding format identifier carried by the bitstream. Then, the decoded video frames are rendered to obtain the real-time preview image. For example, if the compressed bitstream carries H.264, an H.264 decoder is used; if it carries H.265, an H.265 decoder is used. In the recording encapsulation branch, the compressed bitstream and its carried timestamp information are encapsulated together.
[0040] The media description information of the medical imaging equipment includes the video encoding format identifier, payload type, clock frequency, video channel number, and other information of the real-time video stream. The video encoding format identifier for the real-time video stream includes common formats such as H.264 and H.265. Retaining the timestamp information corresponding to the real-time video stream involves necessary timestamp conversion operations, such as converting the timestamp corresponding to the real-time video stream to a millisecond-level playback timestamp based on the clock frequency in the media description information. This part refers to existing methods and will not be elaborated upon in this application.
[0041] In one embodiment, the predetermined data structure used for the compressed bitstream is the Annex-B format NALU (Network Abstraction Layer Unit) data structure. The resulting compressed bitstream includes: inserting a four-byte start code 0x00 0x00 0x00 0x01 into the header of the raw encoded data, retaining the timestamp information corresponding to the real-time video stream, and adding a video encoding format identifier, and encapsulating it into a unified NALU data structure within the image acquisition toolkit.
[0042] This allows real-time video streams with different data structures to be converted into compressed bitstreams with a unified predetermined data structure. This consolidates the differences between different medical imaging devices, different encoding formats, and different payload parameters within the image acquisition toolkit, eliminating the need for the image acquisition software to parse real-time video streams, media description information, or distinguish between different underlying encapsulation differences. Therefore, the image acquisition software does not need to change the upper-layer process for each newly connected medical imaging device, making this method convenient for use in different application scenarios.
[0043] Example 3: In Example 2 above, the received real-time video stream needs to be parsed to obtain raw encoded data based on the media description information of the medical imaging device. Therefore, the image acquisition toolkit first needs to obtain the media description information of the medical imaging device. In this example, this information is obtained during the stage of establishing a video data channel between the image acquisition toolkit and the medical imaging device, including: The image acquisition toolkit first parses the host, port, path, username, and password information from the device address to establish a TCP connection with the medical imaging equipment. Then, it sends a private CMD media description request to the medical imaging equipment via this TCP connection using a proprietary CMD protocol to obtain the equipment's media description information. It also initiates a video data channel establishment request via the same TCP connection to establish a video data channel between the toolkit and the medical imaging equipment. This video data channel uses TCP video data transport methods, including RTP over TCP video data channel, TLV frames, length-prefixed streams, or proprietary video frame encapsulation.
[0044] The image acquisition toolkit and medical imaging equipment run a proprietary CMD protocol, or custom command and control protocol, on this TCP channel. After the video data channel is established, the medical imaging equipment continuously sends real-time video streams in the form of TCP byte streams over the TCP connection according to the interleaved format agreed upon by the proprietary CMD layer. The image acquisition toolkit can then receive the real-time video streams and parse them based on the acquired media description information.
[0045] The method by which the image acquisition toolkit parses the real-time video stream based on media description information is related to the video data channel type and the interleaved format of the real-time video stream. In another embodiment, the image acquisition toolkit establishes an RTP over TCP video data channel with the medical imaging equipment, that is, it adopts a transmission method that carries RTP (Real-time Transport Protocol) video data over a TCP connection. This method is beneficial for achieving low latency and is easy to penetrate NAT and firewalls in a hospital network environment. The raw encoded data obtained by parsing the received real-time video stream based on the media description information includes: The video acquisition toolkit first identifies the frame header identifier, channel number, and RTP payload length field of the real-time video stream in the receive buffer according to the interleaved format agreed upon by the proprietary CMD layer, thereby segmenting complete RTP data packets from the real-time video stream. Incomplete data is retained in the receive buffer and padded with subsequent bytes to avoid RTP data packet boundary misalignment.
[0046] Then, the RTP data packets are decapsulated based on the media description information of the medical imaging equipment. This includes stripping the RTP header from the RTP data packets according to the RTP payload rules corresponding to the video encoding format identifier in the media description information, and then reassembling the fragmented payloads to obtain the raw encoded data. The single NALU packing, fragment packing, and reassembly of different video encoding format identifiers can employ existing commonly used RTP video payload processing methods, which will not be elaborated upon here.
[0047] In addition to employing a low-latency RTP over TCP video data channel, in another embodiment, the image acquisition toolkit also enables a low-latency decoding mechanism in the decoder when decoding the compressed bitstream using the decoder corresponding to the video encoding format identifier carried in the compressed bitstream. Different decoders enable this low-latency decoding mechanism in different ways, including enabling a low-latency flag, fast decoding, chunk decoding, a smaller asynchronous depth, or zero-latency parameters, so that the decoder outputs each frame as little as possible without introducing additional buffering. The decoders used include FFmpeg, MediaCodec, VideoToolbox, Direct3D11 / DXVA, NVDEC, Intel QSV, or vendor-specific HIS decoders, etc.
[0048] Furthermore, the GPU (Graphics Processing Unit) is prioritized for rendering the decoded video frames to obtain a real-time preview. When no GPU is available, rendering is degraded to CPU rendering. This includes uploading textures to the decoded video frames according to the texture upload method corresponding to the pixel format, followed by shading and rendering to obtain the real-time preview. Specifically, BGRA format uses a single-texture upload method, YUV420P format uses a Y, U, and V three-texture upload method, and NV12 or NV21 format uses a Y and UV dual-texture upload method. Color format conversion, rotation, and scaling are preferentially performed in the GPU shader to avoid converting to RGB on the CPU for each frame. The GPU rendering backend can use OpenGL, Direct3D, Metal, Vulkan, QtMultimedia textures, or Flutter Textures, as long as low-copy texture upload and GPU-side color conversion are implemented. This mechanism can reduce CPU load and lower rendering latency.
[0049] RTP over TCP direct acquisition, low-latency decoding, and GPU rendering can all reduce end-to-end preview latency. By combining these three mechanisms, end-to-end preview latency can be reduced to less than 100ms, achieving low-latency real-time preview.
[0050] Example 4 further incorporates a legitimacy verification process before establishing a video data channel between the image acquisition toolkit and the medical imaging equipment, preventing abnormal device streams or replay requests from directly entering the acquisition process. As described in Example 3 above, when the image acquisition toolkit establishes a TCP connection with the medical imaging equipment, it sends a private CMD media description request and initiates a video data channel establishment request to the medical imaging equipment via the TCP connection. After adding the legitimacy verification process, this process is completed in two steps, including: The image acquisition toolkit first sends a private CMD media description request to the medical imaging device via an established TCP connection. After validating the received private CMD media description request, the medical imaging device returns a private CMD media description response carrying media description information to the image acquisition toolkit.
[0051] After the image acquisition toolkit completes the legality verification of the received private CMD media description response, it parses the media description information of the medical imaging device from the private CMD media description response, and initiates a video data channel establishment request to the medical imaging device via TCP connection to establish a video data channel with the medical imaging device.
[0052] In one embodiment, the above-mentioned legitimacy verification process is completed using a private CMD encryption authentication method based on random numbers, timestamps, and pre-shared authentication factors. The image acquisition toolkit and the medical imaging equipment each store the same pre-shared authentication factor. The above process is further implemented as follows (please refer to...). Figure 2 The flowchart shown is as follows: 1. The image acquisition toolkit generates a random number and the current timestamp, and uses a stored pre-shared authentication factor to perform a combined operation on the random number and timestamp to obtain a request digest. Then, based on the random number, timestamp, and request digest, an encrypted authentication request header is formed and sent to the medical imaging device in a private CMD media description request.
[0053] In this embodiment, a pre-shared authentication factor, a random number, and a timestamp are used as inputs. A fixed-length checksum calculated using a digest algorithm is used as the request digest. The digest algorithm used can be any one of MD5, SHA-1, SHA-256, or HMAC. The calculation method for the subsequent response digest is similar and will not be described again here.
[0054] 2. The medical imaging equipment parses the encrypted authentication request header of the received private CMD media description request to obtain a random number, timestamp, and request digest. First, it checks whether the parsed timestamp is within a preset allowed time window: When the timestamp is detected to be outside the allowed time window, it is determined that the validity verification of the private CMD media description request has failed. The private CMD media description request is then rejected, and an error response is returned to the image acquisition toolkit to indicate authentication failure or request expiration.
[0055] When a timestamp is detected to be within the allowed time window, the stored pre-shared authentication factor is used to combine the random number and the timestamp to obtain a response digest, and the consistency between the response digest and the parsed request digest is checked. When the response digest matches the parsed request digest, the legitimacy verification of the private CMD media description request is confirmed, and the response digest and media description information are returned to the image acquisition toolkit along with the private CMD media description response.
[0056] When the response digest does not match the parsed request digest, an error response is returned to the image acquisition toolkit to indicate authentication failure.
[0057] 3. The image acquisition toolkit parses the received private CMD media description response to obtain a response digest, and checks whether it matches the locally calculated request digest: When the parsed response digest matches the locally calculated request digest, the legitimacy verification of the private CMD media description response is confirmed. Further parsing of the private CMD media description response yields the media description information of the medical imaging device, and a video data channel establishment request is sent to establish a video data channel with the medical imaging device.
[0058] When the parsed response digest is inconsistent with the locally calculated request digest, or when an error response is received from the medical imaging device, if the validity check of the private CMD media description response fails, an open failure response is directly returned to the image acquisition software.
[0059] In this way, the device video stream undergoes a validity check before entering the preview link, preventing abnormal device streams or replay requests from directly entering the acquisition process. Furthermore, since the validity check only occurs at the private CMD control layer and does not change the subsequent RTP video data format, it does not add any extra processing overhead to each frame of video data.
[0060] Example 5: Considering the unstable success rate of single-frame capture by medical imaging equipment, especially in ophthalmological examination scenarios, factors such as blinking, momentary defocusing, eyelash obstruction, reflections, or exposure flicker can render a captured single image frame unusable, often requiring repeated captures. To improve the quality of the captured target image frame, in step 6 of Example 1 above, the medical imaging equipment extracts multiple consecutive image frames according to the capture command and returns them to the image acquisition software. After receiving the multiple consecutive image frames extracted and returned by the medical imaging equipment in response to the capture command, the image acquisition software selects the image frame with the best image quality as the final target image frame.
[0061] The number of image frames returned by medical imaging equipment can be customized. When evaluating the image quality of each image frame, multiple indicators such as image frame sharpness, exposure histogram, integrity, and equipment-side quality evaluation value are used for assessment. In ophthalmological examination scenarios, blink detection or eye position detection results can also be combined. For specific implementation, existing image quality evaluation methods can be referenced.
[0062] Example 6: During the execution of this image acquisition method, the image acquisition software and image acquisition toolkit also perform status callbacks and display the working status during previewing, capturing, and recording in real time. The working status here includes various working statuses during the execution of the above embodiments, including: When the image acquisition toolkit detects a failure to connect to the private CMD, a failure to authenticate the device, a failure to acquire media description information, or a failure to establish a video channel, it returns an "open failed" status to the image acquisition software. Once the image acquisition toolkit begins receiving the real-time video stream from the medical imaging device, it returns an "open successful" status to the image acquisition software. When the image acquisition toolkit detects a connection interruption with the medical imaging device or an abnormal shutdown of the medical imaging device, it returns a "disconnected" status to the image acquisition software.
[0063] Once the image acquisition software successfully receives the image frame captured by the medical imaging device, it generates a capture completion event. If the medical imaging device's independent capture interface returns an error, an empty response, or fails to save, the image acquisition software clears the capture status and prompts the user to recapture the image or check the device.
[0064] When recording starts and stops, the video capture software updates the recording status and capture list.
[0065] The image acquisition software dynamically updates and displays the various working states mentioned above during real-time preview, image capture, and recording. Through this closed-loop status monitoring, it is possible to clearly know whether the device is successfully connected, whether the real-time preview is normal, whether image capture is complete, and whether recording has ended. This approach avoids the problem of only displaying the image without providing feedback on the acquisition status, making it more suitable for continuous image acquisition workflows in medical imaging equipment.
[0066] The above descriptions are merely preferred embodiments of this application, and this application is not limited to the above embodiments. It is understood that other improvements and variations that can be directly derived or conceived by those skilled in the art without departing from the spirit and concept of this application should be considered to be included within the protection scope of this application.
Claims
1. An image acquisition method of a medical image apparatus, characterized by, The image acquisition method of the medical imaging equipment includes: The image acquisition software sends the received preview command to the image acquisition toolkit. The image acquisition toolkit establishes a video data channel with the corresponding medical imaging device according to the device address in the preview command. After preprocessing the real-time video stream sent by the medical imaging device through the video data channel into a compressed bitstream, the compressed bitstream is decoded and rendered to obtain a real-time preview image, which is then output to the image acquisition software for real-time display. When the video capture software receives a recording instruction, it sends the recording instruction to the video capture toolkit. In the process of decoding and rendering the compressed bitstream to obtain a real-time preview, the video capture toolkit responds to the recording instruction by directly encapsulating the compressed bitstream into a video file. When the image acquisition software receives a capture command, it sends the capture command to the medical imaging device via the capture link between the software and the medical imaging device, and receives the target image frame extracted and returned by the medical imaging device in response to the capture command.
2. The medical image apparatus image acquisition method of claim 1, wherein, The image acquisition toolkit preprocesses the real-time video stream received from medical imaging equipment via the video data channel into a compressed stream, including: The image acquisition toolkit parses the received real-time video stream to obtain raw encoded data based on the media description information of the medical imaging equipment. It then converts the raw encoded data format into a predetermined data structure, retains the timestamp information corresponding to the real-time video stream, and adds the video encoding format identifier of the real-time video stream contained in the media description information to obtain a compressed bitstream with a predetermined data structure.
3. The image acquisition method of the medical imaging equipment according to claim 2, characterized in that, The image acquisition toolkit parses the received real-time video stream based on the media description information of the medical imaging equipment to obtain raw encoded data, including: After receiving the real-time video stream via the RTP over TCP video data channel with the medical imaging equipment, the image acquisition toolkit parses and segments the real-time video stream according to the TCP byte stream format used to obtain RTP data packets. Based on the media description information of the medical imaging equipment, the segmented RTP data packets are decapsulated using RTP to obtain raw encoded data.
4. The image acquisition method of the medical imaging equipment according to claim 3, characterized in that, The image acquisition toolkit decodes and renders the compressed bitstream to obtain a real-time preview image, including: The image acquisition toolkit uses the decoder corresponding to the video encoding format identifier carried in the compressed bitstream to perform low-latency decoding of the compressed bitstream, and then renders the decoded video frames to obtain a real-time preview.
5. The image acquisition method of the medical imaging equipment according to claim 4, characterized in that, The decoded video frames are rendered to obtain a real-time preview, including: The GPU is used to upload textures to the decoded video frames according to the texture upload method corresponding to the pixel format, and then the shading rendering is completed to obtain a real-time preview screen.
6. The image acquisition method of the medical imaging equipment according to claim 2, characterized in that, The image acquisition toolkit establishes a video data channel with the medical imaging equipment in response to the preview command, including: The image acquisition toolkit establishes a TCP connection with the medical imaging device based on the device address carried in the preview command, and sends a private CMD media description request to the medical imaging device. After the medical imaging equipment completes the legality verification of the received private CMD media description request, it returns a private CMD media description response carrying media description information to the image acquisition toolkit. After the image acquisition toolkit completes the legality verification of the received private CMD media description response, it parses the media description information of the medical imaging device and initiates a video data channel establishment request to the medical imaging device to establish a video data channel with the medical imaging device.
7. The image acquisition method of the medical imaging equipment according to claim 6, characterized in that, The image acquisition toolkit and the medical imaging device each store the same pre-shared authentication factor. The image acquisition toolkit, in response to the preview command, establishes a video data channel with the medical imaging device, which further includes: The image acquisition toolkit generates a random number and the current timestamp, and uses the stored pre-shared authentication factor to combine the random number and timestamp to obtain a request digest. Based on the random number, timestamp and request digest, an encrypted authentication request header is formed and carried in the private CMD media description request and sent to the medical imaging device. The medical imaging equipment parses the encrypted authentication request header of the private CMD media description request to obtain a random number, a timestamp, and a request digest. When the timestamp exceeds the allowed time window, the validity verification of the private CMD media description request is determined to have failed. When the timestamp is within the allowed time window, the equipment uses the stored pre-shared authentication factor to combine the random number and timestamp to obtain a response digest. When the response digest matches the request digest, the validity verification of the private CMD media description request is determined to have been completed. The response digest and media description information are then included in the private CMD media description response and returned to the image acquisition toolkit. When the image acquisition toolkit determines that the response digest in the private CMD media description response matches the locally computed request digest, it confirms that the private CMD media description response has been validated.
8. The image acquisition method of the medical imaging equipment according to claim 1, characterized in that, The image acquisition software receives the target image frame extracted and returned by the medical imaging device in response to the image capture command, including: The image acquisition software receives multiple consecutive image frames extracted and returned by the medical imaging device in response to the image capture command, and selects the image frame with the best image quality as the target image frame.
9. The image acquisition method of the medical imaging equipment according to claim 1, characterized in that, The image acquisition software and the medical imaging equipment establish an image capture link through an independent image capture interface. The independent image capture interface can be implemented in any of the following ways: HTTP interface, private CMD image capture command, direct callback of device driver library, or independent image capture service deployed on the acquisition machine.
10. The image acquisition method of the medical imaging equipment according to claim 1, characterized in that, The image acquisition method of the medical imaging equipment also includes: The image acquisition software and image acquisition toolkit perform status callbacks and display the working status in real time during the preview, screenshot, and recording processes.