Image processing method and apparatus, and electronic device, medium and product
Patent Information
- Application Number
- PCT/CN2025/085535
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-03-27
- Publication Date
- 2026-10-01
Smart Images
Figure CN2025085535_01102026_PF_FP_ABST
Abstract
Description
Image processing methods, apparatus, electronic devices, media and products Technical Field
[0001] This disclosure relates to the field of vehicle technology, and more particularly to an image processing method, apparatus, electronic device, medium, and product. Background Technology
[0002] The vehicle surround view system uses multiple wide-angle cameras installed around the car to cover the entire field of view around the vehicle. It processes multiple video images collected at the same time to obtain a 360-degree top view of the vehicle's surroundings. Finally, the image is displayed on the screen of the center console. It is intuitive and has no blind spots, allowing the driver to easily control the vehicle to park or pass through complex road surfaces, effectively reducing the occurrence of accidents such as scratches, collisions, and getting stuck.
[0003] In existing technologies, in-vehicle surround view systems often use framebuffer technology. Framebuffer is an application programming interface (API) provided by Linux for display devices, abstracting video memory as a device and allowing upper-layer applications to directly read and write to the display buffer in graphics mode, thereby controlling the content displayed on the screen. However, for scenarios requiring the processing and simultaneous display of data from multiple cameras, framebuffer cannot provide effective graphics compositing and rendering support. Developers need to rely on additional middleware or libraries for graphics processing, increasing development complexity. Summary of the Invention
[0004] Embodiments of this disclosure provide an image processing method, apparatus, electronic device, medium, and product.
[0005] According to some embodiments, the first aspect of this disclosure provides an image processing method, including: acquiring surround view activation information of a vehicle; calling a corresponding processing module to request native window resources based on the surround view activation information; processing the graphic data collected by the vehicle to obtain a processed image; and displaying the processed image using the native window resources.
[0006] In some embodiments, the step of calling the corresponding processing module to request native window resources based on the lookaround activation information includes: determining the target processing module corresponding to the lookaround activation information from multiple candidate processing modules based on the source of the lookaround activation information; and calling the target processing module to request native window resources.
[0007] In some embodiments, determining the target processing module corresponding to the surround activation information from multiple candidate processing modules based on the source of the surround activation information includes: if the surround activation information is a control command input by a user, then determining the foreground processing application as the target processing module corresponding to the surround activation information.
[0008] In some embodiments, determining the target processing module corresponding to the surround view activation information from multiple candidate processing modules based on the source of the surround view activation information includes: if the surround view activation information is vehicle status information, then determining the target processing module corresponding to the surround view activation information from a front-end processing application and a back-end processing service based on the status information.
[0009] In some embodiments, determining the target processing module corresponding to the surround view activation information from the foreground processing application and the background processing service based on the status information includes: if the vehicle is not fully started, determining the background processing service as the target processing module corresponding to the surround view activation information; if the vehicle has been fully started, determining the foreground processing application as the target processing module corresponding to the surround view activation information.
[0010] In some embodiments, the method further includes: when the background processing service is the target processing module corresponding to the surround view activation information, it creates a Surface object through SurfaceComposerClient and writes the graphic data collected by the vehicle into the Surface object; when the foreground processing application is the target processing module corresponding to the surround view activation information, it creates a Surface object through SurfaceView and writes the graphic data collected by the vehicle into the Surface object.
[0011] In some embodiments, processing the graphic data collected by the vehicle to obtain a processed image includes: writing the graphic data collected by the vehicle into a graphic buffer corresponding to the native window resource; rendering the graphic data in the graphic buffer; and adding the graphic buffer to a buffer queue after rendering is completed; retrieving the graphic data in the graphic buffer from the buffer queue and compositing it to obtain the processed image.
[0012] In some embodiments, before adding the graphics buffer to the buffer queue, the method further includes locking the graphics data in the graphics buffer.
[0013] In some embodiments, the method further includes: obtaining surround view off information of the vehicle and destroying the native window.
[0014] According to some embodiments, a second aspect of this disclosure provides an image processing apparatus, comprising: an acquisition module for acquiring surround view activation information of a vehicle; a creation module for calling a corresponding processing module to request native window resources based on the surround view activation information; and a display module for processing graphic data acquired from the vehicle to obtain a processed image, and displaying the processed image using the native window resources.
[0015] According to some embodiments, a third aspect of this disclosure provides an electronic device, including: a processor, and a memory communicatively connected to the processor; the memory storing computer-executable instructions; the processor executing the computer-executable instructions stored in the memory to implement the method as described in any of the preceding claims.
[0016] According to some embodiments, a fourth aspect of this disclosure provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, are used to implement the method described above.
[0017] According to some embodiments, a fifth aspect of this disclosure provides a computer program product including computer execution instructions that, when executed by a processor, are used to implement the method described above.
[0018] The image processing methods, apparatus, electronic devices, media, and products provided in this disclosure, based on the acquired vehicle surround-view activation information, call the corresponding processing module to apply for native window resources and use the native window resources to display the processing results of the image data collected by the vehicle. Therefore, they can reliably respond to surround-view activation information and activate surround-view display in different scenarios. Furthermore, using native window resources for surround-view display allows direct interaction with the underlying graphics processor, enabling fast image rendering through hardware acceleration. It can also fully utilize other functional modules in the Android system, thereby effectively improving the processing effect of image data and reducing development difficulty. Therefore, it can combine the ecological advantages of the Android system with the efficient image rendering capabilities of native windows, ensuring low latency and high performance while significantly reducing system development and maintenance costs. It is suitable for application scenarios with high image processing requirements in modern in-vehicle intelligent cockpits. Attached Figure Description
[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of the embodiments of this disclosure.
[0020] Figure 1 illustrates an exemplary architectural diagram of the vehicle infotainment system provided in an embodiment of this disclosure.
[0021] Figure 2 illustrates a schematic flowchart of the image processing method provided in an embodiment of this disclosure;
[0022] Figure 3 illustrates a scenario diagram of the producer-consumer model provided in an embodiment of this disclosure;
[0023] Figure 4 illustrates an exemplary scene diagram of image rendering provided in an embodiment of this disclosure;
[0024] Figure 5 illustrates a scenario diagram of another interactive interface provided in an embodiment of this disclosure;
[0025] Figure 6 illustrates a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure.
[0026] The accompanying drawings have illustrated specific embodiments of this disclosure, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this disclosure to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.
[0028] First, the terms used in the embodiments of this disclosure will be explained.
[0029] Window: Represents a single view area on the display. It is controlled by the Window Manager and is composed of views. These views form a View Hierarchy, which is then rendered onto the Surface created by WindowFlinger for the Window.
[0030] View: The basic module representing components that interact with the user. A view occupies a rectangular area on the screen and is responsible for drawing graphics and handling interactive events within that area. In Android, the views of each window constitute a View Hierarchy.
[0031] Surface: Created by SurfaceFlinger and given to the Window Manager, and then handed over by the Window Manager to the Window for drawing the content of the view within the window. It is the interface used for drawing graphics in the Android system, representing a screen surface that can be drawn on, and providing a buffer as a data carrier object. Applications can send rendering commands to the GPU through this buffer.
[0032] Native Window is an abstract class in the Android system used to display graphics, providing a series of methods for managing the graphics buffer. Through Native Window, you can obtain the window's drawing surface (Surface) and draw graphics on that surface.
[0033] In the Android system, Surface and Native Window work together to display and manage graphics. Surface encapsulates information related to the native window, while Native Window is its underlying implementation, providing methods for manipulating image data. Developers use Surface to draw graphics and Native Window to interact with the underlying graphics hardware, achieving efficient graphics processing and display.
[0034] SurfaceView is a View component belonging to the application layer. It provides a window for displaying the image content of a Surface. Internally, SurfaceView manages a Surface object and is responsible for drawing its content onto the screen.
[0035] SurfaceComposerClient is a client API (interface) provided by SurfaceFlinger, belonging to the system service layer, used to create and manage Surfaces. Most application processes interact with SurfaceFlinger through SurfaceComposerClient.
[0036] Vehicle Hal is a hardware abstraction layer (HAL) service related to vehicle services, which mainly defines standardized interfaces and attribute management for interacting with automotive hardware.
[0037] The vehicle surround view system uses multiple wide-angle cameras installed around the car to cover the entire field of view around the vehicle. It processes multiple video images collected at the same time to obtain a 360-degree top view of the vehicle's surroundings. Finally, the image is displayed on the screen of the center console. It is intuitive and has no blind spots, allowing the driver to easily control the vehicle to park or pass through complex road surfaces, effectively reducing the occurrence of accidents such as scratches, collisions, and getting stuck.
[0038] In existing technologies, Around View Monitor (AVM) systems commonly use framebuffer technology. Framebuffer is an application programming interface (API) provided by Linux for display devices, abstracting video memory as a device and allowing upper-level applications to directly read and write to the display buffer in graphics mode, thereby controlling the content displayed on the screen. However, for scenarios requiring the processing and simultaneous display of data from multiple cameras, framebuffer cannot provide effective graphics compositing and rendering support. Developers need to rely on additional middleware or libraries for graphics processing, increasing development complexity.
[0039] The technical solutions of this disclosure are illustrated below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.
[0040] The vehicle infotainment system provided in the embodiments of this disclosure will be described below with reference to Figure 1.
[0041] Figure 1 is a schematic diagram of the vehicle infotainment system architecture provided in this embodiment of the present disclosure. As shown in Figure 1, the vehicle infotainment system can be divided into a hardware layer, a drive layer, a hardware abstraction layer (HAL), a framework layer, and an application layer. The hardware layer includes an electronic control unit (ECU), a camera, and a display screen. The ECU and the display screen can acquire surround view activation information, activate the vehicle surround view system, and display a surround view image of the vehicle on the display screen; wherein, the surround view activation information may include the vehicle's reverse gear status information acquired by the ECU, or control commands input by the user received by the display screen.
[0042] Specifically, the electronic control unit (ECU) acquires the vehicle's gear position information and sends it via Ethernet (eth) to the Vehicle Hardware Abstraction Layer (VHL) interface. The VHL interface then forwards the gear position information to either the front-end (application layer) processing application (AVM APP) or the back-end (framework layer) processing service (AVM Service). When the gear position information indicates reverse gear, the receiving processing application / service activates the surround-view processing. The display screen receives control commands input by the user's touch input and sends these commands to the front-end processing application, thereby activating the surround-view processing.
[0043] The image processing method provided in the embodiments of this disclosure will be described below with reference to Figure 2.
[0044] Figure 2 is a flowchart illustrating the image processing method provided in this embodiment. The executing entity of this method can be an in-vehicle infotainment system. As shown in Figure 2, the image processing method provided in this embodiment may include:
[0045] S201. Obtain the vehicle's surround view activation information;
[0046] S202. Based on the surround view activation information, call the corresponding processing module to request native window resources;
[0047] S203. Process the graphic data collected from the vehicle to obtain the processed image, and display the processed image using native window resources.
[0048] In the specific implementation, after the vehicle's surround view activation information is obtained, the vehicle system calls the corresponding processing module to request a native window resource and writes the graphic data collected by the vehicle into the Sureface of the requested window. By rendering and compositing the graphic data in the Sureface, a processed image is obtained, and finally, the processed image is displayed on the display screen through the requested window resource.
[0049] Native Window can directly interact with the underlying graphics processing unit (GPU), enabling rapid image rendering through hardware acceleration. It can run flexibly on various hardware platforms, compatible with everything from low-power embedded chips to high-performance multi-core processors, allowing the solution to adapt to the configuration requirements of different vehicle models. Through Android's native hardware abstraction layer interface, Native Window can seamlessly interface with camera modules, displays, and image processing units from different manufacturers, further enhancing system portability. Native Window is tightly integrated with Android's multimedia framework, supporting fast image stream capture, processing, and display, effectively reducing system overhead. Native Window can fully utilize other functional modules in the Android ecosystem, such as image processing algorithms, display management, and sensor management modules, allowing developers to quickly adapt to different automotive hardware platforms. It also allows for easier addition of features such as AI image enhancement processing and night vision mode to meet the needs of different automotive scenarios. As an open-source system, Android does not require additional licensing fees, allowing developers to freely modify and optimize the system. Furthermore, as Android's application in the automotive market increases and its ecosystem matures, the compatibility and support of related hardware and software become richer, further reducing overall development costs.
[0050] In this embodiment, based on the obtained vehicle surround view activation information, the corresponding processing module is invoked to request native window resources, and the native window resources are used to display the processing results of the graphic data collected by the vehicle. Therefore, it can reliably respond to surround view activation information and activate surround view display in different scenarios. Furthermore, using native window resources for surround view display can directly interact with the underlying graphics processor, achieve fast image rendering through hardware acceleration, and make full use of other functional modules in the Android system, thereby effectively improving the processing effect of graphic data and reducing development difficulty.
[0051] In some embodiments, the corresponding processing module is invoked to request native window resources, including:
[0052] Based on the source of the surround view activation information, the target processing module corresponding to the surround view activation information is determined from multiple candidate processing modules;
[0053] Call the target processing module to request native window resources.
[0054] In the specific implementation, different processing modules can be used as target processing modules for surround view activation information from different sources, so as to effectively respond to the surround view activation information and enable surround view display.
[0055] In one possible implementation, based on the source of the look-around activation information, the target processing module corresponding to the look-around activation information is determined from multiple candidate processing modules, including:
[0056] If the surround view activation information is a control command input by the user, then the foreground processing application is determined as the target processing module corresponding to the surround view activation information.
[0057] In its implementation, as shown in Figure 1, when the surround view activation information is received by the user's touch input control command on the display screen, the display screen sends the received control command to the foreground processing application. The foreground processing application, acting as the target processing module, requests window resources and acquires the graphic data captured by the vehicle's camera, writing the graphic data into the Surface of the requested window. The vehicle system processes the graphic data in the Surface, including but not limited to rendering and compositing, to obtain a composite image. This composite image is then displayed on the display screen through the window resources, effectively responding to the user's input control command for surround view display.
[0058] In one possible implementation, based on the source of the look-around activation information, the target processing module corresponding to the look-around activation information is determined from multiple candidate processing modules, including:
[0059] If the surround view activation information is the vehicle's status information, then the target processing module corresponding to the surround view activation information is determined from the front-end processing application and the back-end processing service based on the status information.
[0060] In its implementation, as shown in Figure 1, when the surround view activation information is the vehicle's status information, the electronic control unit sends the acquired status information to the foreground processing application or the background processing service. The foreground processing application or the background processing service requests window resources and acquires the graphic data captured by the vehicle's camera, writing the graphic data into the Surface of the requested window. The vehicle system processes the graphic data in the Surface, including but not limited to rendering and compositing, to obtain a composite image, and displays the composite image on the display screen through the window resources, thereby effectively activating the surround view display automatically based on the vehicle's status.
[0061] For example, vehicle status information may include gear position information. When the gear position information represents reverse gear, the target processing module calls the native window interface to create a graphics buffer.
[0062] For example, vehicle status information may include road condition information. When road conditions are complex (e.g., narrow roads), the target processing module calls the native window interface to create a graphics buffer.
[0063] For example, based on the status information, the target processing module corresponding to the lookaround activation information is determined from the foreground processing application and the background processing service, including:
[0064] If the vehicle is not fully started, the background processing service is identified as the target processing module corresponding to the surround view activation information.
[0065] If the vehicle has been fully started, determine the front-end processing application as the target processing module corresponding to the surround view activation information.
[0066] In practical implementation, when the vehicle is first started, the vehicle system is not fully started, so the foreground processing application cannot work reliably. At this time, the background processing service can be used as the target processing module. The background processing service calls the native window interface to create a graphics buffer, so that the surround view display can be automatically activated according to the vehicle's status information even when the vehicle is not fully started. When the vehicle is fully started, the foreground processing application is used as the target processing module. It can not only obtain the vehicle's status information and activate the surround view display according to the vehicle's status information, but also receive the control commands input by the user through the touch screen of the vehicle system to trigger the surround view display. Therefore, the reliability of the surround view display can be effectively improved.
[0067] For example, the method also includes:
[0068] When the background processing service acts as the target processing module corresponding to the surround view activation information, it creates a Surface object through SurfaceComposerClient and writes the graphic data collected by the vehicle into the Surface object.
[0069] When the front-end processing application acts as the target processing module corresponding to the surround view activation information, it creates a Surface object through SurfaceView and writes the graphic data collected by the vehicle into the Surface object.
[0070] When the foreground processing application acts as the target processing module, it requests an application (Activity) window as the native window in the Java layer and requests the creation of a SurfaceView. The processing application receives a SurfaceCreated notification, indicating successful SurfaceView request. When the processing application creates the SurfaceView, the system requests a new Surface from SurfaceFlinger via SurfaceComposerClient and allocates an independent graphics buffer. The processing application then uses setSurface to pass the Surface object to the local machine. On the C++ side, the background processing service receives the Surface object via nativeSetSurface and obtains an ANativeWindow object via ANativeWindow_fromSurface to manipulate the local display framework. When the background processing service acts as the target processing module, because the vehicle system is not fully started, the SurfaceView in the application layer cannot work reliably. Therefore, the processing service directly calls the SurfaceComposerClient to request native window Surface resources, thereby obtaining the Surface object.
[0071] In one possible implementation, the graphic data acquired by the vehicle is processed to obtain a processed image, including:
[0072] The graphic data collected by the vehicle is written into the graphic buffer corresponding to the native window resource, the graphic data in the graphic buffer is rendered, and the graphic buffer is added to the buffer queue after the rendering is completed.
[0073] The image data is retrieved from the image buffer in the buffer queue and synthesized to obtain the processed image.
[0074] In the specific implementation, after the graphics processing interface is called to process the graphics data in the graphics buffer, the graphics buffer can be added to the buffer queue and wait to be displayed. The display compositing service retrieves the graphics data in the graphics buffer from the buffer queue for compositing, which ensures efficient transmission and rendering of graphics data and achieves a smooth user interface experience.
[0075] Figure 3 is a schematic diagram of a producer-consumer model provided in an embodiment of this disclosure. As shown in Figure 3, in the vehicle system, Surface rendering uses a producer-consumer model, which is implemented through Surface and SurfaceFlinger.
[0076] BufferQueue is the link between Surface and SurfaceFlinger Layer. When upper-layer graphics data is rendered to Surface, it is actually rendered to a GraphicBuffer. Then, IGraphicBufferProducer submits the GraphicBuffer to BufferQueue so that SurfaceFlinger can perform subsequent compositing and display work.
[0077] The classic workflow of BufferQueue is as follows:
[0078] The producer requests a free buffer: dequeueBuffer();
[0079] The producer fills the buffer and returns it to the queue: queueBuffer();
[0080] Consumer acquires a buffer: acquireBuffer();
[0081] Once the consumer has finished using it, it returns the buffer to the queue using `releaseBuffer()`.
[0082] Figure 4 is a schematic diagram of the image rendering scene provided in this embodiment of the present disclosure. As shown in Figures 1 and 4, the target processing module responds to the lookaround activation information and requests native window resources through the Window Manager. The target processing module can obtain graphics data from the camera preview, or obtain graphics data captured by the camera from the background through the Native Development Kit (NDK), and write the obtained graphics data into the Surface corresponding to the native window. The GL Consumer consumes the graphics data in the GraphicBuffer, making it usable by OpenGL ES (GL graphics library), thereby enabling the graphics processor (GPU) to process the graphics data. After processing, the IGraphicBufferProducer submits the GraphicBuffer to the BufferQueue (submit graphics buffer), the Surfaceflinger (display compositing service) obtains the graphics data in the BufferQueue for layer management and data processing, and finally the hardware composer composites the data of multiple window layers, rendering the composite image onto the screen through the Direct Rendering Manager (DRM). The Graphics Allocator (Gralloc) module manages the allocation, mapping, and processing of graphics buffers.
[0083] In one possible implementation, before adding the graphics buffer to the buffer queue, the following steps are also included:
[0084] Lock the graphics data in the graphics buffer.
[0085] In the specific implementation, the graphics data in the graphics buffer can be locked before adding the graphics buffer to the buffer queue to prevent the graphics data in the graphics buffer from being tampered with, which would affect the accuracy of the graphics display.
[0086] In some embodiments, the method further includes:
[0087] Obtain the vehicle's surround view disabling information and destroy the native window.
[0088] In practice, the vehicle's surround view shutdown information can include vehicle status information (such as the vehicle's current gear being non-reverse) or a user-input shutdown command. In response to this, the vehicle's infotainment system destroys the native window and ends the surround view display.
[0089] This disclosure also provides an image processing apparatus. Figure 5 is a schematic diagram of the structure of the image processing apparatus provided in this disclosure. As shown in Figure 5, the apparatus includes:
[0090] The acquisition module 51 is used to acquire the vehicle's surround view activation information;
[0091] Create module 52, which uses the surround view activation information to call the corresponding processing module to request native window resources;
[0092] Display module 53 is used to process the graphic data collected by the vehicle to obtain a processed image, and to display the processed image using the native window resources.
[0093] In some embodiments, module 52 is created specifically for:
[0094] Based on the source of the surround view activation information, the target processing module corresponding to the surround view activation information is determined from multiple candidate processing modules;
[0095] Call the target processing module to request native window resources.
[0096] In some embodiments, module 52 is further specifically used for:
[0097] If the surround view activation information is a control command input by the user, then the foreground processing application is determined as the target processing module corresponding to the surround view activation information.
[0098] In some embodiments, module 52 is further specifically used for:
[0099] If the surround view activation information is vehicle status information, then based on the status information, the target processing module corresponding to the surround view activation information is determined from the front-end processing application and the back-end processing service.
[0100] In some embodiments, module 52 is further specifically used for:
[0101] If the vehicle is not fully started, the background processing service is determined as the target processing module corresponding to the surround view activation information;
[0102] If the vehicle has been fully started, the front-end processing application is determined as the target processing module corresponding to the surround view activation information.
[0103] In some embodiments, the background processing service is used to create a Surface object through SurfaceComposerClient and write the graphic data collected by the vehicle into the Surface object;
[0104] The front-end processing application is used to create Surface objects through SurfaceView and write the graphic data collected by the vehicle into the Surface objects.
[0105] In some embodiments, the display module 53 is specifically used for:
[0106] The graphic data collected by the vehicle is written into the graphic buffer corresponding to the native window resource, the graphic data in the graphic buffer is rendered, and the graphic buffer is added to the buffer queue after the rendering is completed.
[0107] The graphic data in the graphic buffer is obtained from the buffer queue and synthesized to obtain the processed image.
[0108] In some embodiments, the display module 53 is further specifically used for:
[0109] Lock the graphics data in the graphics buffer.
[0110] In some embodiments, creation module 52 is further configured to:
[0111] Obtain the vehicle's surround view shutdown information and destroy the native window.
[0112] It should be noted that the image processing device is used to execute the image processing method described above, and its specific implementation is as described above, and will not be repeated here.
[0113] Figure 6 is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. As shown in Figure 6, the electronic device includes:
[0114] The electronic device includes a processor 291 and a memory 292; it may also include a communication interface 293 and a bus 294. The processor 291, memory 292, and communication interface 293 can communicate with each other via the bus 294. The communication interface 293 can be used for information transmission. The processor 291 can invoke logical instructions stored in the memory 292 to execute the methods of the above embodiments.
[0115] Furthermore, the logic instructions in the aforementioned memory 292 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.
[0116] The memory 292, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this disclosure. The processor 291 executes functional applications and data processing by running the software programs, instructions, and modules stored in the memory 292, thereby implementing the methods in the above-described method embodiments.
[0117] The memory 292 may include a program storage area and a data storage area. The program storage area may store the operating system and application programs required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 292 may include high-speed random access memory and may also include non-volatile memory.
[0118] This disclosure provides a non-transitory computer-readable storage medium storing computer-executable instructions that, when executed by a processor, are used to implement the methods described in the foregoing embodiments.
[0119] This disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the methods provided in any of the embodiments described above.
[0120] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.
[0121] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.
Claims
1. An image processing method, comprising: Obtain the vehicle's surround view activation information; Based on the surround view activation information, the corresponding processing module is invoked to request native window resources; The graphic data collected from the vehicle is processed to obtain a processed image, and the processed image is displayed using the native window resource.
2. The method according to claim 1, wherein, The step of calling the corresponding processing module to request native window resources based on the surround view activation information includes: Based on the source of the surround view activation information, the target processing module corresponding to the surround view activation information is determined from multiple candidate processing modules; The target processing module is invoked to request native window resources.
3. The method according to claim 2, wherein, The step of determining the target processing module corresponding to the surround-view activation information from multiple candidate processing modules based on the source of the surround-view activation information includes: If the surround view activation information is a control command input by the user, then the foreground processing application is determined as the target processing module corresponding to the surround view activation information.
4. The method according to claim 2, wherein, The step of determining the target processing module corresponding to the surround-view activation information from multiple candidate processing modules based on the source of the surround-view activation information includes: If the surround view activation information is vehicle status information, then based on the status information, the target processing module corresponding to the surround view activation information is determined from the front-end processing application and the back-end processing service.
5. The method according to claim 4, wherein, The step of determining the target processing module corresponding to the surround-view activation information from the foreground processing application and the background processing service based on the status information includes: If the vehicle is not fully started, the background processing service is determined as the target processing module corresponding to the surround view activation information; If the vehicle has been fully started, the front-end processing application is determined as the target processing module corresponding to the surround view activation information.
6. The method according to claim 5, wherein, The method further includes: When the background processing service acts as the target processing module corresponding to the surround view activation information, it creates a Surface object through SurfaceComposerClient and writes the graphic data collected by the vehicle into the Surface object. When the foreground processing application acts as the target processing module corresponding to the surround view activation information, it creates a Surface object through SurfaceView and writes the graphic data collected by the vehicle into the Surface object.
7. The method according to claim 1, wherein, The process of processing the graphic data collected from the vehicle to obtain the processed image includes: The graphic data collected by the vehicle is written into the graphic buffer corresponding to the native window resource, the graphic data in the graphic buffer is rendered, and the graphic buffer is added to the buffer queue after the rendering is completed. The graphic data in the graphic buffer is obtained from the buffer queue and synthesized to obtain the processed image.
8. The method according to claim 7, wherein, Before adding the graphics buffer to the buffer queue, the method further includes: Lock the graphics data in the graphics buffer.
9. The method according to any one of claims 1-8, wherein, The method further includes: Obtain the vehicle's surround view shutdown information and destroy the native window resources.
10. An image processing apparatus, comprising: The acquisition module is used to acquire the vehicle's surround view activation information; A module is created to call the corresponding processing module to request native window resources based on the surround view activation information; The display module is used to process the graphic data collected by the vehicle to obtain the processed image, and to display the processed image using the native window resources.
11. An electronic device, comprising: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-9.
12. A computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-9.
13. A computer program product comprising computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-9.