一种基于阻塞队列的多源抓拍图像处理、接入方法及装置与流程

文档序号:19792043发布日期:2020-01-24 14:27阅读:133来源:国知局
本发明涉及数据处理
技术领域
,具体而言,涉及一种基于阻塞队列的多源抓拍图像处理、接入方法及装置。
背景技术
:随着计算机技术和信息技术的日益发展,图像识别技术也越来越多的被人们关注,且在未来的发展中会有更广阔的应用空间,无论医疗、安检以及信息搜集等领域,都会更加依赖于图像识别技术。图像识别技术在日常生活中的应用也越来越广泛,例如各种人脸识别系统、车辆识别系统等。现有的人脸识别应用系统是将各类摄像头或相机设备进行抓拍,并将抓拍图像直接接入到系统中,通过专用算法对视频流进行抽帧解析和识别,进而进行下一步的人脸识别告警或研判分析应用。但行业现状是很多情况下,人脸识别应用系统只是整个大的集成项目中的一部分,无法直接接入各类摄像头,只能根据其他厂商的系统或硬件产生的抓拍数据进行后续应用。导致现有的人脸识别应用系统需要针对不同的厂商开发不同的抓拍数据接入程序,而且对于多源抓拍图像的处理也很不方便,导致人脸识别应用系统对接第三方的系统复杂度很高。技术实现要素:本发明旨在至少在一定程度上解决相关技术中的技术问题,为达上述目的,本发明第一方面的实施例提供了一种基于阻塞队列的多源抓拍图像处理方法,其包括:获取多个数据源的抓拍图像,并将所述抓拍图像存储在数据缓存池中,其中,所述抓拍图像按照预定的数据格式进行获取;按预设时间间隔从所述数据缓存池中取出所述抓拍图像进行预处理;对所述预处理后的抓拍图像进行归一化处理。进一步地,对不同数据源的抓拍图像定义相同的数据格式。进一步地,所述预定的数据格式包括所述抓拍图像的编号、所述抓拍图像的存储路径、抓拍时间以及抓拍设备的编号。进一步地,所述预定的数据格式包括所述抓拍图像的编号、所述抓拍图像的base64值、抓拍时间以及抓拍摄像头的编号。进一步地,所述数据缓存池包括阻塞队列,用于存储从所述多个数据源获取的所述抓拍图像。进一步地,在所述预设时间间隔内若所述数据缓存池未存满,则不对所述数据缓存池中的所述抓拍图像进行预处理。进一步地,所述预处理包括对所述抓拍图像的特征区域提取。进一步地,所述特征区域包括所述抓拍图像中的人脸区域。进一步地,所述预处理还包括将所述抓拍图像压缩到指定分辨率。进一步地,所述归一化处理包括将所述预处理后的抓拍图像封装成统一的抓拍数据格式。进一步地,所述抓拍数据格式包括所述抓拍图像的抓拍时间、抓拍设备的编号以及所述抓拍图像的预处理信息。为达上述目的,本发明第二方面的实施例还提供了一种基于阻塞队列的多源抓拍图像处理装置,其包括:获取模块,用于获取多个数据源的抓拍图像,并将所述抓拍图像存储在数据缓存池中,其中,所述抓拍图像按照预定的数据格式进行获取;预处理模块,用于按预设时间间隔从所述数据缓存池中取出所述抓拍图像进行预处理;归一化模块,用于对所述预处理后的抓拍图像进行归一化处理。使用本发明的基于阻塞队列的多源抓拍图像处理方法或装置,通过定义统一的数据格式,实现不同数据源的抓拍图像采用相同数据格式进行获取。这样只需针对不同抓拍图像数据源进行设置,即可实现多源抓拍图像接入的归一化,有效降低系统复杂程度。将获取的抓拍图像存放在数据缓存池中,根据预设的时间间隔对数据缓存池中的抓拍图像进行预处理,可避免因不同数据源的抓拍图像获取速度不统一带来的影响,能有效提高抓拍图像预处理的效率。对抓拍图像进行特征区域提取和全景图压缩的预处理,能有效减少抓拍图像数据传输过程中的系统资源消耗,提升系统的处理效率。为达上述目的,本发明第三方面的实施例提供了一种基于阻塞队列的多源抓拍图像接入方法,其包括:根据如上所述的基于阻塞队列的多源抓拍图像处理方法得到归一化的抓拍图像;将所述归一化的抓拍图像发送至图像识别系统。为达上述目的,本发明第四方面的实施例提供了一种基于阻塞队列的多源抓拍图像接入装置,其包括:图像处理模块,用于根据如上所述的基于阻塞队列的多源抓拍图像处理方法得到归一化的抓拍图像;图像发送模块,用于将所述归一化的抓拍图像发送至图像识别系统。使用本发明的基于阻塞队列的多源抓拍图像接入方法或装置,通过针对常用的不同数据源定义相同的数据格式,例如数据库形式、ftp文件数据、http接口数据以及消息订阅数据等,实现抓拍图像数据的接入方式的归一化。以阻塞队列为基础实现数据缓存池,将获取的抓拍图像数据存储到数据缓存池中,根据可配置的定时任务按照统一的速度从数据缓存池中取抓拍图像数据进行处理,实现抓拍图像的获取和图像处理的解耦。将预处理后的抓拍图像进行统一格式的封装后,发送至图像识别系统进行进一步的分析和处理,大大减少非标准格式数据接入图像识别应用系统的复杂程度,有效提高了图像识别应用系统接入多源抓拍图像数据的效率。为达上述目的,本发明第五方面的实施例提供了一种非临时性计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时,实现根据本发明第一方面所述的基于阻塞队列的多源抓拍图像处理方法或实现根据本发明第三方面所述的基于阻塞队列的多源抓拍图像接入方法。为达上述目的,本发明第六方面的实施例提供了一种计算设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时,实现根据本发明第一方面所述的基于阻塞队列的多源抓拍图像处理方法或实现根据本发明第三方面所述的基于阻塞队列的多源抓拍图像接入方法。根据本发明的非临时性计算机可读存储介质和计算设备,具有与根据本发明第一方面的基于阻塞队列的多源抓拍图像处理方法或与根据本发明第三方面的基于阻塞队列的多源抓拍图像接入方法具有类似的有益效果,在此不再赘述。附图说明图1为根据本发明实施例的基于阻塞队列的多源抓拍图像处理方法的原理示意图;图2为根据本发明实施例的获取多源抓拍图像的原理示意图;图3为根据本发明实施例的对抓拍图像进行预处理的原理示意图;图4为根据本发明实施例的基于阻塞队列的多源抓拍图像处理装置的结构示意图;图5为根据本发明实施例的基于阻塞队列的多源抓拍图像接入方法的原理示意图;图6为根据本发明实施例的基于阻塞队列的多源抓拍图像接入装置的结构示意图;图7为根据本发明实施例的计算设备的结构示意图。具体实施方式下面将参照附图详细描述根据本发明的实施例,描述涉及附图时,除非另有表示,不同附图中的相同附图标记表示相同或相似的要素。要说明的是,以下示例性实施例中所描述的实施方式并不代表本发明的所有实施方式。它们仅是与如权利要求书中所详述的、本发明公开的一些方面相一致的装置和方法的例子,本发明的范围并不局限于此。在不矛盾的前提下,本发明各个实施例中的特征可以相互组合。此外,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中,“多个”的含义是至少两个,例如两个,三个等,除非另有明确具体的限定。现有的图像识别应用系统(例如人脸识别应用系统)一般作为一个大的集成项目中的一个部分,该大型集成项目可能是由很多家厂商分别构建的多个子系统组成的。作为第三方抓拍系统,不同厂商的数据源不一样,即抓拍图像数据格式和发送数据方式都不一样,例如有直接读取数据库的、读取ftp形式的、调用http接口的以及消息订阅形式的等。而且不同的发送方式,其数据传输速率也不一样,例如消息订阅的传输速率是很快的,因此对图像识别应用系统的接入能力和解析能力要求也不一样。总而言之,抓拍图像的数据格式和发送方式的多样性导致图像识别应用系统对接第三方抓拍图像数据的系统复杂度较高,而且对抓拍图像的处理效率也较低。图1所示为根据本发明实施例的基于阻塞队列的多源抓拍图像处理方法的原理示意图,包括步骤s21~s23。在步骤s21中,获取多个数据源的抓拍图像,并将所述抓拍图像存储在数据缓存池中,其中,所述抓拍图像按照预定的数据格式进行获取。在本发明实施例中,从多个不同的第三方服务数据源获取抓拍图像,例如从第三方存储服务或第三方数据服务获取抓拍图像。现有的各种第三方抓拍系统会将各监测设备抓拍的图像数据提供给图像识别系统进行后续的图像识别和分析处理。目前较为主流的第三方发送数据的方式包括以下几种:读取数据库形式的、ftp(filetransferprotocol,文件传输协议)文件形式的、http((hypertexttransferprotocol,超文本传输协议)接口形式的以及消息订阅形式的。在本发明实施例中,多个数据源的抓拍图像数据包括数据库数据、ftp文件数据、http接口数据以及消息订阅数据等。由于不同数据源的数据格式不相同,导致了对第三方数据的接收较为复杂。在发明实施例中,对不同数据源定义了相同的获取抓拍图像数据的数据格式,实现对不同数据源的抓拍图像数据的接收方式的归一化。人脸识别应用系统获取抓拍图像数据,实质上就是需要获取某一时刻某个摄像头抓拍的一张监控画面(即为一张抓拍图像,下文中简称全景图),然后通过专用算法从该全景图中检测出人脸并进行下一步的识别告警和分析。因此在本发明实施例中,定义了所需的数据格式如下表所示:在一些实施例中,所述预定的数据格式包括所述抓拍图像的编号、所述抓拍图像的存储路径、抓拍时间以及抓拍设备的编号。其中,抓拍图像的编号为图片唯一编号即uuid(universallyuniqueidentifier,通用唯一识别码)值;抓拍图像的存储路径为全景图的图片存储uri(uniformresourceidentifier,统一资源标识符),用于标识该全景图名称,允许用户通过特定的协议进行交互操作;抓拍时间要求可精确到毫秒,以提高图像处理的准确度;抓拍设备的编号为抓拍摄像头的唯一编号,例如20位的gb28181国标编码,可唯一地对应到特定的抓拍设备,提高抓拍系统数据的可靠性。在其他一些实施例中,所述预定的数据格式包括所述抓拍图像的编号、所述抓拍图像的base64值、抓拍时间以及抓拍摄像头的编号。其中,可使用全景图的base64值代替上述实施例中的全景图的图片存储uri,用于在http环境下传递较长的标识信息。在此给出一个定义数据格式的具体例子,用以更好的解释本发明,但并不以此为限。举例如下:图2所示为根据本发明实施例的获取多源抓拍图像的原理示意图,其中包括对数据库数据、ftp文件、http接口以及消息订阅形式的抓拍数据进行获取,并将获取的抓拍图像放入数据缓存池存储。根据上述定义的数据格式,下文针对不同的数据源分别展开说明。(1)读取数据库形式第三方系统将抓拍图像数据存储在指定数据库中,在本发明实施例中,定时直接从第三方数据库读取抓拍图像数据。一般第三方系统会提供查询sql(structuredquerylanguage,结构化查询语言),可根据时间范围查询出这个时间段内的所有抓拍图像数据。但由于不同厂商系统会存在差异,因此在本发明实施例中设计一个动态sql来实现适配所有厂商的不同查询抓拍图像数据sql,该sql中的字段都是可配置的参数,如下所示:#要查询的表pull.database.table=${database_table:表名xxxxxxxxx}#要查询的图片id字段名称pull.database.column.imageid=${database_imageid_column:imageidxxxxxxxxx}#要查询的全景图路径字段名称pull.database.column.imageuri=${database_imageuri_column:imageurixxxxxx}#要查询的设备id字段名称pull.database.column.deviceid=${database_deviceid_column:deviceidxxxxxx}#要查询的图片抓拍时间字段名称pull.database.column.capturetime=${database_capturetime_column:capturetimexxxxxx}上述代码中的查询sql是一个通用的,实际运行时会根据上述参数拼接动态sql去第三方获取数据:“selectdatabase_imageid_column,database_imageuri_column,database_deviceid_column,database_capturetime_columnfromdatabase_tablewheredatabase_capturetime_column>=‘抓拍时间段的开始时间值’anddatabase_capturetime_column<‘抓拍时间段的结束时间值’”。其中,抓拍时间段的开始时间和结束时间是每一次去第三方查询抓拍图像数据的时间参数。以下给出两个具体使用的例子以更好的解释本发明中使用的sql。a厂商提供的sql是:“selectimagid,imageuri,deviceid,capturetimefromcapture_record_201908wherecreatetime>=‘2019-08-2600:00:00’andcreatetime<‘2019-8-2623:59:59’”,则其配置就是:#要查询的表pull.database.table=${database_table:capture_record_201908}#要查询的图片id字段名称pull.database.column.imageid=${database_imageid_column:imageid}#要查询的全景图路径字段名称pull.database.column.imageuri=${database_imageuri_column:imageuri}#要查询的设备id字段名称pull.database.column.deviceid=${database_deviceid_column:deviceid}#要查询的图片抓拍时间字段名称pull.database.column.capturetime=${database_capturetime_column:capturetime}b厂商提供的sql是:“selectpersonid,zfspath,positionid,createtimefromid_persoon_2019wherecreatetime>=‘2019-08-2600:00:00’andcreatetime<‘2019-8-2623:59:59’”。则其配置就是:#要查询的表pull.database.table=${database_table:id_persoon_2019}#要查询的图片id字段名称pull.database.column.imageid=${database_imageid_column:personid}#要查询的全景图路径字段名称pull.database.column.imageuri=${database_imageuri_column:zfspath}#要查询的设备id字段名称pull.database.column.deviceid=${database_deviceid_column:positionid}#要查询的图片抓拍时间字段名称pull.database.column.capturetime=${database_capturetime_column:createtime}在本发明实施例中,使用动态sql来实现适配不同厂商的查询抓拍图像数据sql,有效提升对多源抓拍图像数据获取的效率。(2)ftp数据形式第三方系统将抓拍图像数据存放到指定ftp上,在本发明实施例中,和第三方约定一个合理的文件存储格式,保证符合上文所述的预定的数据格式的抓拍信息都是完整的,并定时去该ftp服务器上读取抓拍图像数据。其中,抓拍图像ftp存储路径为:“megvii/年月日/相机devideid//时间戳命名的全景图.jpg”具体示例为:“megvii/20190826/4501260000121000001/20190826163010.jpg”根据上述对应的数据格式可以获取到如下必要信息:抓拍时间:capturetime=20190826163010;图片uri:imageuri=上述完整路径即是;摄像头唯一id:deviceid=4501260000121000001。(3)http接口形式在本发明实施例中,提供一个标准httprestful接口,第三方系统在有抓拍图像数据产生时调用本接口,可实现抓拍图像的实时接入。下文给出一个具体示例,但并不以此为限。接口url:/api/capture/receive接口method:post接口request:在本发明实施例中,当有抓拍图像产生时由第三方调用本接口,即可完成抓拍图像的获取。(4)消息队列形式第三方系统在有抓拍图像数据产生时,将数据发送到消息中间件(例如kafka)的指定topic中。在本发明实施例中,实时监听该topic,当有新的抓拍图像数据产生时,就去消费即可获取抓拍图像数据。以下给出一个具体示例:第三方系统发送数据到消息中间件的数据格式:根据上述定义的数据格式,即可实现对不同数据源的抓拍图像数据采用统一的格式进行获取,降低系统对多源抓拍数据获取的复杂程度,有效提升对抓拍数据进行处理的整体效率。在本发明其他实施例中,还可获取其他形式的第三方抓拍系统的抓拍图像数据,定义数据格式为如上所述的格式即可实现抓拍图像的快速获取,提升系统的兼容性。在上述步骤s21中,在获取了多个数据源的抓拍图像后,将所述抓拍图像存储在数据缓存池中。在本发明实施例中,所述数据缓存池是基于阻塞队列实现的。所述阻塞队列是一种数据结构,一种存储数据的组织形式,其特点是数据先进先出,即先存入的数据会被先处理,保证数据按时间顺序进行处理,可满足图像识别系统中对抓拍图像时序的需求。在步骤s22中,按预设时间间隔从所述数据缓存池中取出所述抓拍图像进行预处理。图3所示为根据本发明实施例的对抓拍图像进行预处理的原理示意图。在本发明实施例中,通过可配置的定时任务,按照一定的速度从数据缓存池里取出获取的全景图进行处理。由于数据缓存池是可以设置是否有界的,即其长度是可以设置的,例如将阻塞队列的长度设置为100,则其只能存储100条数据。在本发明实施例中,把数据缓存池设置指定的长度,然后把获取的抓拍图像数据存储进去,每隔预设时间间隔就去检查所述数据缓存池是否已存满,若满了就把其中的数据取出来进行处理。实际的效果就是从多个数据源获取抓拍图像数据并往数据缓存池里存数据的速度是不一定的,可能出现时快时慢。但是从数据缓存池里取出数据进行预处理的速度是固定的,从而实现了对抓拍图像处理速度的统一。在具体实际应用中,可以调整所述预设时间间隔以控制消费(即图像处理)的速度要大于生产(即图像获取)的速度,防止出现由于生产的速度大于消费的速度而导致的内存溢出报错。在一些实施例中,还可以对于生产数据(即获取抓拍图像数据)的环境进行控制,即设置例如查询数据库的频率、从ftp读取数据的频率,对http接口可采取限流措施,而消息队列数据更好控制,由于数据是持久化的可本地存储,如果数据缓存池中数据太多,则晚一点去获取即可。在一些实施例中,在所述预设时间间隔内若所述数据缓存池未存满,则不对所述数据缓存池中的所述抓拍图像进行预处理。即在某一轮定时任务中,如果检查数据缓存池没满的话,本轮处理任务就暂不取任何数据进行预处理,等到下一轮数据满了再处理即可。由于取数据的时间间隔(即所述预设时间间隔)非常小(例如5000ms),因此对抓拍图像数据的延迟性影响也非常小。给出一个具体数据处理速度配置的示例如下,但并不以此为限:#数据缓存池大小,即每一轮处理的数据量image.store.size=${image_store_size:10}#处理数据时间间隔(毫秒),即每隔多长时间进行数据处理image.handle.delay=${image_handle_delay:5000}#处理线程数,根据服务器计算能力配置合理线程数,充分利用服务器计算能力image.handle.threadpool.size=${image_handle_threadpool_size:10}由于在本发明实施例中采用基于阻塞队列的方式实现数据缓存池,既可保证数据按时间顺序进行处理,也可实现数据生产和数据消费的共享,并且把生产和消费分开,解决数据生产与消费速度不匹配的问题。在上述步骤s22中,所述预处理包括对所述抓拍图像的特征区域提取,即对全景图中的感兴趣区域进行分割并提取。在本发明实施例中,所述特征区域包括所述抓拍图像中的人脸区域,即根据人脸检测算法从全景图中检测出人脸并找出其在全景图中的位置,然后分割出人脸抓拍图,供后续人脸识别系统进行后续分析和处理。在本发明另一实施例中,所述特征区域包括所述抓拍图像中的车牌区域,即根据车牌检测算法从全景图中检测出车牌位置,并分割出车牌抓拍图,供后续车辆识别系统进行进一步的分析处理。在一些实施例中,所述预处理还包括将所述抓拍图像压缩到指定分辨率。在对全景图进行特征区域提取的同时,将该全景图压缩到指定分辨率,以减少图像所需存储空间。由于抓拍图像数量巨大,因此将全景图进行压缩可有效节省系统对抓拍图像的存储资源,也便于后续对抓拍图像的传输。在一些实施例中,对抓拍图像进行上述预处理后,记录对抓拍图像进行预处理后的相关信息,例如提取的特征区域在全景图中的相对位置信息、全景图压缩比例等。若在本发明其他实施例中,采用了其他预处理操作,同样也可记录所述预处理的相关信息。在一些实施例中,将进行预处理后的抓拍图像(包括提取的人脸区域和压缩后的全景图)存储到人脸识别应用系统的相应存储模块,并返回其所对应的唯一uri。人脸识别应用系统后续流程就可直接根据已存储的图像数据进行分析,减少传输过程中网络流量消耗。因为人脸识别应用系统后续分析处理环节比较长,如果直接使用base64或原始图像文件进行传输,数据对象序列化后会比较大,会增大网络消耗和内存使用。因此可先将预处理后的图像数据发送至人脸识别应用系统的相应存储模块,以减少系统的资源消耗。在步骤s23中,对所述预处理后的抓拍图像进行归一化处理。在本发明实施例中,所述归一化处理包括将所述预处理后的抓拍图像封装成统一的抓拍数据格式,即将预处理后的全景图和提取的人脸区域图像封装成指定的内部使用格式,完成对多源抓拍图像的处理。在一些实施例中,所述抓拍数据格式包括所述抓拍图像的抓拍时间、抓拍设备的编号以及所述抓拍图像的预处理信息,其中,所述预处理信息包括提取的人脸区域在全景图中的相对位置的相关信息。采用本发明实施例的基于阻塞队列的多源抓拍图像处理方法,通过定义统一的数据格式,实现不同数据源的抓拍图像采用相同数据格式进行获取。可有效解决由于各种图像数据的存储和传输格式都不相同,使得图像识别系统对抓拍图像数据直接进行处理的效率较低的问题。这样只需针对不同抓拍图像数据源进行设置,即可实现多源抓拍图像接入的归一化,有效降低系统复杂程度。将获取的抓拍图像存放在数据缓存池中,根据预设的时间间隔对数据缓存池中的抓拍图像进行预处理,可避免因不同数据源的抓拍图像获取速度不统一带来的影响,能有效提高抓拍图像预处理的效率。对抓拍图像进行特征区域提取和全景图压缩的预处理,能有效减少抓拍图像数据传输过程中的系统资源消耗,提升系统对抓拍图像数据的处理效率。本发明第二方面的实施例还提供了一种基于阻塞队列的多源抓拍图像处理装置。图4所示为根据本发明实施例的基于阻塞队列的多源抓拍图像处理装置400的结构示意图,包括获取模块401、预处理模块402以及归一化模块403。获取模块401用于获取多个数据源的抓拍图像,并将所述抓拍图像存储在数据缓存池中,其中,所述抓拍图像按照预定的数据格式进行获取。预处理模块402用于按预设时间间隔从所述数据缓存池中取出所述抓拍图像进行预处理。归一化模块403用于对所述预处理后的抓拍图像进行归一化处理。所述基于阻塞队列的多源抓拍图像处理装置400的各个模块的更具体实现方式可以参见对于本发明的基于阻塞队列的多源抓拍图像处理方法的描述,且具有与之相似的有益效果,在此不再赘述。本发明第三方面的实施例提出了一种基于阻塞队列的多源抓拍图像接入方法。图5所示为根据本发明实施例的基于阻塞队列的多源抓拍图像接入方法的原理示意图,包括根据如上所述的基于阻塞队列的多源抓拍图像处理方法得到处理后的归一化的抓拍图像。在本发明实施例中,包括获取多个数据源的抓拍图像,并将所述抓拍图像存储在数据缓存池中,其中,所述抓拍图像按照预定的数据格式进行获取;按预设时间间隔从所述数据缓存池中取出所述抓拍图像进行预处理;对所述预处理后的抓拍图像进行归一化处理。在本发明其他实施例中,若还采取了其他的对多源抓拍图像进行处理的操作,同样也适用于本发明实施例。在上述数据封装(即归一化)完成后,将所述归一化的抓拍图像发送至图像识别系统。在本发明实施例中,将所述归一化处理后(即封装成指定的内部使用格式)的数据发送给人脸识别应用系统,最终实现多源抓拍数据的接入。下文给出一个统一的数据格式示例如下,但并不以此为限:其中,可包括抓拍图像的唯一id、抓拍时间(精确到毫秒)、抓拍设备id、人脸区域在全景图中的相对位置等信息。所述数据格式可根据系统需求进行相应调整。采用本发明实施例的基于阻塞队列的多源抓拍图像接入方法,通过针对常用的不同数据源定义相同的数据格式,例如数据库形式、ftp文件数据、http接口数据以及消息订阅数据等,实现抓拍图像数据的接入方式的归一化。以阻塞队列为基础实现数据缓存池,将获取的抓拍图像数据存储到数据缓存池中,根据可配置的定时任务按照统一的速度从数据缓存池中取抓拍图像数据进行处理,实现抓拍图像的获取和图像处理的解耦。将预处理后的抓拍图像进行统一格式的封装后,发送至图像识别系统进行进一步的分析和处理,大大减少非标准格式数据接入图像识别应用系统的复杂程度,有效提高了图像识别应用系统接入多源抓拍图像数据的效率。本发明第四方面的实施例提出了一种基于阻塞队列的多源抓拍图像接入装置。图6所示为根据本发明实施例的基于阻塞队列的多源抓拍图像接入装置600的结构示意图,包括图像处理模块601以及图像发送模块602。图像处理模块601用于根据如上所述的基于阻塞队列的多源抓拍图像处理方法得到归一化的抓拍图像。图像发送模块602用于将所述归一化的抓拍图像发送至图像识别系统。所述基于阻塞队列的多源抓拍图像接入装置600的各个模块的更具体实现方式可以参见对于本发明的基于阻塞队列的多源抓拍图像接入方法的描述,且具有与之相似的有益效果,在此不再赘述。本发明第五方面的实施例提出了一种非临时性计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时,实现根据本发明第一方面实施例所述的基于阻塞队列的多源抓拍图像处理方法或实现根据本发明第三方面实施例所述的基于阻塞队列的多源抓拍图像接入方法。一般来说,用于实现本发明方法的计算机指令的可以采用一个或多个计算机可读的存储介质的任意组合来承载。非临时性计算机可读存储介质可以包括任何计算机可读介质,除了临时性地传播中的信号本身。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码,所述程序设计语言包括面向对象的程序设计语言—诸如java、smalltalk、c++,还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言,特别是可以使用适于神经网络计算的python语言和基于tensorflow、pytorch等平台框架。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。本发明第六方面的实施例提供了一种计算设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时,实现根据本发明第一方面实施例所述的基于阻塞队列的多源抓拍图像处理方法或实现根据本发明第三方面实施例所述的基于阻塞队列的多源抓拍图像接入方法。根据本发明第五、六方面的非临时性计算机可读存储介质和计算设备,可以参照根据本发明第一方面实施例或第三方面实施例具体描述的内容实现,并具有与根据本发明第一方面实施例的基于阻塞队列的多源抓拍图像处理方法或第三方面实施例的基于阻塞队列的多源抓拍图像接入方法具有类似的有益效果,在此不再赘述。图7示出了适于用来实现本公开的实施方式的示例性计算设备的框图。图7显示的计算设备12仅仅是一个示例,不应对本公开实施例的功能和使用范围带来任何限制。如图7所示,计算设备12可以通用计算设备的形式实现。计算设备12的组件可以包括但不限于:一个或者多个处理器或者处理单元16,系统存储器28,连接不同系统组件(包括系统存储器28和处理单元16)的总线18。总线18表示几类总线结构中的一种或多种,包括存储器总线或者存储器控制器,外围总线,图形加速端口,处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说,这些体系结构包括但不限于工业标准体系结构(industrystandardarchitecture;以下简称:isa)总线,微通道体系结构(microchannelarchitecture;以下简称:mac)总线,增强型isa总线、视频电子标准协会(videoelectronicsstandardsassociation;以下简称:vesa)局域总线以及外围组件互连(peripheralcomponentinterconnection;以下简称:pci)总线。计算设备12典型地包括多种计算机系统可读介质。这些介质可以是任何能够被计算设备12访问的可用介质,包括易失性和非易失性介质,可移动的和不可移动的介质。存储器28可以包括易失性存储器形式的计算机系统可读介质,例如随机存取存储器(randomaccessmemory;以下简称:ram)30和/或高速缓存存储器32。计算设备12可以进一步包括其它可移动/不可移动的、易失性/非易失性的计算机可读存储介质。仅作为举例,存储系统34可以用于读写不可移动的、非易失性磁介质(图中未显示,通常称为“硬盘驱动器”)。尽管图7中未示出,可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器,以及对可移动非易失性光盘(例如:光盘只读存储器(compactdiscreadonlymemory;以下简称:cd-rom)、数字多功能只读光盘(digitalvideodiscreadonlymemory;以下简称:dvd-rom)或者其它光介质)读写的光盘驱动器。在这些情况下,每个驱动器可以通过一个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程序产品,该程序产品具有一组(例如至少一个)程序模块,这些程序模块被配置以执行本公开各实施例的功能。具有一组(至少一个)程序模块42的程序/实用工具40,可以存储在例如存储器28中,这样的程序模块42包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据,这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本公开所描述的实施例中的功能和/或方法。计算设备12也可以与一个或多个外部设备14(例如键盘、指向设备、显示器24等)通信,还可与一个或者多个使得用户能与该计算机系统/服务器12交互的设备通信,和/或与使得该计算机系统/服务器12能与一个或多个其它计算设备进行通信的任何设备(例如网卡,调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口22进行。并且,计算设备12还可以通过网络适配器20与一个或者多个网络(例如局域网(localareanetwork;以下简称:lan),广域网(wideareanetwork;以下简称:wan)和/或公共网络,例如因特网)通信。如图所示,网络适配器20通过总线18与计算设备12的其它模块通信。要说明的是,尽管图中未示出,可以结合计算设备12使用其它硬件和/或软件模块,包括但不限于:微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。处理单元16通过运行存储在系统存储器28中的程序,从而执行各种功能应用以及数据处理,例如实现前述实施例中提及的方法。本发明的计算设备可以是服务器,也可以有限算力的终端设备。尽管上面已经示出和描述了本发明的实施例,应当理解的是,上述实施例是示例性的,不能解释为对本发明的限制,本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。当前第1页1 2 3 
当前第1页1 2 3 
网友询问留言 留言:0条
  • 还没有人留言评论。精彩留言会获得点赞!