手上有一個項目,需要檢驗使用本程序的,是否本人!因為在程序使用前,我們都已經做過頭像現場采集,所以源頭呢是不成問題的,那么人臉檢測,人臉比對,怎么辦呢?度娘了下,目前流行的幾個人臉檢測,人臉比對核心,大多都是基於互聯網的,但我們的項目是基於本地服務器,那就有點麻煩了,后來找到ArcFace.它的核心允許本地調用,那就好辦了,立刻去了虹軟的開放平台,看論壇,下DEMO;我當時下的是這個:ArcFace C#DEMO
本以為可以一帆風順的就可以把項目搞定了,不想…噩夢才剛剛開始呢…且聽我細細道來:
首先說下我的調用邏輯; 項目里有一個采集端(每個業務窗口),負責采集現場人像,並通過ArcFace人臉檢測,特征提取,獲取到.dat比對源(ServiceFaceModels),然后存到數據庫(blob);
項目里的應用端(用戶手機),隨機時間的調用攝像頭,采集到被比對圖片;並對該記錄進行標記;
項目時比對端(服務器),定時詢問數據庫,哪些被標記記錄需要比對,然后通過數據庫記錄,找到該圖片,並通過ArcFace人臉檢測,特征提取,獲取到.dat被比對源(LocalFaceModels) 然后將這兩個源在內存中進行比對,得分高於0.7的,就通過;
前兩端就不多說了,都是一些常規的操作.重點講下比對端(服務器);
先說我做的第一個版本,做的是一個控制台程序;
//首先定義了一個調用類; MatchUserFace;它里邊包含了初始化,人臉檢測,特征提取,人臉比對,以及一些輔助方法;
//然后在Program里定義了一個委托,這個委托的作用,就是能夠讓我可以帶參數進去ArcFace的檢測與比對核心;
public delegate bool MatchHandler(string userid, string studyid, string photoid, string photopath);
//最后我的Program里邊,就是做一個遞歸,去不斷的問數據庫拿被標志需要進行核對的記錄,拿到圖片后,就進行比對; QueryDataFile(string upstate);
下邊這段就是在QueryDataFile();去實現異步調用比對核心;
MatchHandler handler = new MatchHandler(MatchUserFace.GetAndMatchImage);
string Identification = string.Format("USERID:{0} STUDYID:{1} PHID:{2}", userid, studyid, photoid);
IAsyncResult result = handler.BeginInvoke(userid, studyid, photoid, pathstr, RecognizeEngine, DetectEngine, new AsyncCallback(CallbackFunc), Identification);
下邊這段就是異步的結果回調;
static void CallbackFunc(IAsyncResult result)
{
MatchHandler handler = (MatchHandler)((AsyncResult)result).AsyncDelegate;
bool match = handler.EndInvoke(result);
string strmatch = string.Empty;
if (match)
{
strmatch = " 比對結果:OK";
}
else
{
strmatch = " 比對結果:NO";
}
Console.WriteLine(result.AsyncState + strmatch);
GC.Collect();
}
寫好了,發布到服務器上,還想着中午吃個雞腿獎勵下自己;不想…發布后不到兩小時,小弟來說:服務器是不是出問題了,下邊所有業務窗口訪問速度嚴重延遲…立馬跑到機房去看,一看沒毛病呀,所有的服務都好好的,沒有卦死..再打開資源監視器一看,靠…那個比對端一下吃3個多G的內存,而且還在不斷上升中…立馬停掉,然后再問小弟,下邊業務是否正常,他回復正常了…那么說,就是我寫的這個比對端有問題了!改!!!
第二個版本,
下了機房看代碼…左看右看,沒有哪不對呀,一步步按步就班的…毫無頭緒時,就想,是不是服務器內存不夠而已,打申請拿了64G回來.再開程序也是一樣吃的很緊,但是下邊業務窗口倒是不延時,看來內存增大還是有好處的…呵…;但是源頭問題還是沒解決,不行的呀!到了晚飯時,一道靈光拍進腦門,我看到代碼里我是每異步調用一次,就初始化一次ArcFace的SDK.我就想,是不是這個原因導致呢?修改方法,去試試!! //把那個委托改成如下:
public delegate bool MatchHandler(string userid, string studyid, string photoid, string photopath, IntPtr RecognizeEngine, IntPtr DetectEngine);
//然后初始化SDK放到了Program里做:
string appId = "4yHjnxK94FCK6L7HaJieWawSLubnANXXXXX";
string sdkFDKey = "7S6Xp4mtroLnjTt7qDYnd2dqHXXXXX";
string sdkFRKey = "7S6Xp4mtroLnjTt7qDYnd2dxSgXXXXX";
int retCode = AFDFunction.AFD_FSDK_InitialFaceEngine(appId, sdkFDKey, pMem, detectSize, ref DetectEngine, 5, nScale, nMaxFaceNum);
int retCode2 = AFRFunction.AFR_FSDK_InitialEngine(appId, sdkFRKey, pMemRecongnize, detectSize, ref RecognizeEngine);
//最后把異步調用的方法改成如下:
MatchHandler handler = new MatchHandler(MatchUserFace.GetAndMatchImage);
string Identification = string.Format("USERID:{0} STUDYID:{1} PHID:{2}", userid, studyid, photoid);
IAsyncResult result = handler.BeginInvoke(userid, studyid, photoid, pathstr, RecognizeEngine, DetectEngine, new AsyncCallback(CallbackFunc), Identification);
再次發布到服務器.然后再到資源監視器去看,喲…線程數不高了而且增長的還不快…好開心!!以為搞好了;就回宿舍睡覺去了!!不想…睡得迷糊的時候,我們的客服小妹妹的電話就打到我這了,我說什么事,她說現在大面積反映用戶比對不了?what?我說不可能吧,是不是當地電信故障呀?我自己拿手機試了下,真的不行呀!!!快速趕回辦公室遠程看了下服務器,我的乖乖…比對端卦了!!!我再看日志,日志沒有捕捉到程序異常,只是捕到了個:Value cannot be null.Parameter name: source;我吃你大米了,我刨你家玉米地了,為啥要這么對我!重啟比對端,然后都可以正常運作了…我決定在這監視這個比對端,在資源監視器我到是發現了一個:w3wp.exe它在不斷的漲內存(這是要划重點的)想想這可已經是深夜了.果不出其然,運行了大概兩個多小時后,程序又卦了.我的乖乖,為啥會這樣呢,一時半會也想不出辦法呀!我也總不能呆在服務器旁它停了,我就重啟吧! 第二天致電虹軟,反映了程序會運行一段時間就會卦掉,虹軟這邊也提出了很多寶貴意見,
1.先着眼把捕捉到的那個錯誤,查出來,看看是否處理好了,程序還會不會卦;那我就在程序里增加了日志打印,還真就發現了幾個在DEMO里沒有處理到的問題:
- 每個Marshal.AllocHGlobal,用完以后,一定要釋放;
- AFD_FSDK_StillImageFaceDetection;AFR_FSDK_ExtractFRFeature;這兩個函數要判斷返回值是否等於0; 所以 MatchUserFace 調用類我作了如下修改
private static byte[] detectAndExtractFeature(Image imageParam, out Image facerect,
IntPtr RecognizeEngine, IntPtr DetectEngine)
{
byte[] feature = null; facerect = null;
try
{
int width = 0; int height = 0; int pitch = 0;
Bitmap bitmap = new Bitmap(imageParam);
byte[] imageData = getBGR(bitmap, ref width, ref height, ref pitch);
IntPtr imageDataPtr = Marshal.AllocHGlobal(imageData.Length);
Marshal.Copy(imageData, 0, imageDataPtr, imageData.Length);
ASVLOFFSCREEN offInput = new ASVLOFFSCREEN();
offInput.u32PixelArrayFormat = 513;
offInput.ppu8Plane = new IntPtr[4];
offInput.ppu8Plane[0] = imageDataPtr;
offInput.i32Width = width;
offInput.i32Height = height;
offInput.pi32Pitch = new int[4];
offInput.pi32Pitch[0] = pitch;
AFD_FSDK_FACERES faceRes = new AFD_FSDK_FACERES();
IntPtr offInputPtr = Marshal.AllocHGlobal(Marshal.SizeOf(offInput));
Marshal.StructureToPtr(offInput, offInputPtr, false);
IntPtr faceResPtr = Marshal.AllocHGlobal(Marshal.SizeOf(faceRes));
//人臉檢測
int detectResult = AFDFunction.AFD_FSDK_StillImageFaceDetection(DetectEngine, offInputPtr, ref faceResPtr);
if (detectResult == 0)
{
try
{
object obj = Marshal.PtrToStructure(faceResPtr, typeof(AFD_FSDK_FACERES));
faceRes = (AFD_FSDK_FACERES)obj;
for (int i = 0; i < faceRes.nFace; i++)
{
MRECT rect = (MRECT)Marshal.PtrToStructure(faceRes.rcFace + Marshal.SizeOf(typeof(MRECT)) * i, typeof(MRECT));
int orient = (int)Marshal.PtrToStructure(faceRes.lfaceOrient + Marshal.SizeOf(typeof(int)) * i, typeof(int));
if (i == 0)
{
facerect = CutFace(bitmap, rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top);
}
}
}
catch (Exception ex)
{
LogNetWriter.Error("人臉檢測時出錯:" + ex.Message);
}
}
if (faceRes.nFace > 0)
{
try
{
AFR_FSDK_FaceInput faceResult = new AFR_FSDK_FaceInput();
int orient = (int)Marshal.PtrToStructure(faceRes.lfaceOrient, typeof(int));
faceResult.lOrient = orient;
faceResult.rcFace = new MRECT();
MRECT rect = (MRECT)Marshal.PtrToStructure(faceRes.rcFace, typeof(MRECT));
faceResult.rcFace = rect;
IntPtr faceResultPtr = Marshal.AllocHGlobal(Marshal.SizeOf(faceResult));
Marshal.StructureToPtr(faceResult, faceResultPtr, false);
AFR_FSDK_FaceModel localFaceModels = new AFR_FSDK_FaceModel();
IntPtr localFaceModelsPtr = Marshal.AllocHGlobal(Marshal.SizeOf(localFaceModels));
int extractResult = AFRFunction.AFR_FSDK_ExtractFRFeature(RecognizeEngine, offInputPtr, faceResultPtr, localFaceModelsPtr);
if (extractResult == 0)
{
Marshal.FreeHGlobal(faceResultPtr);
Marshal.FreeHGlobal(offInputPtr);
object objFeature = Marshal.PtrToStructure(localFaceModelsPtr, typeof(AFR_FSDK_FaceModel));
Marshal.FreeHGlobal(localFaceModelsPtr);
localFaceModels = (AFR_FSDK_FaceModel)objFeature;
feature = new byte[localFaceModels.lFeatureSize];
Marshal.Copy(localFaceModels.pbFeature, feature, 0, localFaceModels.lFeatureSize);
localFaceModels = new AFR_FSDK_FaceModel();
}
}
catch (Exception ex)
{
LogNetWriter.Error("提取特征時出錯:" + ex.Message);
}
}
bitmap.Dispose();
imageData = null;
Marshal.FreeHGlobal(imageDataPtr);
//Marshal.FreeHGlobal(faceResPtr);
offInput = new ASVLOFFSCREEN();
faceRes = new AFD_FSDK_FACERES();
}
catch (Exception ex)
{
LogNetWriter.Error("識別人臉並提取人臉特征出錯:" + ex.Message);
}
return feature;
}
當然了,比對的時候也作了一些修改,就是當比對完了以后,就做了指針釋放;
Marshal.FreeHGlobal(firstFeaturePtr);
Marshal.FreeHGlobal(secondFeaturePtr);
Marshal.FreeHGlobal(firstPtr);
Marshal.FreeHGlobal(secondPtr);
經過這一次修改后,再發布到服務器,喲…不錯哦..運行的時間久了…但還是會卦,而且那個w3wp.exe還是會不斷的拉內存;這個版本的運行時間可以達到4小左右了;我就想總得有個解決辦法吧;再次致電虹軟,再次反映這個問題,虹軟這邊給我的建議就是不要去進行多線程,我想想也對,要把邏輯簡單化,我就把識別核心打包成一個EXE.然后在Program里調用這個EXE.意思就是每當我有需要識別的圖片,我就調一個EXE.然后EXE處理完以后,就自我釋放了… 於是我改了第三版:
//這里就是一條線程在做處理
string strmatch = string.Empty;
ControlExeClass _ControlExeClass = new Model.ControlExeClass();
//這個方法是調一個EXE,EXE的內容是:ControlExeClass.cs;
//做的任務就是把圖片進行人臉檢測,人臉特征提取,人臉識別;
bool bo = _ControlExeClass.ControlExe(userid, studyid, photoid, pathstr);
if (bo)
{
iCheck_OK++;
label5.Text = iCheck_OK.ToString();
strmatch = " 比對結果:OK";
}
else
{
strmatch = " 比對結果:NO";
}
string dates = " 比對時間:" + DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss");
textBox1.Text += " USERID:" + userid + " STUDYID:" + studyid + " PHID:" + photoid + strmatch + dates + Environment.NewLine;
然后那個EXE就是沿用MatchUserFace調用類,在EXE的主線程里完成調用;還別說,用了這個方法后,內存不拉升了,而且w3wp.exe上漲,也只是在EXE工作的一剎那上來,EXE干完活后,它就會生成一個新的w3wp.exe,舊的w3wp.exe那個會被注銷掉…嘩…想想就開心,終於如願解決了問題,但….當一個人覺得越順利時,往往大麻煩就會來了.正如我覺得上天不會對我那么好一樣,運行了大概一天后,程序還是卦了.蒼天呀,大地呀,我到底做錯了什么…. 正在我一籌莫展時,我就老記恨這個w3wp.exe,到底是什么東東,好,度娘下徹底了解下它. 度娘是這么形容它的: w3wp.exe是在IIS（因特網信息服務器）與應用程序池相關聯的一個進程，如果你有多個應用程序池，就會有對應的多個w3wp.exe的進程實例運行。這個進程用來分配大量的系統資源。 好,既然說我的IIS里的應用程序池,那我就對我的應用程序池進行固定內存回收不就好了嘛;我就對線程池做了一個固定內存回收,當達到400000KB時就做一次回收. 這一下設置做下去后,的確是立竿見影的,當EXE工作時w3wp.exe就從來沒高過400000KB;我想這一下應該徹底解決了吧;可是….程序還是卦了….我是真的不得上天倦顧呀… 一連幾天毫無頭緒,胡子長一臉了,也沒心思刮,領導這邊還想刮我骨頭呢…唉…上下壓力都好大呀.搞得我肚子也不舒服,就去廁所蹲了個坑,還別說,這個坑,含金量特高.又一道靈光打進了我的腦門,我想呀,是不是我的遞歸出現了問題呢???我就回去看了下代碼,我的遞歸邏輯是沒有問題的呀,一步步有板有眼,這是怎么回事呢,我又度娘了下,關於C#的遞歸,是這么形容的:一個算法中，由於遞歸調用次數過多，堆棧是會溢出。遞歸使用的內存大小累計達4G,系統就會進行內存回收. 至於何時收,怎么收,就是windows的事情了.乖乖…既然有這么一個限定,我不用不就好了嘛,我就用死詢還不好嗎? 所以第4版修改如下:
private static void CycleData()
{
while (true)
{
if (_DoWork)
{
break;
}
else
{
QueryDataFile("U");
Thread.Sleep(1500);
}
Thread.Sleep(2000);
}
}
至此所有問題解決!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!哦…..忘說了,我后來沒有單獨調用EXE這種方法了,改成了第一版的控制台程序,其結果是一樣的;
現在…呵呵…我可是十分輕松着座在大班椅上,喝着奶茶,身邊座着小秘,我說,她打的這篇文章…呵….開玩笑了,文章里每個字都是我自己親手敲的,同時也十分感謝虹軟能提供這么優秀的SDK供我使用,更要感謝虹軟的技術支持,給我莫大的幫助; 最后總結幾點:
1.SDK可以只初始化一次,然后ref傳參進結構體,就可以一直用下去;
2.每個Marshal.AllocHGlobal,用完以后,一定要釋放;
3.可以異步回調進行;
4.AFRFunction.AFR_FSDK_ExtractFRFeature; AFDFunction.AFD_FSDK_StillImageFaceDetection; 這兩個函數要判斷返回值是否等於0;
5.最最最重要一點,嚴禁使用遞歸去調用;寧願用死詢代替;(因為這個就是導致我程序死掉的主因),因為遞歸要是深度太大,而且次數過多,累計內存使用達4G以上,系統就會做一次線程與內存回收,至於怎么收,何時收就是不定時的,所以一定不要用遞歸,這個是我在C#官方看到對於遞歸的解釋;
6.如果是使用windows服務器進行虹軟SDK的;建議IIS線程池做一個固定內存回收機制; 最后上傳一下幾個示例片段吧,因為個中涉及到一些數據庫操作,我整個工程就不上傳了