今早在GitHub上收到一則issue，發信人為Suaro。

Suaro希望使用OpenCV來實現模型加載與推演，但是沒有成功，因此開了issue尋求我的幫助。

現場圍觀該Issue：

https://github.com/yinguobing/facial-landmark-detection-hrnet/issues/3

說實話這個功能并沒有在我最初的考慮范圍內。該項目所遵守的開源協議意味著我沒有義務去解決這個問題。但是，Suaro提issue的方式在我看來是非常值得贊許與推廣的。所以，我不僅幫TA解決了issue，還要以此為樣本，與大家分享下一些提issue時的注意事項。

首先，我們先解決OpenCV加載模型的問題。

使用OpenCV加載模型

OpenCV在3.0的版本時引入了一個dnn模塊，實現了一些基本的神經網絡模型layer。在最新的4.5版本中，dnn模塊使用函數 readNet 實現模型加載。不過根據官方解釋，OpenCV不支持TensorFlow所推薦的模型保存格式 saved_model 。所以在加載模型之前，模型需要首先被凍結。

凍結網絡

在之前的文章“TensorFlow如何凍結網絡模型”中介紹過了凍結網絡的具體含義以及原理。但是在TensorFlow2中網絡凍結似乎被棄用了，文中提到的凍結腳本也無法使用。幸運的是，網絡凍結的原理仍然有效，而且OpenCV作者提供了一小段示例樣本展示了凍結網絡的方法如下：

importtensorflowastffrom tensorflow.python.framework.convert_to_constants import convert_variables_to_constants_v2# Load the model from saved_model.loaded=tf.saved_model.load('my_model')infer=loaded.signatures['serving_default']f=tf.function(infer).get_concrete_function(input_1=tf.TensorSpec(shape=[None,256,256,3],dtype=tf.float32))f2=convert_variables_to_constants_v2(f)graph_def=f2.graph.as_graph_def()#Exportfrozengraphwithtf.io.gfile.GFile('frozen_graph.pb','wb')asf:f.write(graph_def.SerializeToString())

凍結TensorFlow2模型的示例代碼，作者：Dmitry Kurtaev

在這段代碼中，模型的推演功能被包裹在 tf.function 中，構建了靜態圖。然后通過 convert_variables_to_constant_v2 將變量轉換為常量，并將最終獲得的 graph_def 寫入單獨的protobuf文件。

加載并推演

網絡凍結完成后，并可以使用OpenCV加載推演了。示例代碼如下：

import numpy as npimportcv2ascv net=cv.dnn.readNet('frozen_graph.pb')inp=np.random.standard_normal([1,3,256,256]).astype(np.float32)net.setInput(inp)out=net.forward()print(out.shape)

OpenCV加載模型的示例代碼，作者：Dmitry Kurtaev

Issue順利解決。 注意TensorFlow版本為2.3.1。OpenCV版本4.5.0。

接下來我們來談談如何提issue。

Issue是什么

Issue在中文環境下多譯為“問題”，而且是那種可能造成反復糾纏、難以解決的問題例如社會問題（social issue）。電視劇“神盾局特工”中的“反派”局長也曾用這個詞來調侃Daisy。

實際上，這個詞在現代制造業中也經常會遇到。在我工作的第一家公司中，每個項目在啟動前都會組織不同維度與形式的技術研討，核心就是可能會遇到的“技術issue”。而且項目一旦進入實質性質的試生產流片階段，大家最害怕出現的也是issue。它通常意味著加班、業績壓力以及可能的推倒重來。

軟件行業中，issue這個詞常被用來指代計算機程序使用過程中出現的異常表現。因此源代碼托管平臺GitHub專門為每一個項目提供了一個專門的討論空間，供代碼的使用者提出自己遇到的issue使用。這個區域在UI界面上緊挨著源代碼，其重要性可見一斑。

圖源：作者GitHub頁面截圖

造成Issue的原因

程序的異常行為背后可能存在多種原因，有可能是代碼中存在的錯誤，也有可能是使用者的不當操作造成。例如一臺微波爐無法加熱食物，可能是磁控管故障，也有可能是沒插電源。面對“無法加熱”這個現象，找到其背后的原因是解決issue的關鍵。這時候，提issue的方式在某種程度上直接決定了問題解決的速度。根據我的觀察，一個優秀的issue提出者能夠做到以下幾點。

嘗試解決問題

如果你家的微波爐不工作了，大部分人的第一反應可能會去檢查電源線是不是沒有插上。這就是在嘗試解決問題。理論上越是成熟的項目代碼，發生故障的概率越低。一旦異常事件發生了，首先要嘗試排除最可能發生的狀況。畢竟因為松動的電源線叫廠家的維修人員上門服務，除了費用不說，主要是耽誤自己的午餐。

嘗試解決問題的手段因每個人的能力不同而不同。在保證安全的前提下盡力即可。例如本次提issue的小伙伴就詳細的描述了TA已經嘗試過的方案，而且以列表的形式一一列出，這無疑顯示了TA的誠意，是加分項。

逐條列出已經嘗試過的方案

反過來，如果issue提出者上來就說“XXX不能用，該怎么辦呀”，這樣多多少少顯得有些伸手黨，不過也沒什么大不了，只要TA能做到——

準確描述現象

這是最常見的現象，不僅僅是issue區域，在生活中也隨處可見。當問題出現時，無法使用語言傳遞準確的有價值信息。同樣是微波爐的例子，以下是兩種不同的表述：

A:我家的微波爐壞了，咋辦呀？

B:我家的微波爐不工作了，大火力加熱兩分鐘，指示燈不亮，微波爐不響，食物不熱。電源插好了，可能是什么原因呀？

準確描述現象的最大好處在于這樣做可以盡可能的排除各種導致故障的可能性。最為廠家售后人員，如果你聽到的是第一種回答，你多半會要求用戶檢查電源線是否插好。而第二種回答顯然已經排除了這種可能性，甚至可以初步估計出故障的嚴重程度已經超過了普通用戶的解決能力。這無疑有利于問題盡快解決。

代碼issue與之類似，當問題出現時，在issue中要盡可能的描述出具體的現象。一個糟糕的描述可能是：

A: 我的代碼奔潰了，是什么原因呀？

而一個優秀的描述則是：

B: 我在執行 python3 train.py --batch_size=32 的時候訓練中斷了，并且顯示錯誤信息 ValueError ...

代碼的錯誤信息就像是微波爐上的指示燈，它可以提供非常有用的信息幫助排除錯誤發生的原因。解決代碼的錯誤需要“抓現行”，也就是要讓程序在你眼前奔潰給你看。這也是為什么幾乎所有的代碼作者要求提issue的時候附上導致錯誤出現的具體指令或者示例代碼。

這一點Suaro就做得很好。TA在issue中附上了完整的錯誤信息：

在issue中附上具體的錯誤信息

一般來說，做到這種程度解決該issue就有希望了。如果是代碼問題，多半會修復。如果該issue無法復現，那有可能不是代碼問題，此時代碼作者多半會要求你——

提供必要信息

實際上這是最基礎的要求，但往往是最先被忽略的部分。繼續拿廣受歡迎的微波爐舉例。作為廠家的售后人員，當你要求客戶提供微波爐的型號代碼后，你有可能會發現用戶買的其實根本就不是微波爐，而是洗碗機！

這一問題在軟件行業更加突出。一是因為同一個軟件可能存在多版本并存的現象。例如OpenCV就有2.x, 3.x和4.x這三個主版本分支。TensorFlow也有1和2兩個主版本。除此以外，現今軟件更迭速度前所未有的迅速，nightly（每日更新）也不罕見。如果把git commit算進去那更是多如牛毛。所以issue可能是由于版本不兼容造成的。

所以，我強烈建議在提issue時一定要附上自己所使用的環境信息。實際上，GitHub已經內置了issue模板，將必要的信息嵌入進去，用戶提issue就像是在做選擇題一樣。

TensorFlow提供的issue模板

Suaro在issue中并沒有附上這部分信息。這種情況下我會默認TA使用的環境信息與我在README文件中的一致。當然，反過來考慮，當代碼作者的環境與README不同時，也需要在issue回復中明示。

我在issue回復時標明了版本信息

交流溝通的能力

寫了這么多關于issue的內容，聰明的你應該已經看出來了。Issue只是表面形式，內里的核心是溝通與交流。有誠意的、有效率的溝通與交流是每個人都應該掌握的能力。工作中它有助于項目推進，生意中可以避免誤解與爭端，生活中可以讓你交到真心朋友。雖然目前的大環境對于真誠交流的人不那么友好，但是，對于每一個真誠的人，總會有另一份真誠不負期望。

責任編輯：xj

原文標題：使用OpenCV加載TensorFlow2模型

文章出處：【微信公眾號：新機器視覺】歡迎添加關注！文章轉載請注明出處。