CN113727035B - 图像处理方法、系统、电子设备及存储介质 - Google Patents

Abstract

本申请公开了一种图像处理方法、系统、电子设备及存储介质，该图像处理方法包括：相机实现层响应于应用程序发起的调用请求，生成与所述调用请求对应的图像参数，所述相机实现层为基于软件开发工具包的实现层；将所述图像参数下发至硬件抽象层；接收所述硬件抽象层传输的图像数据，所述图像数据由所述硬件抽象层基于所述图像参数从摄像头采集的数据中得到；对所述图像数据进行预设算法处理，并将所述预设算法处理后的图像数据传输至所述应用程序。本方法可以实现应用程序调用相机实现层，即可实现图像拍摄，而不必依赖于硬件抽象层实现拍摄，从而具有较高地通用性。

Description

图像处理方法、系统、电子设备及存储介质

技术领域

本申请涉及图像处理技术领域，更具体地，涉及一种图像处理方法、系统、电子设备及存储介质。

背景技术

随着科技水平和生活水平的快速进步，电子设备(如手机、平板电脑等)已经成为了人们生活中必不可少的电子产品。并且，目前大多数电子设备均具备拍照功能，用户可通过随身携带的电子设备随时记录现实场景中的各种内容。电子设备在实现拍照时通常会基于影像处理的软件架构，从而实现图像预览、拍照以及录像等功能，但是相关的软件架构实现拍摄的通用性较差。

发明内容

鉴于上述问题，本申请提出了一种图像处理方法、系统、电子设备及存储介质。

第一方面，本申请实施例提供了一种图像处理方法，所述方法包括：相机实现层响应于应用程序发起的调用请求，生成与所述调用请求对应的图像参数，所述相机实现层为基于软件开发工具包的实现层；将所述图像参数下发至硬件抽象层；接收所述硬件抽象层传输的图像数据，所述图像数据由所述硬件抽象层基于所述图像参数从摄像头采集的数据中得到；对所述图像数据进行预设算法处理，将所述预设算法处理后的图像数据传输至所述应用程序。

第二方面，本申请实施例提供了一种图像处理系统，所述图像处理系统包括相机实现层、应用程序以及硬件抽象层，所述相机实现层为基于软件开发工具包的实现层，其中，所述应用程序用于向所述相机实现层发起调用请求；所述相机实现层用于响应于所述调用请求，生成与所述调用请求对应的图像参数，并将所述图像参数下发至所述硬件抽象层；所述硬件抽象层用于基于所述图像参数从摄像头采集的数据中得到图像数据，并将所述图像数据发送至所述相机实现层；所述相机实现层还用于对所述图像数据进行预设算法处理，将所述预设算法处理后的图像数据传输至所述应用程序。

第三方面，本申请实施例提供了一种电子设备，包括：一个或多个处理器；存储器；一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于执行上述第一方面提供的图像处理方法。

第四方面，本申请实施例提供了一种计算机可读取存储介质，所述计算机可读取存储介质中存储有程序代码，所述程序代码可被处理器调用执行上述第一方面提供的图像处理方法。

本申请提供的方案，通过相机实现层响应于应用程序发起的调用请求，生成与调用请求对应的图像参数，且该相机实现层为基于软件开发工具包的实现层，将图像参数下发至硬件抽象层，然后接收硬件抽象层传输的图像数据，该图像数据由硬件抽象层基于图像参数从摄像头采集的数据中得到，对图像数据进行预设算法处理，将预设算法处理后的图像数据传输至应用程序。由此，可以将用于实现图像拍摄的相关处理逻辑以及图像处理算法等从硬件抽象层中抽离出来，并基于软件开发工具包实现，从而应用程序仅需要调用软件开发工具包即可实现图像拍摄，图像拍摄的相关算法进行移植时仅需要针对软件开发工具包进行移植即可，从而具备较好地通用性；另外，由于相机实现层基于软件开发工具包实现，因此应用程序实现图像拍摄时的相关算法的调用能够在同一进程中运行，避免了跨进程调用算法，提升了拍摄性能；再者，由于相机实现层基于软件开发工具包实现，因此无论是自研的应用程序或者是第三方的应用程序，都可以调用相机实现层即可实现图像预览、拍照、录像等，可以提升第三方应用程序在拍摄时的实现效果。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了本申请实施例提供的系统架构的一种示意图。

图2示出了根据本申请一个实施例的图像处理方法流程图。

图3示出了根据本申请另一个实施例的图像处理方法流程图。

图4示出了本申请另一个实施例提供的图像处理方法中步骤S220的流程图。

图5示出了根据本申请又一个实施例的图像处理方法流程图。

图6示出了本申请实施例提供的系统架构的另一种示意图。

图7示出了本申请实施例提供的算法处理服务模块的原理示意图。

图8示出了根据本申请再一个实施例的图像处理方法流程图。

图9示出了本申请实施例提供的调用硬件处理模块的原理示意图。

图10示出了本申请实施例提供的系统架构的再一种示意图。

图11示出了根据本申请一个实施例的图像处理系统的一种框图。

图12是本申请实施例的用于执行根据本申请实施例的图像处理方法的电子设备的框图。

图13是本申请实施例的用于保存或者携带实现根据本申请实施例的图像处理方法的程序代码的存储单元。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

影像是一个重要的领域，它广泛存在于手机、电视、手表、安防、交通、医疗等各个行业。其中，软件架构是整个影像的核心之一，它深刻影响着产品竞争力、用户体验、开发效率、技术壁垒等。基于Android、Linux、Windows等系统，各厂商均对进行不同程度的影像软件架构设计。

电子设备中通常安装有操作系统(例如安卓系统)，操作系统的影像处理架构主要包括应用层以及硬件抽象层。应用层(Application layer)可以设置有用于拍照的应用程序(例如系统拍照应用、第三方拍照应用等)；硬件抽象层(Hardware Abstraction Layer，HAL)是位于操作系统内核与硬件电路之间的接口层，其目的在于将硬件抽象化，硬件抽象层设置有硬件抽象模块，以安卓系统为例，该硬件抽象模块为安卓原生模块，如原生相机硬件抽象模块Camera HAL、媒体策略模块和算法管理模块。此外，操作系统中还包括框架层(Framework)、驱动层等，框架层包括各种原生应用的应用接口(如原生相机应用程序接口)、应用服务(如原生相机服务)、框架层接口(如Google HAL3interface)，驱动层包括各种驱动(例如屏幕Display驱动、音频Audio驱动等)，该驱动层用于使能移动终端的各种硬件，例如图像信号处理器ISP+前端图像传感器sensors等。

发明人发现，通常都会把实现预览的算法、拍照的算法(比如美颜处理、滤镜处理、旋转处理、水印处理、虚化处理、高动态范围处理、多帧处理等后处理算法)等中的至少部分算法设置于硬件抽象层，以便应用层的应用程序能够进行灵活的调用。并且，这些算法通常是厂商自研或者按照自身需求委托第三方公司代为研发算法，这些算法会被电子设备的厂商集成到平台厂商开发的HAL层中。由于不同电子设备的厂商使用平台各不相同，HAL架构也各不同，那么电子设备厂商就需要频繁的在不同HAL架构上二次开发集成自研的算法或购买的算法，使其可以在HAL正常运行。因此通用性较差，导致可移植性差，迁移工作量大。

另外，应用层中的应用程序在调用图像拍摄的相关算法时，需要通过跨进程通信(IPC，Inter-Process Communication)调用硬件抽象层中的算法，这就会使每帧图像的处理均会跨进程调用算法，从而导致频繁的进行跨进程通信，导致拍摄性能较低。例如，在预览帧达到60fps(画面每秒传输帧数，Frame Per Second)及以上的时候，每帧都需要调用IPC进行算法处理的话，60帧的话就需要每秒钟跨进程120次，导致预览卡顿，无法达到流畅性预览的要求。

再者，由于操作系统提供的应用程序接口(API，Application ProgrammingInterface)和框架能力没法满足目前电子设备的厂商开发的各种功能，因此各个电子设备的厂商就会在HAL层和Framework层进行各种定制化开发，来实现自己的功能。但是这些定制化的开发各个手机厂家都不同，没有标准化，因此不能开放给三方的应用程序，这样就造成了三方的应用程序和自研应用程序的软件流程差异，没法实现复用，从而导致预览、拍照或录像效果差异大，用户体验差。例如：对于双摄人像模式功能，google在Android系统中没有提供相关的API，但是各个厂商自研的相机应用里都有人像模式，但是三方应用几乎都没有人像模式，导致自研应用和第三方的应用之间的流程存在差异。

针对上述问题，发明人提出了本申请实施例提供的图像处理方法、系统、电子设备以及存储介质，可以将用于实现图像拍摄的相关处理逻辑以及图像处理算法等从硬件抽象层中抽离出来，并基于软件开发工具包实现，从而应用程序仅需要调用软件开发工具包即可实现图像拍摄，图像拍摄的相关算法进行移植时仅需要针对软件开发工具包进行移植即可，从而具备较好地通用性；另外，由于相机实现层基于软件开发工具包实现，因此应用程序实现图像拍摄时的相关算法的调用能够在同一进程中运行，避免了跨进程调用算法，提升了拍摄性能；再者，由于相机实现层基于软件开发工具包实现，因此无论是自研的应用程序或者是第三方的应用程序，都可以调用相机实现层即可实现图像预览、拍照、录像等，可以提升第三方应用程序在拍摄时的实现效果。其中，具体的图像处理方法在后续的实施例中进行详细的说明。

下面先对本申请实施例提供的图像处理算法的系统架构进行介绍。

请参阅图1，图1为本申请实施例提供的一种图像处理算法的系统架构示意图。该系统架构包括应用层420、相机实现层410以及硬件抽象层430。其中，应用层420可以设置有用于拍照的应用程序(APP，Application)，例如系统拍照应用、第三方拍照应用等，应用层中的应用程序通过集成的API接口访问相机实现层410，以实现影像能力；相机实现层410用于实现拍照的影像处理中的应用程序的鉴权、拍摄时下发至硬件抽象层的基础参数的决策处理、摄像头的控制逻辑、相机模式的管理、拍摄预览时的处理、算法处理服务(APS，Algorithm Process Service)等，由此可以将依赖于Framework和HAL的相关软件逻辑、算法、配置文件等分离出来，提升系统架构的通用性。其中，具体的系统架构在后续实施例中进行详细介绍。

请参阅图2，图2示出了本申请一个实施例提供的图像处理方法的流程示意图。在具体的实施例中，所述图像处理方法应用于电子设备。下面将以电子设备为例，说明本实施例的具体流程，当然，可以理解的，本实施例所应用的电子设备可以为智能手机、平板电脑、智能手表、智能眼镜、笔记本电脑等，在此不做限定。下面将针对图2所示的流程进行详细的阐述，所述图像处理方法具体可以包括以下步骤：

步骤S110：相机实现层响应于应用程序发起的调用请求，生成与所述调用请求对应的图像参数，所述相机实现层为基于软件开发工具包的实现层。

在本申请实施例中，应用层中的应用程序在需要进行图像拍摄时，可以通过API接口向相机实现层发起对相机实现层的调用请求，以完成所需的图像拍摄。其中，相机实现层为从依赖于Framework和HAL的相关软件逻辑、图像处理算法、配置文件等抽离出来，并基于软件开发工具包(Software Development Kit，SDK)所构建的实现层。也就是说，相机实现层可以理解为基于SDK的插件，由此，应用层中的应用程序只需要调用该基于SDK的插件，即可实现其需求的图像拍摄。

相机实现层在接收到应用层中的APP所发送的调用请求之后，可以响应于该APP的调用请求，生成与该调用请求的图像参数。该图像参数用于指示硬件抽象层需要从摄像头采集的图像数据中抓取指定数据，以及对相机设备的拍摄参数的控制；指定数据为硬件抽象层未进行任何算法处理的原始数据，且该指定数据用于后续生成调用请求所需的图像，例如，预览图像、拍照图像、录像画面等。其中，调用请求中可以携带有相机模式、图像处理功能的开关控制等，相机模式可以包括照片模式、视频模式、夜景模式、人像模式、慢动作、延时摄影、全景等模式，在此不做限定；图像处理功能可以包括美颜、滤镜、虚化、请求预览数据、请求拍照等，在此不做限定。

在一些实施方式中，以上图像参数可以由相机实现层对调用请求进行解析，从而得到调用请求所需拍摄的图像的相关参数后，再对该相关参数进行转换，得到用于硬件抽象层所需的图像参数。其中，相机实现层对该相关参数进行转换，可以是基于该相关参数，确定硬件抽象层对摄像头进行配置所需的基础参数、预览图像时所需抓取的原始数据流、拍摄时所需抓取的原始数据流等，并基于此，生成硬件抽象层能够识别的图像参数。

在一些实施方式中，相机实现层可以是基于生产者消费者模式的架构。其中，可以根据拍摄的业务对相机实现层分为生产者和消费者两部分业务，生产者业务和消费者业务相互独立，又相互协同。生产者业务是以相机设备的管理、请求的下发为主要模块，从而产生所需的原始图像数据。消费者业务主要是以预览处理、算法处理服务等为主要模块，对原始图像数据进行后处理，从而得到用于提供至应用程序的图像数据。

在一种可能的实施中，相机实现层还可以分层进行设计，将其分为业务层和模块层，业务层用于实现上述的生产者业务和消费者业务，从而实现具体的业务，例如拍照功能、录像功能等；模块层用于实现生产者业务和消费者业务时，为其提供基础能力。可选地，模块层可以包括鉴权模块、相机设备(CameraDevice)管理模块、模式管理模块、参数下发的决策模块、预览处理模块、APS模块等模块。其中，各个模块在后续实施例中进行详细介绍。

步骤S120：将所述图像参数下发至硬件抽象层。

在本申请实施例中，相机实现层在生成与调用请求所对应的图像参数后，则可以将图像参数下发至硬件抽象层。硬件抽象层可以基于接收的图像参数，对相机设备(摄像头)进行配置，和/或，从相机设备所采集的图像数据中抓取与图像参数所对应的图像数据。可选地，硬件抽象层可以为Camera HAL。

在一些实施方式中，图像参数可以包括：预览阶段或者拍摄阶段所对应的图像参数。可以理解地，若调用请求为预览阶段的请求，则图像参数中应当包括用于获取预览数据对应的原始图像数据的参数；若调用请求为拍摄阶段(例如拍照、录像的触发请求等)的请求，则图像参数中应当包括用于获取生成拍摄图像的原始图像数据的参数。由此，硬件抽象层可以在拍摄过程中的不同阶段，基于相机实现层所发送的图像参数，从相机设备采集的数据中获取未经过处理的原始图像数据。

另外，由于在进行图像拍摄时，不同的拍摄需求下，相机设备需要进行不同的配置。因此，图像参数中还可以包括用于配置相机设备的配置参数，该配置参数用于硬件抽象层对相机设备进行配置，以使硬件抽象层能够从相机设备采集的图像数据中抓取所需的原始图像数据。

步骤S130：接收所述硬件抽象层传输的图像数据，所述图像数据由所述硬件抽象层基于所述图像参数从摄像头采集的数据中得到。

在本申请实施例中，相机实现层在下发上述图像参数至硬件抽象层之后，则可以接收到硬件抽象层所传输的图像数据。该图像数据即用于生成返至应用程序的图像数据，其中，该图像数据可以是未经过处理的，并经过后续的处理后返回至应用程序，并由应用程序生成预览图像或者拍摄图像的数据。

步骤S140：对所述图像数据进行预设算法处理，将所述预设算法处理后的图像数据传输至所述应用程序。

在本申请实施例中，相机实现层在接收到硬件抽象层传输的图像数据后，则可以对图像数据进行预设算法处理，由此得到用于传输至应用程序的图像数据，并将预设算法处理后得到的图像数据传输至应用程序。应用程序在接收到硬件抽象层所发送的图像数据后，则可以基于相机实现层进行预设算法处理后的图像数据，生成预览图像进行显示，或者生成拍摄图像进行显示和存储。

在一些实施方式中，预设算法处理可以包括对接收的图像数据进行预览处理、后处理等，其中，预览处理用于生成后续应用程序进行屏幕显示的图像数据；后处理用于执行预览处理或者生成拍摄图像的过程中的算法处理，例如美颜处理、滤镜处理、旋转处理、水印处理、虚化处理、高动态范围处理、多帧处理等图像处理。

本申请实施例提供的图像处理方法，由于在实现拍摄过程的影像处理过程中，整个处理过程中的相关处理逻辑以及图像处理算法均由相机实现层处理，而硬件抽象层只需要进行基础的相机设备的控制，以及抓取所需的原始图像数据，因此影像处理过程不必依赖于在硬件抽象层中增加处理逻辑和处理算法，从而应用程序仅需要调用软件开发工具包即可实现图像拍摄，图像拍摄的相关算法进行移植时仅需要针对软件开发工具包进行移植即可，从而具备较好地通用性。

另外，由于相机实现层基于软件开发工具包实现，因此应用程序实现图像拍摄时的相关算法的调用能够在同一进程中运行，避免了跨进程调用算法，提升了拍摄性能。

再者，由于相机实现层基于软件开发工具包实现，因此无论是自研的应用程序或者是第三方的应用程序，都可以调用相机实现层即可实现图像预览、拍照、录像等，可以提升第三方应用程序在拍摄时的实现效果

请参阅图3，图3示出了本申请另一个实施例提供的图像处理方法的流程示意图。该图像处理方法应用于上述电子设备，下面将针对图3所示的流程进行详细的阐述，所述图像处理方法具体可以包括以下步骤：

步骤S210：所述相机实现层响应于应用程序发起的调用请求，从所述应用程序对应的所述硬件抽象层的数据流中，确定与所述调用请求中的拍摄配置信息对应的数据流作为目标数据流。

在本申请实施例中，调用请求中可以包括拍摄配置信息，拍摄配置信息可以包括用户选择的相机模式、图像处理功能的开关控制信息等。相机模式可以包括照片模式、视频模式、夜景模式、人像模式、慢动作、延时摄影、全景等模式，在此不做限定；图像处理功能可以包括美颜、滤镜、虚化、请求预览数据、请求拍照等，在此不做限定，图像处理功能的开关控制信息即对这些图像处理功能是否开启的信息。相机实现层在接收到应用程序发起的调用请求后，则可以从应用程序对应的硬件抽象层的数据流中，确定与该拍摄配置信息对应的数据流，以便后续根据硬件抽象层返回的原始图像数据，能够生成与调用请求所对应的图像数据返回至应用程序。可以理解地，硬件抽象层中可以包括多个数据流，不同的数据流提供不同的图像数据，由于后续需要得到用于处理获得的与调用请求对应的图像数据，因此，可以基于调用请求中的拍摄配置信息，选取与拍摄配置信息的数据流，并将选取的数据流作为指示硬件抽象层所返回的数据流。

在一些实施方式中，为提升确定上述目标数据流的效率，相机实现层还可以根据应用程序所支持的相机模式以及使用的摄像头，先对数据流进行筛选。请参阅图4，相机实现层从所述应用程序对应的所述硬件抽象层的数据流中，确定与所述拍摄配置信息对应的数据流作为目标数据流，可以包括：

步骤S221：获取所述应用程序对应的所述硬件抽象层的数据流组合，所述数据流组合包括预览数据流以及拍摄数据流。

在该实施方式中，相机实现层可以先获取与应用程序所对应的硬件抽象层的数据流组合。由于实现拍摄过程时，会进行预览后，再响应触发指令进行拍摄，因此相机实现层可以确定出包括预览数据流以及拍摄数据流的数据流组合，以便后续能够确定出与拍摄配置信息对应的预览数据流以及拍摄数据流，分别用于处理得到用于生成预览图像和拍摄图像的图像数据。其中，拍摄数据流可以为拍照流或者录像流。

可选地，相机实现层获取所述应用程序对应的所述硬件抽象层的数据流组合，包括：获取与所述应用程序匹配的摄像头标识以及相机模式标识；从所述硬件抽象层的所有数据流组合中，筛选出与所述摄像头标识以及相机模式标识对应的数据流组合。

其中，应用层中的应用程序可以从支持列表中获取支持的摄像头标识(CameraType)以及相机模式标识(Mode Name)，分别传入相机实现层中。摄像头标识代表特定的摄像头或摄像头组合，相机模式标识代表应用程序通常使用的相机模式，例如照片模式、人像模式、夜景模式等。其中，应用程序通常使用的相机模式可以根据应用程序历史进行拍摄时使用的相机模式确定，例如，可以确定使用次数大于预设次数的相机模式作为应用程序通常使用的相机模式；又例如，可以对各个相机模式的使用次数按照从大到小的顺序进行排序，再根据排序结果确定排前N位的相机模式作为应用程序通常使用的相机模式，其中，N为正整数，N的具体数值可以不做限定。

步骤S222：从所述数据流组合中，获取与所述拍摄配置信息对应的数据流组合，作为目标数据流。

在该实施方式中，相机实现层先筛选出数据流组合后，则可以从数据流组合中确定拍摄配置信息对应的数据流组合，从而得到与拍摄配置信息对应的预览数据流以及拍摄数据流，以便后续处理得到用于生成预览图像和拍摄图像的图像数据。由于确定出的目标数据流与拍摄配置信息对应，因此目标数据流携带着即将进入何种相机模式、开启何种图像处理功能等信息，后续可以进一步地根据目标数据流确定出数据流的配置信息。

步骤S220：获取所述目标数据流所对应的元数据参数。

在本申请实施例中，在确定出与应用程序对应的目标数据流之后，则可以进一步根据目标数据流确定出元数据参数。可以理解地，由于目标数据流携带着即将进入何种相机模式、开启何种图像处理功能等信息，因此可以基于此，确定出数据流组合中每个数据流所包含的元数据参数。元数据参数可以包括通过的buffer(缓存)的图像尺寸、图像格式、Camera ID(相机设备的标识)等信息。

步骤S230：根据所述目标数据流以及所述元数据参数，生成对应的图像参数。

在本申请实施例中，在确定出目标数据流以及元数据参数之后，则可以生成携带有目标数据流以及元数据参数的图像参数，从而后续将图像参数下发至硬件抽象层之后，硬件抽象层能够从相应的目标数据流中，基于元数据参数抓取图像数据以及图像数据对应的元数据，并将对应的图像数据以及图像数据对应的元数据传输至相机实现层。

在一些实施方式中，由于上述的目标数据流可以是确定出的包括预览数据流以及拍摄数据流的数据流组合，因此，可以根据目标数据流以及元数据参数，生成预览阶段或者拍摄阶段所对应的图像参数。也就是说，根据确定出的预览数据流以及元数据参数，生成预览阶段所对应的图像参数；根据确定出的拍摄数据流以及元数据参数，生成拍摄阶段所对应的图像参数。

需要说明的是，本申请实施例提供的图像处理方法中步骤S210至步骤S230的内容即对应其他实施例中所讲的参数下发的决策模块，即本申请实施例提供的相机实现层的模块层中的决策模块，其他实施例中的决策模块的实现方式可以参阅本申请实施例的内容。

步骤S240：将所述图像参数下发至硬件抽象层。

步骤S250：接收所述硬件抽象层传输的图像数据，所述图像数据由所述硬件抽象层基于所述图像参数从摄像头采集的数据中得到。

步骤S260：对所述图像数据进行预设算法处理，并将所述预设算法处理后的图像数据传输至所述应用程序。

在本申请实施例中，步骤S240至步骤S260可以参阅前述实施例的内容，在此不再赘述。

本申请实施例提供的图像处理方法，在由相机实现层执行拍摄过程中对硬件抽象层的请求下发时，基于调用请求中的拍摄配置信息，从硬件抽象层的数据流中获取拍摄配置信息对应的数据流，并基于确定出的数据流及其对应的元数据参数，生成图像参数，由此，可以实现硬件抽象层能够从相应的数据流中抓取对应的原始图像数据返回至相机实现层，而无需硬件抽象层进行过多的软件逻辑和算法处理，即可实现图像拍摄的影像处理，从而影像处理过程不必依赖于在硬件抽象层中增加处理逻辑和处理算法，进而应用程序仅需要调用软件开发工具包即可实现图像拍摄，图像拍摄的相关算法进行移植时仅需要针对软件开发工具包进行移植即可，从而具备较好地通用性。

请参阅图5，图5示出了本申请又一个实施例提供的图像处理方法的流程示意图。该图像处理方法应用于上述电子设备，下面将针对图5所示的流程进行详细的阐述，所述图像处理方法具体可以包括以下步骤：

步骤S310：所述相机实现层响应于应用程序发起的调用请求，基于所述应用程序的应用信息，对所述应用程序进行权限验证，所述相机实现层为基于软件开发工具包的实现层。

在本申请实施例中，考虑到将原本硬件抽象层中增加的处理逻辑和处理算法被抽离出来，由相机实现层实现，应用程序对相机实现层进行调用即可实现图像拍摄，而一些应用程序可能为恶意应用等情况，若可以任意调用相机实现层，则可能导致用户隐私泄露，甚至影响用户的人生财产安全。因此，相机实现层接收到应用程序发起的调用请求时，还可以对应用程序进行权限验证，以避免恶意调用相机实现层的情况出现。其中，相机实现层可以获取应用程序的应用信息，并基于应用程序的应用信息，对应用程序进行权限验证。

在一些实施方式中，应用信息可以包括：应用程序的包名、应用程序的签名、应用程序所申请的key(密钥)合法性、应用程序申请的key有效期、应用程序所申请的权限类别、应用程序是否被撤销权限、应用程序所申请key的生效机型等，在此不做限定。对应用程序进行权限验证，权限验证通过的条件可以包括以下条件中的一种或者多种：包名为预设白名单中的包名、应用程序的签名合法、应用程序所申请的key合法、应用程序申请的key有效期未过期、应用程序所申请的权限类别包括拍摄权限、应用程序未被撤销权限、应用程序所申请key的生效机型为该电子设备的机型等。

步骤S320：若权限验证通过，生成与所述调用请求对应的图像参数。

在本申请实施例中，若对应用程序进行权限验证后，确定权限验证通过时，则可以执行生成与调用请求对应的图像参数等后续步骤，以完成图像拍摄的过程。

在本申请实施例中，相机实现层在接收到应用程序发起的调用请求后，可以先向硬件抽象层发送用于开启调用请求对应的指定摄像头的开启请求，开启请求用于指示硬件抽象层控制指定摄像头处于开启状态。可以理解地，在执行拍摄过程时，首先需要开启摄像头再进行图像预览、图像拍摄的过程，因此可以接收到调用请求后，可以先控制调用请求所需的指定摄像头开启，例如，若调用请求为通过前置摄像头进行图像拍摄的请求，则可以控制前置摄像头开启。

在一些实施方式中，相机实现层对于每次打开的摄像头可以进行统一的管理。在第一次打开指定摄像头时，可以创建开启该指定摄像头对应的session(会话)对象，发送用于开启调用请求对应的指定摄像头的开启请求，以控制指定摄像头开启。在进行指令的执行时，会分发给该指定摄像头执行，例如执行拍照指令。在该指定摄像头处于开启状态的情况下，若相机实现层接收到应用程序发送的模式切换请求，则可以确定相机模式切换请求对应切换至的相机模式所对应的指定摄像头是否为该处于开启状态的指定摄像头；若是该处于开启状态的指定摄像头，则可以保持该指定摄像头处于开启状态。例如，由照片模式切换到视频模式，若视频模式所使用的摄像头与当前开启的摄像头为同一个，但是所处的相机模式不一样，即功能不一样，例如照片模式用的是拍照，视频模式使用的是录像，那么采用该实施方式，则可以在切换模式的时候，摄像头不进行关闭后再重新打开，只是功能进行切换，由此可以避免重复的开启和关闭摄像头，提升图像拍摄的性能。

另外，在需要重新打开摄像头时，则可以关闭摄像头后，再次打开该摄像头；另外，需要重新创建session对象时，可以关闭此前的session对象，然后再创建session对象，然后进行图像拍摄。可选地，可以首先判断是否需要重新打开摄像头，若是，则可以重新打开摄像头后，再执行判断是否重新创建session对象；若不需要重新打开摄像头，则可以直接执行判断是否重新创建session对象；若重新创建session对象，则可以执行重新创建session对象，然后进行图像拍摄。

在一些实施方式中，对应用程序进行权限验证可以包括两次鉴权。其中，第一次鉴权可以是通过相机实现层中的检查权限模块进行鉴权，本次鉴权可以使用本地缓存鉴权；第二次鉴权为在系统Camera Server(相机服务)进程中的鉴权模块进行验证，此时则可以根据上述的应用信息进行鉴权，从而保证鉴权的安全性，防止出现安全漏洞。实际应用时，由于应用程序在调用相机实现层进行图像拍摄时，会首先打开相机设备(摄像头)，再进行图像预览、图像拍摄的过程，因此，第一次鉴权可以在刚刚接收到调用请求时执行，并向应用程序返回鉴权结果，若通过，则执行摄像头的开启，若否，则结束流程，并向应用程序返回权限验证结果；在摄像头开启后，则可以执行第二次鉴权，以进一步保证安全性。如图6所示，应用层410中的应用程序通过API接口层440调用相机实现层时，相机实现层410的检查权限模块会调用鉴权模块进行权限验证，并返回结果，如果验证通过，可以打开摄像头，此时，可以在相机服务(Camera Server)层450进程进行第二次鉴权，保证安全性。

另外，相机实现层中还可以包括模式管理模块。模式管理模块用于实现管理不同的相机模式，例如照片模式、视频模式、夜景模式、人像模式、慢动作、延时摄影、全景等模式。

步骤S330：将所述图像参数下发至硬件抽象层。

在一些实施方式中，由于通常影像处理的系统架构中主要包括应用层、框架层以及硬件抽象层，各个层级间相互协作完成影像处理的正常运行。其中，各个层级间通常会通过标签传递的方式进行通信，其中，Android系统中设计了jarTag作为各层级之间传递的参数，用于各层级之间信息或指令的传达。但是，各个平台厂商自定义一些标签，例如平台厂商A的标签、平台厂商B的科标签，各个电子设备的厂商也会自定义一些标签，例如设备厂商A的标签、设备厂商B的标签、设备厂商C的标签等，这样就导致标签差异很大，碎片化很严重，从而导致通用性不高。因此，为了实现本申请实施例中相机实现层的通用性，可以使各个层级的传递参数进行通用化，由此保证相机实现层能够通用。

其中，相机实现层在下发图像参数至硬件抽象层时，可以根据硬件抽象层对应的平台信息，将该图像参数对应的传递参数转换为指定参数后，再将指定参数下发至硬件抽象层，由此，不同平台所研发的硬件抽象层，本申请实施例中的相机实现层均可以通用，从而提高整体系统架构的通用性和可移植性。该传递参数以及指定参数均可以为供应商标签(VendorTag)类型。

可选地，可以利用不同平台信息对应的平台转换器，将上述传递参数修改为指定参数。例如，若获取到平台信息为平台A，则使用平台A对应的平台转换器进行参数转换。

作为一种可能的实施方式，不同平台信息对应的平台转换器可以预置在转换模块的Java归档包JAR中，当获取到平台信息后，可以直接从该Java归档包中调取出对应的平台转换器进行使用。例如，若转换模块获取到平台信息为平台A，则从该Java归档包中调取出平台A的平台转换器进行参数转换。

作为另一种可能的实施方式，上述平台信息对应的平台转换器还可以从网络服务器上获取。可以将不同平台信息对应的平台转换器存放在网络服务器中，当该转换模块获取到平台信息后，可以通过网络连接服务器，从服务器上获取到对应的平台转换器。例如，若转换模块获取到平台信息为平台A，则从服务器中获取平台A的平台转换器，将该平台A的平台转换器下载到该电子设备，再利用该OPPO平台转换器进行参数转换。

作为再一种可能的实施方式，上述平台信息对应的平台转换器还可以从该电子设备的系统中获取。由于，电子设备可能具有不止一种平台信息，所以需要通过确定的平台信息来获取对应的平台转换器。例如，若转换模块获取到平台信息为平台A，则从该电子产品的系统中调取出平台A的平台转换器进行参数转换。

作为还一种可能的实施方式，上述平台信息对应的平台转换器还可以从外部其他设备导入。可以将不同平台信息对应的平台转换器存放在外部设备中，当该转换模块获取到平台信息后，可以通过网络从该外部设备(例如服务器等)，从该外部设备上获取到对应的平台转换器。

当然，本申请实施例中提供的参数转换的方式也同样可以适用于其他实施例中；并且，应用层与硬件抽象层、框架层进行其他的指令和信息的传输时，也可以同样采用该参数转换的方式，对参数转换后再进行传输，由此可以提升整个系统架构的通用性。

步骤S340：接收所述硬件抽象层传输的图像数据，所述图像数据由所述硬件抽象层基于所述图像参数从摄像头采集的数据中得到。

在本申请实施例中，步骤S340可以参阅其他实施例的内容，在此不再赘述。

步骤S350：利用算法处理服务模块，并根据所述拍摄配置信息对所述原始图像数据以及所述元数据进行对应的预设算法处理。

在本申请实施例中，相机实现层中可以包括算法处理服务(APS，AlgorithmProcess Service)模块，在对硬件抽象层传输的图像数据进行预设算法处理时，可以通过APS模块，并根据拍摄配置信息对原始图像数据以及元数据进行对应的预设算法处理。其中，可以根据拍摄配置信息，确定使用的预设处理算法。

在一些实施方式中，请参阅图7，相机实现层中可以包括APS接入模块、APS适配(Adapter)模块以及APS模块。其中，APS接入模块层为顶层模块接口，用于此模块与其他模块间解耦，从其他模块获取到硬件抽象层传输的预览数据及预览meta(元数据)、拍照数据及拍照元数据、录像数据及录像元数据；APS Adapter模块用于对预览数据及预览meta、拍照数据及拍照meta、录像数据及录像meta进行时间戳匹配、buffer转换、meta预处理等；APS模块用于对输入的预览、拍照及录像数据进行算法处理，并返回处理后的数据。APS模块中执行的算法处理可以为后处理算法执行的处理，例如，美颜处理、滤镜处理、旋转处理、水印处理、虚化处理、高动态范围处理、多帧处理等图像处理，在此不做限定。

在本申请实施例中，相机实现层中还可以包括预览处理模块，预览处理模块用于处理得到用于应用程序屏幕显示的预览图像的图像数据。预览处理模块用于进行预览GPU算法处理，接收外部传入的图像数据，图像数据可以为YUV数据(Y为图像亮度数据，U和V为图像色度数据)或者HardwareBuffer，然后经过绑定纹理，再调用算法进行处理，最后输出到输出纹理上，从而可以供应用程序进行屏幕显示或二次特效处理。可选地，调用算法进行处理可以利用APS模块实现。

由于本模块算法需要图形处理器(Graphics Processing Unit，GPU)处理，而大部分的输入buffer都是中央处理器(Central Processing Unit，CPU)访问的buffer，因此相关技术中，通常是先把CPU访问的buffer拷贝到GPU访问的buffer，然后再进行GPU算法处理，需要进行buffer拷贝，这样的话，效率较低。因此，在实现预览处理模块时，可以采用共享buffer的方式实现，可以实现CPU访问的Buffer共享给GPU使用，不需要进行拷贝，整体流程效率更高。

可选地，从硬件抽象层传输的图像数据(预览数据)可以通过ImageReader传递到应用程序，应用程序可以从ImageReader中获取image(图像)，再从image获取到HardwareBuffer；拿到HardwareBuffer后先通过eglGetNativeClientBufferANDROID创建EGLClientBuffer，再通过eglCreateImageKHR把EGLClientBuffer转换成EGLImageKHR，最后再通过glEGLImageTargetTexture2DOES接口把EGLImageKHR和OES纹理进行绑定，从而实现HardwareBuffer直接复用，避免进行buffer拷贝，性能更好。其中，ImageReader类允许应用程序直接访问呈现表面的图像数据，因此可以基于此传递图像数据至应用程序；HardwareBuffer指的是硬件缓存数据，例如像素缓存、顶点缓存、索引缓存等数据；eglGetNativeClientBufferANDROID是EGL(渲染API和原生窗口系统之间的接口)的扩展，基于该扩展可以创建EGL的图像数据缓冲区，即EGLClientBuffer；eglCreateImageKHR用于创建EGLImageKHR对象，EGLImageKHR对象用于将纹理数据进行封装为相应格式，由此，glEGLImageTargetTexture2DOES接口将EGLImageKHR与纹理数据绑定后，能够实现纹理更新。

步骤S360：将所述预设算法处理后的图像数据传输至所述应用程序。

在本申请实施例中，在得到预设算法处理后的图像数据后，则可以将预设算法处理后的图像数据传输至应用程序。

本申请实施例提供的图像处理方法，相机实现层在接收到应用层中应用程序下发的调用请求时，可以对应用程序进行权限验证后，再响应调用请求，进行后续处理，由此保证了相机实现层被调用时的安全性。再者，在相机实现层中设置了算法处理服务模块，对硬件抽象层传输的原始数据进行预设图像处理，因此能够实现对原始数据的算法处理能够由相机实现层实现，而不必在硬件抽象层增加算法处理，因此可以提升通用性。

请参阅图8，图8示出了本申请再一个实施例提供的图像处理方法的流程示意图。该图像处理方法应用于上述电子设备，下面将针对图8所示的流程进行详细的阐述，所述图像处理方法具体可以包括以下步骤：

步骤S410：相机实现层响应于应用程序发起的调用请求，生成与所述调用请求对应的图像参数，所述相机实现层为基于软件开发工具包的实现层。

步骤S420：将所述图像参数下发至硬件抽象层。

步骤S430：接收所述硬件抽象层传输的图像数据，所述图像数据由所述硬件抽象层基于所述图像参数从摄像头采集的数据中得到。

在本申请实施例中，步骤S410至步骤S430可以参阅其他实施例的内容，在此不再赘述。

步骤S440：若对所述图像数据的预设算法处理包括由指定硬件处理模块对应的算法处理，利用预置于相机框架层的指定静态库文件调用所述相机框架层的第一动态库文件。

步骤S450：利用所述第一动态库文件调用vendor层中的第二动态库文件。

步骤S460：利用所述第二动态库文件调用所述指定硬件处理模块对应的算法处理文件，以对所述图像数据进行所述指定硬件处理模块对应的算法处理。

在本申请实施例中，由于操作系统规定了在APP层、Framework层及Vendor层(供应商实现层)之间访问的规则，APP层必须要通过硬件抽象层接口定义语言(HIDL，HALinterface definition language)的方式进行访问Vendor层的数字信号处理(DigitalSignal Processing，DSP)、高通骁龙神经处理引擎(Snapdragon Neural ProcessingEngine，SNPE)等硬件。Vendor供应商实现层指的是平台厂商提供的效果实现层，不同平台的平台效果不同，这里不对各类平台效果实现展开叙述。如此的话，则需要跨进程进行通信，会影响处理性能。因此，在相机实现层调用指定硬件处理模块对应的算法处理时，可以对调用方式进行转换，以保证同一进程内即可实现调用指定硬件处理模块对应的算法处理，对图像数据进行处理，指定硬件处理模块可以为DSP、SNPE等硬件模块。首先，可以利用预置于相机框架层的指定静态库文件调用相机框架层的第一动态库文件。其中，指定静态库文件为jar类型的库文件，第一动态库文件为so类型的库文件。然后，在调用第一动态库文件后，则可以利用第一动态库文件调用vendor层中的第二动态库文件，第二动态库文件可以为so类型的库文件；最后，利用第二动态库文件调用指定硬件处理模块对应的算法处理文件，以对图像数据进行指定硬件处理模块对应的算法处理。jar类型的库文件是java的一种文档格式，jar类型的库文件为静态库的文件，静态库在程序编译时会被连接到目标代码中，程序运行时将不再需要该静态库；so型的库文件是Linux系统的可执行文件，其可以在Linux系统运行，so类型的库文件为动态库的文件，动态库在程序编译时并不会被连接到目标代码中，而是在程序运行是才被载入，因此在程序运行时还需要动态库存在。

示例性地，请参阅图9，首先，访问预置在framework层中的a.jar，然后a.jar再调用framework层的a-jni.so，此a-jni.so再访问vendor层的a.so，最终vendor层的a.so再调用平台硬件相关的DSP、SNPE等库。在整个流程中，所有jar包、so库均运行在APP进程内，因为没有跨进程消耗，所以性能更优，特别是在预览帧率为30fps、60fps、120fps等情况下性能更好。可以理解地，通过在framework层和vendor层分别做一次中转，实现符合系统的限制要求，从而能够实现同进程访问。

步骤S470：将所述预设算法处理后的图像数据传输至所述应用程序。

本申请实施例提供的图像处理方法，在实现应用程序仅需要调用软件开发工具包即可实现图像拍摄，图像拍摄的相关算法进行移植时仅需要针对软件开发工具包进行移植即可，从而具备较好地通用性。另外，执行对图像数据的算法处理，对硬件模块进行调用时，通过调用文件的转换，使得对硬件模块的调用可以与相机实现层能够在同一进程运行，避免了跨进程调用，提升了处理效率。

下面结合本申请实施例提供的图像处理算法的系统架构图，对前述实施例提供的图像处理方法所结合的实施方式进行介绍。

如图10所示，该系统架构可以包括应用层420、API接口层4400、相机实现层410、Camera Server(相机服务)层450、以及硬件抽象层430。应用层420支持系统应用和三方应用接入，通过集成API包进行访问相机实现层410；API接口层440对Camera2API进行封装，提供统一的抽象接口，通过相机模式标识和摄像头标识的组合方式进行影像能力的接入，API接口层440以AAR包方式存在，用于提供给三方APP或自研APP集成、编译，以达到功能调用的目的。相机实现层410可以包括生产者模块及消费者模块，生产者模块由模块层中的鉴权模块、相机设备(CameraDevice)管理模块、模式管理模块、和参数下发的决策模块实现，消费者模块由预览处理模块、APS接入模块、APS适配(Adapter)模块以及APS模块实现。其中，相机实现层410的各个模块、相机服务层450、以及硬件抽象层430可以参阅前述实施例的内容，在此不再赘述。

请参阅图11，其示出了本申请实施例提供的一种图像处理系统400的结构框图。该图像处理系统400应用上述的电子设备，该图像处理系统400包括：相机实现层410、应用程序421以及硬件抽象层430，所述相机实现层410为基于软件开发工具包的实现层。其中，所述应用程序421用于向所述相机实现层410发起调用请求；所述相机实现层410用于响应于所述调用请求，生成与所述调用请求对应的图像参数，并将所述图像参数下发至所述硬件抽象层430；所述硬件抽象层430用于基于所述图像参数从摄像头采集的数据中得到图像数据，并将所述图像数据发送至所述相机实现层410；所述相机实现层410还用于对所述图像数据进行预设算法处理，将所述预设算法处理后的图像数据传输至所述应用程序421。

在一些实施方式中，所述调用请求中包括拍摄配置信息。相机实现层410可以用于：响应于应用程序421发起的调用请求，从所述应用程序421对应的所述硬件抽象层430的数据流中，确定与所述拍摄配置信息对应的数据流作为目标数据流；获取所述目标数据流所对应的元数据参数；根据所述目标数据流以及所述元数据参数，生成对应的图像参数。

作为一种可能的实施方式，相机实现层410从所述应用程序421对应的所述硬件抽象层430的数据流中，确定与所述拍摄配置信息对应的数据流作为目标数据流，可以包括：获取所述应用程序421对应的所述硬件抽象层430的数据流组合，所述数据流组合包括预览数据流以及拍摄数据流；从所述数据流组合中，获取与所述拍摄配置信息对应的数据流组合，作为目标数据流。

可选地，相机实现层410获取所述应用程序421对应的所述硬件抽象层430的数据流组合，可以包括：获取与所述应用程序421匹配的摄像头标识以及相机模式标识；从所述硬件抽象层430的所有数据流组合中，筛选出与所述摄像头标识以及相机模式标识对应的数据流组合。

作为一种可能的实施方式，相机实现层410根据所述目标数据流以及所述元数据参数，生成对应的图像参数，可以包括：根据所述目标数据流以及所述元数据参数，生成预览阶段或者拍摄阶段所对应的图像参数。

在一些实施方式中，相机实现层410可以具体用于：响应于应用程序421发起的调用请求，基于所述应用程序421的应用信息，对所述应用程序421进行权限验证；若权限验证通过，生成与所述调用请求对应的图像参数。

在一些实施方式中，相机实现层410还可以用于：响应于应用程序421发起的调用请求，向所述硬件抽象层430发送用于开启所述调用请求对应的指定摄像头的开启请求，所述开启请求用于指示所述硬件抽象层430控制所述指定摄像头处于开启状态。

在一种可能的实施方式中，相机实现层410还可以用于在所述响应于应用程序421发起的调用请求，生成与所述调用请求对应的图像参数之后，在所述指定摄像头处于开启状态的情况下，所述相机实现层410接收到所述应用程序421发送的模式切换请求；若所述模式切换请求对应切换的相机模式对应的摄像头为所述指定摄像头，则保持所述指定摄像头处于开启状态。

在一些实施方式中，所述调用请求中包括拍摄配置信息，所述图像数据包括原始图像数据以及所述原始图像数据对应的元数据，所述相机实现层410包括算法处理服务模块。相机实现层410可以具体用于：利用所述算法处理服务模块，并根据所述拍摄配置信息对所述原始图像数据以及所述元数据进行对应的预设算法处理；将所述预设算法处理后的图像数据传输至所述应用程序421。

在一些实施方式中，相机实现层410可以具体用于：若所述预设算法处理包括由指定硬件处理模块对应的算法处理，利用预置于相机框架层的指定静态库文件调用所述相机框架层的第一动态库文件；利用所述第一动态库文件调用vendor层中的第二动态库文件；利用所述第二动态库文件调用所述指定硬件处理模块对应的算法处理文件，以对所述图像数据进行所述指定硬件处理模块对应的算法处理。

作为一种可能的实施方式，所述指定静态库文件为jar类型的库文件，所述第一动态库文件以及所述第二动态库文件为so类型的库文件。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述系统和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，模块相互之间的耦合可以是电性，机械或其它形式的耦合。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

综上所述，本申请提供的方案，通过相机实现层响应于应用程序发起的调用请求，生成与调用请求对应的图像参数，且该相机实现层为基于软件开发工具包的实现层，将图像参数下发至硬件抽象层，然后接收硬件抽象层传输的图像数据，该图像数据由硬件抽象层基于图像参数从摄像头采集的数据中得到，对图像数据进行预设算法处理，将预设算法处理后的图像数据传输至应用程序。由此，可以将用于实现图像拍摄的相关处理逻辑以及图像处理算法等从硬件抽象层中抽离出来，并基于软件开发工具包实现，从而应用程序仅需要调用软件开发工具包即可实现图像拍摄，图像拍摄的相关算法进行移植时仅需要针对软件开发工具包进行移植即可，从而具备较好地通用性；另外，由于相机实现层基于软件开发工具包实现，因此应用程序实现图像拍摄时的相关算法的调用能够在同一进程中运行，避免了跨进程调用算法，提升了拍摄性能；再者，由于相机实现层基于软件开发工具包实现，因此无论是自研的应用程序或者是第三方的应用程序，都可以调用相机实现层即可实现图像预览、拍照、录像等，可以提升第三方应用程序在拍摄时的实现效果。

请参考图12，其示出了本申请实施例提供的一种电子设备的结构框图。该电子设备100可以是智能手机、平板电脑、智能手表、智能眼镜、笔记本电脑等能够运行应用程序的电子设备。本申请中的电子设备100可以包括一个或多个如下部件：处理器110、存储器120、以及一个或多个应用程序，其中一个或多个应用程序可以被存储在存储器120中并被配置为由一个或多个处理器110执行，一个或多个程序配置用于执行如前述方法实施例所描述的方法。

处理器110可以包括一个或者多个处理核。处理器110利用各种接口和线路连接整个电子设备100内的各个部分，通过运行或执行存储在存储器120内的指令、程序、代码集或指令集，以及调用存储在存储器120内的数据，执行电子设备100的各种功能和处理数据。可选地，处理器110可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、可编程逻辑阵列(Programmable LogicArray，PLA)中的至少一种硬件形式来实现。处理器110可集成中央处理器(CentralProcessing Unit，CPU)、图形处理器(Graphics Processing Unit，GPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器110中，单独通过一块通信芯片进行实现。

存储器120可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory)。存储器120可用于存储指令、程序、代码、代码集或指令集。存储器120可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等。存储数据区还可以存储电子设备100在使用中所创建的数据(比如电话本、音视频数据、聊天记录数据)等。

请参考图13，其示出了本申请实施例提供的一种计算机可读存储介质的结构框图。该计算机可读介质800中存储有程序代码，所述程序代码可被处理器调用执行上述方法实施例中所描述的方法。

计算机可读存储介质800可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。可选地，计算机可读存储介质800包括非易失性计算机可读介质(non-transitory computer-readable storage medium)。计算机可读存储介质800具有执行上述方法中的任何方法步骤的程序代码810的存储空间。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。程序代码810可以例如以适当形式进行压缩。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不驱使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (14)

1.一种图像处理方法，其特征在于，所述方法包括：

相机实现层响应于应用程序发起的调用请求，生成与所述调用请求对应的图像参数，所述相机实现层为基于软件开发工具包的实现层；

所述相机实现层将所述图像参数下发至硬件抽象层；

所述相机实现层接收所述硬件抽象层传输的图像数据，所述图像数据由所述硬件抽象层基于所述图像参数从摄像头采集的数据中得到；

所述相机实现层对所述图像数据进行预设算法处理，并将所述预设算法处理后的图像数据传输至所述应用程序。

2.根据权利要求1所述的方法，其特征在于，所述调用请求中包括拍摄配置信息，所述相机实现层响应于应用程序发起的调用请求，生成与所述调用请求对应的图像参数，包括：

所述相机实现层响应于应用程序发起的调用请求，从所述应用程序对应的所述硬件抽象层的数据流中，确定与所述拍摄配置信息对应的数据流作为目标数据流；

获取所述目标数据流所对应的元数据参数；

根据所述目标数据流以及所述元数据参数，生成对应的图像参数。

3.根据权利要求2所述的方法，其特征在于，所述从所述应用程序对应的所述硬件抽象层的数据流中，确定与所述拍摄配置信息对应的数据流作为目标数据流，包括：

获取所述应用程序对应的所述硬件抽象层的数据流组合，所述数据流组合包括预览数据流以及拍摄数据流；

从所述数据流组合中，获取与所述拍摄配置信息对应的数据流组合，作为目标数据流。

4.根据权利要求3所述的方法，其特征在于，所述获取所述应用程序对应的所述硬件抽象层的数据流组合，包括：

获取与所述应用程序匹配的摄像头标识以及相机模式标识；

从所述硬件抽象层的所有数据流组合中，筛选出与所述摄像头标识以及相机模式标识对应的数据流组合。

5.根据权利要求2所述的方法，其特征在于，所述根据所述目标数据流以及所述元数据参数，生成对应的图像参数，包括：

根据所述目标数据流以及所述元数据参数，生成预览阶段或者拍摄阶段所对应的图像参数。

6.根据权利要求1所述的方法，其特征在于，所述相机实现层响应于应用程序发起的调用请求，生成与所述调用请求对应的图像参数，包括：

所述相机实现层响应于应用程序发起的调用请求，基于所述应用程序的应用信息，对所述应用程序进行权限验证；

若权限验证通过，生成与所述调用请求对应的图像参数。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述相机实现层响应于应用程序发起的调用请求，向所述硬件抽象层发送用于开启所述调用请求对应的指定摄像头的开启请求，所述开启请求用于指示所述硬件抽象层控制所述指定摄像头处于开启状态。

8.根据权利要求7所述的方法，其特征在于，在所述相机实现层响应于应用程序发起的调用请求，生成与所述调用请求对应的图像参数之后，所述方法还包括：

在所述指定摄像头处于开启状态的情况下，所述相机实现层接收到所述应用程序发送的模式切换请求；

若所述模式切换请求对应切换的相机模式对应的摄像头为所述指定摄像头，则保持所述指定摄像头处于开启状态。

9.根据权利要求1所述的方法，其特征在于，所述调用请求中包括拍摄配置信息，所述图像数据包括原始图像数据以及所述原始图像数据对应的元数据，所述相机实现层包括算法处理服务模块，所述相机实现层对所述图像数据进行预设算法处理，并将所述预设算法处理后的图像数据传输至所述应用程序，包括：

所述相机实现层利用所述算法处理服务模块，并根据所述拍摄配置信息对所述原始图像数据以及所述元数据进行对应的预设算法处理；

将所述预设算法处理后的图像数据传输至所述应用程序。

10.根据权利要求1-9任一项所述的方法，其特征在于，所述相机实现层对所述图像数据进行预设算法处理，包括：

若所述预设算法处理包括由指定硬件处理模块对应的算法处理，所述相机实现层利用预置于相机框架层的指定静态库文件调用所述相机框架层的第一动态库文件；

利用所述第一动态库文件调用vendor层中的第二动态库文件；

利用所述第二动态库文件调用所述指定硬件处理模块对应的算法处理文件，以对所述图像数据进行所述指定硬件处理模块对应的算法处理。

11.根据权利要求10所述的方法，其特征在于，所述指定静态库文件为jar类型的库文件，所述第一动态库文件以及所述第二动态库文件为so类型的库文件。

12.一种图像处理系统，其特征在于，所述图像处理系统包括相机实现层、应用程序以及硬件抽象层，所述相机实现层为基于软件开发工具包的实现层，其中，

所述应用程序用于向所述相机实现层发起调用请求；

所述相机实现层用于响应于所述调用请求，生成与所述调用请求对应的图像参数，并将所述图像参数下发至所述硬件抽象层；

所述硬件抽象层用于基于所述图像参数从摄像头采集的数据中得到图像数据，并将所述图像数据发送至所述相机实现层；

所述相机实现层还用于对所述图像数据进行预设算法处理，并将所述预设算法处理后的图像数据传输至所述应用程序。

13.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储器；

一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于执行如权利要求1-11任一项所述的方法。

14.一种计算机可读取存储介质，其特征在于，所述计算机可读取存储介质中存储有程序代码，所述程序代码可被处理器调用执行如权利要求1-11任一项所述的方法。

Images