本發(fā)明涉及智能圖像處理領(lǐng)域，尤其涉及一種圖像處理系統(tǒng)及圖像處理的方法。

背景技術(shù)：

智能圖像處理算法特別是人工智能方面的算法，一般由于計算復(fù)雜，例如深度學(xué)習(xí)都需要強大的計算資源。該領(lǐng)域最重要的問題，是解決算法高性能及加速問題。早期，人們很容易想到利用云計算的海量處理資源來擴展計算能力，如Google(谷歌)著名的貓臉識別，建立了一個9層的深度神經(jīng)網(wǎng)絡(luò)，運行在16000個CPU(中央處理器)組成的服務(wù)器集群，經(jīng)過3天得出結(jié)果。這種計算的缺點是，計算速度慢。另外一種就是利用GPU(Graphical Processing Unit，圖形處理器)進(jìn)行加速。如貓臉識別實驗中，一位名叫Adam Coates的斯坦福大學(xué)研究人員想出了一個更好的解決方案，他用一種不同的微處理器(GPU)，將三臺計算機連貫在一起，讓它們像是一個系統(tǒng)一樣運行，結(jié)果與Google數(shù)千臺計算機的運行效果是一樣的。這絕對是一個非凡的成就。

兩種方法各有優(yōu)缺點，分布式計算速度慢，但很容易擴展，能充分利用現(xiàn)已部署的海量CPU資源，投資低。GPU運算速度快，但GPU是比較新的硬件設(shè)備，大量使用需要大量的投資。

當(dāng)前，Hadoop(Hadoop Distributed File System，Hadoop分布式文件系統(tǒng)，大量數(shù)據(jù)分布式處理軟件框架)系統(tǒng)已經(jīng)有了廣泛的使用，也出現(xiàn)了基于Hadoop的分布式圖像處理方案。大批量圖像處理這種計算密集型的應(yīng)用也給分布式系統(tǒng)的設(shè)計帶來了一定的挑戰(zhàn)，而Hadoop在這種應(yīng)用中有其自身的不足之處。例如，全量場景，任務(wù)內(nèi)串行；重吞吐量，響應(yīng)時 間完全沒有保證等缺點，最致命的是Hadoop不適合做實時分析系統(tǒng)，這在一定程度上限制了Hadoop的應(yīng)用場景。而傳統(tǒng)的分布式圖像處理系統(tǒng)，多數(shù)基于遠(yuǎn)程過程調(diào)用和NFS(Network File System，網(wǎng)絡(luò)文件系統(tǒng))實現(xiàn)，在系統(tǒng)通信和存儲上也存在先天的不足。

另外，若涉及海量圖像分析處理的時候，如果以流的形式在系統(tǒng)中傳遞會嚴(yán)重消耗網(wǎng)絡(luò)帶寬，增加響應(yīng)時間。

技術(shù)實現(xiàn)要素：

本發(fā)明要解決的技術(shù)問題是提供一種圖像處理系統(tǒng)及圖像處理的方法，以提高處理大批量圖像文件的效率。

為了解決上述技術(shù)問題，本發(fā)明提供了一種圖像處理系統(tǒng)，其中，包括：

顯示模塊，用于接收用戶上傳的一張或多張圖像，將所述圖像上傳到存儲模塊，向處理模塊發(fā)送第一消息；在接收到所述處理模塊的第二消息后，根據(jù)所述第二消息從所述存儲模塊下載對應(yīng)處理后圖像并進(jìn)行顯示；

所述處理模塊，用于在接收到所述第一消息后，根據(jù)所述第一消息從所述存儲模塊下載圖像并進(jìn)行圖像處理，將處理后的圖像上傳到所述存儲模塊，向所述顯示模塊發(fā)送所述第二消息；

所述存儲模塊，用于存儲所述顯示模塊和所述處理模塊上傳的圖像。

進(jìn)一步地，上述圖像處理系統(tǒng)還具有下面特點：

所述處理模塊，還用于在接收到所述第一消息后解析所述第一消息，解析出的信息包括圖像的存儲路徑信息，根據(jù)所述圖像的存儲路徑信息從所述存儲模塊下載對應(yīng)的圖像。

進(jìn)一步地，上述圖像處理系統(tǒng)還具有下面特點：

所述處理模塊，進(jìn)行圖像處理包括：將所述圖像轉(zhuǎn)化成字節(jié)流，調(diào)用對應(yīng)的圖像算法對所述字節(jié)流進(jìn)行處理。

進(jìn)一步地，上述圖像處理系統(tǒng)還具有下面特點：

所述處理模塊，進(jìn)行圖像處理后還用于：將圖像處理日志信息上傳到所述存儲模塊。

進(jìn)一步地，上述圖像處理系統(tǒng)還具有下面特點：所述顯示模塊，接收到所述處理模塊的第二消息后還用于，從所述存儲模塊下載對應(yīng)的圖像處理日志信息并顯示。

進(jìn)一步地，上述圖像處理系統(tǒng)還具有下面特點：所述第一消息為卡夫卡kafka分布式發(fā)布訂閱消息系統(tǒng)消息。

進(jìn)一步地，上述圖像處理系統(tǒng)還具有下面特點：所述顯示模塊，每接收用戶上傳的一張圖像向所述處理模塊發(fā)送一條所述第一消息。

進(jìn)一步地，上述圖像處理系統(tǒng)還具有下面特點：所述第一消息攜帶圖像的存儲路徑信息。

進(jìn)一步地，上述圖像處理系統(tǒng)還具有下面特點：所述第一消息還攜帶用戶設(shè)置的圖像算法參數(shù)和算法類型的信息。

進(jìn)一步地，上述圖像處理系統(tǒng)還具有下面特點：所述算法類型包括以下的任一種：

圖像壓縮算法、文字識別、不良圖像檢測和以圖搜圖。

進(jìn)一步地，上述圖像處理系統(tǒng)還具有下面特點：所述第二消息攜帶所述處理后的圖像和日志信息的存儲路徑信息。

進(jìn)一步地，上述圖像處理系統(tǒng)還具有下面特點：所述第二消息為卡夫卡kafka分布式發(fā)布訂閱消息系統(tǒng)消息。

進(jìn)一步地，上述圖像處理系統(tǒng)還具有下面特點：所述存儲模塊為Hadoop分布式文件系統(tǒng)HDFS。

為了解決上述問題，本發(fā)明還提供了一種圖像處理的方法，應(yīng)用于上述的圖像處理系統(tǒng)，包括：

接收用戶上傳的一張或多張圖像，存儲所述圖像；

下載所述圖像，并進(jìn)行圖像處理，存儲處理后的圖像；

下載所述處理后的圖像并進(jìn)行顯示。

進(jìn)一步地，上述方法還具有下面特點：所述進(jìn)行圖像處理包括：

將所下載的圖像數(shù)據(jù)轉(zhuǎn)化成字節(jié)流，調(diào)用對應(yīng)的圖像算法對所述字節(jié)流進(jìn)行處理。

進(jìn)一步地，上述方法還具有下面特點：所述進(jìn)行圖像處理后，還包括：

存儲圖像處理日志信息。

進(jìn)一步地，上述方法還具有下面特點：還包括：

下載所述圖像處理日志信息并進(jìn)行顯示。

進(jìn)一步地，上述方法還具有下面特點：

所述存儲所述圖像包括：將所述圖像存儲于Hadoop分布式文件系統(tǒng)HDFS；

所述存儲處理后的圖像，包括：將所述處理后的圖像和圖像處理日志信息存儲于所述Hadoop分布式文件系統(tǒng)HDFS。

綜上，本發(fā)明提供一種圖像處理系統(tǒng)及圖像處理的方法，可以提高處理大批量圖像文件的效率。

附圖說明

圖1為本發(fā)明實施例的圖像處理系統(tǒng)的示意圖；

圖2為本發(fā)明應(yīng)用示例的圖像處理系統(tǒng)的示意圖；

圖3為本發(fā)明實施例的圖像處理的方法的流程圖。

具體實施方式

為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚明白，下文中將結(jié)合附圖對本發(fā)明的實施例進(jìn)行詳細(xì)說明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互任意組合。

本發(fā)明的目的是為了克服現(xiàn)有技術(shù)的缺陷，本實施例提供一種圖像處理系統(tǒng)，如圖1所示，本實施例的圖像處理系統(tǒng)包括：

顯示模塊，用于接收用戶上傳的一張或多張圖像，將所述圖像上傳到存儲模塊，向處理模塊發(fā)送第一消息；在接收到所述處理模塊的第二消息后，根據(jù)所述第二消息從所述存儲模塊下載對應(yīng)的圖像并進(jìn)行顯示；

所述處理模塊，用于在接收到所述第一消息后，根據(jù)所述第一消息從所述存儲模塊下載圖像并進(jìn)行圖像處理，將處理后的圖像上傳到所述存儲模塊，向所述顯示模塊發(fā)送所述第二消息；

所述存儲模塊，用于存儲所述顯示模塊和所述處理模塊上傳的圖像。

在一優(yōu)選實施例中，所述處理模塊，還可以用于在接收到所述第一消息后解析所述第一消息，解析出的信息包括圖像的存儲路徑信息，根據(jù)所述圖像的存儲路徑信息從所述存儲模塊下載對應(yīng)的圖像。

在一優(yōu)選實施例中，所述處理模塊進(jìn)行圖像處理可以包括：將所述圖像轉(zhuǎn)化成字節(jié)流，調(diào)用對應(yīng)的圖像算法對所述字節(jié)流進(jìn)行處理。

本實施例中的存儲模塊可以采用HDFS(Hadoop Distributed File System，Hadoop分布式文件系統(tǒng))存儲模塊，用于存儲圖像。

本實施例，將CPU與GPU相結(jié)合，充分利用分布式集群的擴展性和GPU運行的高速度，并進(jìn)行研究；所述處理模塊可以選擇實時處理性能佳的Storm(風(fēng)暴分布式實時計算系統(tǒng))(一個開源的分布式實時計算系統(tǒng))，目的是讓數(shù)據(jù)分析更加實時高效。

另外，本實施例中，將待處理的圖像以及處理后的圖像或結(jié)果全部存儲到HDFS；在調(diào)用圖像處理算法之前將圖像路徑信息轉(zhuǎn)換成字節(jié)流，以及在完成圖像分析后將處理后的圖像或結(jié)果以字節(jié)流發(fā)送出去，其他環(huán)節(jié)傳遞的都是HDFS中圖像存儲的路徑信息，這樣大大減輕了網(wǎng)絡(luò)負(fù)擔(dān)，處理速度更快。

對于海量圖像，采用Kafka(卡夫卡，一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng))消息隊列，每張圖像處理任務(wù)就發(fā)送一條kafka消息到Storm系 統(tǒng)。實現(xiàn)多條消息同時并發(fā)處理，避免Storm系統(tǒng)中循環(huán)單條消息處理。

圖2為本發(fā)明應(yīng)用示例的圖像處理系統(tǒng)的示意圖，如圖2所示，本實施例的圖像處理系統(tǒng)包括以下模塊：可視化UI(用戶界面)(相當(dāng)于上述的顯示模塊)，Kafka消息隊列模塊，HDFS、Storm模塊，智能圖像處理算法模塊。其中，

可視化UI：該UI上，用戶可以選擇圖像算法類型，設(shè)置算法參數(shù)，可以上傳本地圖像(單張圖像或文件夾)。用戶點擊提交按鈕后，就會將選擇的圖像處理算法任務(wù)提交到系統(tǒng)中，任務(wù)便開始啟動。任務(wù)啟動后，先將用戶上傳的圖像存儲到HDFS中，并向Storm模塊發(fā)送Kafka消息。

Kafka消息隊列模塊：kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，通過O(1)(常量復(fù)雜度)的磁盤數(shù)據(jù)結(jié)構(gòu)提供消息的持久化，具有高吞吐量和長時間的穩(wěn)定性能等特點。該模塊負(fù)責(zé)整個圖像分析系統(tǒng)的消息發(fā)送和接收，在輸入端，將圖像路徑、算法類型、算法參數(shù)等信息發(fā)送給Storm模塊；在輸出端，將Storm模塊計算得到的結(jié)果路徑，甚至是算法處理的trace(跟蹤)日志等信息發(fā)送到可視化界面后，由界面將圖像處理后的結(jié)果展示出來。

HDFS：在實施例中，HDFS除了負(fù)責(zé)存儲用戶上傳的圖像外，圖像算法處理后的結(jié)果也會存到這里。避免系統(tǒng)中大批量傳遞圖像流而導(dǎo)致的帶寬消耗。

Storm模塊：Storm是一套極具可擴展能力、快速驚人且具備容錯能力的開源實時分布計算系統(tǒng)，其高度專注于流處理領(lǐng)域。Storm在事件處理與增量計算方面表現(xiàn)突出，能夠以實時方式根據(jù)不斷變化的參數(shù)對數(shù)據(jù)流進(jìn)行處理。該模塊在系統(tǒng)中承擔(dān)接收kafka消息、解析拆分消息字段、從HDFS下載和上傳圖像、調(diào)度算法處理等功能，屬于核心處理模塊。

智能圖像處理模塊：該模塊是算法核心，所有智能圖像算法都封裝在這個模塊中。本實施例的圖像算法基本上都是用C或C++編碼實現(xiàn)的，需要將每個算法封裝成.so文件，并提供可調(diào)用的Java接口，實現(xiàn)圖像算法的調(diào)用。

圖3為本發(fā)明實施例的圖像處理的方法的流程圖，如圖3所示，本實施例的方法應(yīng)用于上述的圖像處理系統(tǒng)，包括以下步驟：

步驟11、接收用戶上傳的一張或多張圖像，存儲所述圖像；

步驟12、下載所述圖像，并進(jìn)行圖像處理，存儲處理后的圖像；

步驟13、下載所述處理后的圖像并進(jìn)行顯示。

本實施例的圖像處理的方法處理圖像的速度更快，同時可以減少網(wǎng)絡(luò)帶寬消耗。

以下以兩個具體實施例對本發(fā)明的方法進(jìn)行詳細(xì)的說明。

實施例一

本實施例的圖像處理的方法包括以下步驟：

步驟101：用戶在可視化UI上上傳待處理圖像，設(shè)置算法相關(guān)參數(shù)，點擊提交，即向系統(tǒng)提交了圖像處理任務(wù)；

步驟102：可視化UI首先將用戶上傳的圖像全部存儲到HDFS，同時記錄所有圖像文件的存放路徑信息；

步驟103：可視化UI發(fā)送Kafka消息到Storm模塊，消息中攜帶HDFS單張圖像存放路徑信息、界面上設(shè)置的圖像算法參數(shù)、算法類型等信息；每處理一張圖像都會發(fā)送一個kafka消息，可一直連續(xù)發(fā)多條消息；

所述算法類型包括但不限于：圖像壓縮、文字識別(例如，OCR(Optical Character Recognition，光學(xué)字符識別))、不良圖像檢測、以圖搜圖。

步驟104：Storm模塊中KafkaSpout(kafka消息源)用來接收Kafka消息，并將消息發(fā)給第一個bolt(消息處理者)進(jìn)行消息字段解析拆分，拆分后的字段為：消息號(sessionid)、圖像在HDFS上的存儲路徑、圖像參數(shù)、算法類型等信息。

步驟105：拆分后的字段發(fā)送到第二個bolt：ReadHdfsBolt；

ReadHdfsBolt會根據(jù)每張圖像的存儲路徑信息從HDFS上下載圖像并轉(zhuǎn)化成字節(jié)流。

步驟106：轉(zhuǎn)換后的字節(jié)流發(fā)送到第三個bolt：AlgorithmBlot；

AlgorithmBlot根據(jù)算法類型消息字段，調(diào)用對應(yīng)的智能圖像算法對字節(jié)流進(jìn)行處理，得到相應(yīng)的處理結(jié)果(圖像或文字等)。

本實施例中，AlgorithmBlot調(diào)用已封裝好的相應(yīng)圖像算法java接口。其中，字節(jié)流作為接口的入?yún)ⅲ瑘D像處理后得到的結(jié)果轉(zhuǎn)換成字節(jié)流。

其中，圖像處理算法基本都是C或C++編碼實現(xiàn)的，事先需要將算法封裝成.so文件，并加載到工程中；而封裝的java接口通過jni方式調(diào)算法.so文件。

步驟107：圖像算法處理后得到結(jié)果(圖像或文字等)以字節(jié)流的形式發(fā)送到第四個bolt：WriteHdfsBlot；

WriteHdfsBlot將字節(jié)流轉(zhuǎn)換成圖像格式或其他類型的處理結(jié)果存儲到HDFS中。

步驟108：最后將HDFS中處理結(jié)果所在的路徑等信息傳遞到最后一個bolt：KafkaBolt。

KafkaBolt將這些數(shù)據(jù)信息以kafka消息發(fā)送給可視化UI界面。

步驟109：可視化界面接收消息后，根據(jù)HDFS上存儲的處理結(jié)果路徑信息，從HDFS上下載處理后的圖像或其他結(jié)果，并展示到界面上。

采用本發(fā)明實施例所述的圖像處理的方法，與現(xiàn)有技術(shù)相比，可適用于實時性要求較高的場景，應(yīng)用范圍更廣，處理速度更快，同時減少了網(wǎng)絡(luò)帶寬消耗，降低了算法處理時間。

本實施例中，用戶在可視化界面上上傳待處理的圖像，同時設(shè)計算法類型以及參數(shù)后，向Storm模塊中提交圖像處理任務(wù)。任務(wù)啟動后，首先將圖像存儲到HDFS中，并將圖像路徑信息發(fā)送kafka消息到Storm模塊中。Storm模塊負(fù)責(zé)從HSFS存儲模塊中下載圖像并轉(zhuǎn)換成字節(jié)流，并根據(jù)算法類型調(diào)用相關(guān)的算法接口。圖像經(jīng)算法處理后得到的結(jié)果先存儲到HDFS中。最后Storm模塊將結(jié)果路徑信息以及處理日志等信息發(fā)送kafka消息到可視化界面，用于界面進(jìn)行結(jié)果展示。

實施例二，本實施例以圖像壓縮算法為例，包括以下步驟：

步驟201：用戶在可視化UI上上傳待壓縮的圖像(一張或多張)，選擇算法類型為：圖像壓縮，同時設(shè)置圖像壓縮算法壓縮因子參數(shù)(取值范圍在0～1，默認(rèn)值為0.85)，點擊提交按鈕，即向系統(tǒng)提交了圖像壓縮處理任務(wù)；

步驟202：可視化UI首先將用戶上傳的所有圖像全部存儲到HDFS中，同時記錄所有圖像文件的存放路徑；

步驟203：可視化UI發(fā)送Kafka消息到Storm模塊，除了消息號sessionid外，消息中還攜帶HDFS單張圖像存放路徑、界面上設(shè)置的圖像算法壓縮因子參數(shù)、算法類型(圖像壓縮算法)等信息；每處理一張圖像都會發(fā)送一個kafaka消息，可一直連續(xù)發(fā)多條消息；

步驟204：Storm模塊中KafkaSpout用來接收Kafka消息，并將消息字段解析拆分，拆分后的字段為：消息號sessionid、圖像在HDFS上的存儲路徑信息、壓縮因子參數(shù)、算法類型(圖像壓縮算法)；

步驟205：拆分后的字段發(fā)送到第二個bolt：ReadHdfsBolt；ReadHdfsBolt會根據(jù)每張圖像的存儲路徑信息從HDFS上下載圖像并轉(zhuǎn)化成字節(jié)流；

步驟206：轉(zhuǎn)換后的字節(jié)流發(fā)送到第三個bolt：AlgorithmBlot；AlgorithmBlot里面判斷算法類型消息字段為圖像壓縮，則調(diào)用已封裝好的圖像壓縮圖像算法java接口。其中，字節(jié)流作為接口的入?yún)?，進(jìn)行圖像壓縮處理后得到壓縮后的圖像流；

其中，圖像處理算法基本都是C或C++編碼實現(xiàn)的，事先需要將算法封裝成.so文件，并加載到工程中；而封裝的java接口通過jni方式調(diào)算法.so文件。

步驟207：壓縮后的圖像以字節(jié)流的形式發(fā)送到第四個bolt：WriteHdfsBlot；

WriteHdfsBlot將字節(jié)流轉(zhuǎn)換成圖像格式存儲到HDFS中。

步驟208：最后將壓縮后圖像在HDFS中的路徑等信息傳遞到最后一個bolt：KafkaBolt。

KafkaBolt將這些數(shù)據(jù)信息以kafka消息發(fā)送出去。

步驟209：可視化UI收到消息后，根據(jù)返回的圖像路徑信息從HDFS上下載壓縮后的圖像，并展示在UI上。

本領(lǐng)域普通技術(shù)人員可以理解上述方法中的全部或部分步驟可通過程序來指令相關(guān)硬件完成，所述程序可以存儲于計算機可讀存儲介質(zhì)中，如只讀存儲器、磁盤或光盤等。可選地，上述實施例的全部或部分步驟也可以使用一個或多個集成電路來實現(xiàn)。相應(yīng)地，上述實施例中的各模塊/單元可以采用硬件的形式實現(xiàn)，也可以采用軟件功能模塊的形式實現(xiàn)。本發(fā)明不限制于任何特定形式的硬件和軟件的結(jié)合。

以上僅為本發(fā)明的優(yōu)選實施例，當(dāng)然，本發(fā)明還可有其他多種實施例，在不背離本發(fā)明精神及其實質(zhì)的情況下，熟悉本領(lǐng)域的技術(shù)人員當(dāng)可根據(jù)本發(fā)明作出各種相應(yīng)的改變和變形，但這些相應(yīng)的改變和變形都應(yīng)屬于本發(fā)明所附的權(quán)利要求的保護(hù)范圍。