（keras-yolo3原始碼分析已經滿天飛，不重複解讀）

問題1：原始的yolo3原始碼，data_generator過程和模型train過程是阻塞式的，模型train速度會受到data產生的影響

解決思路：單獨開一個thread，將data_generator過程wrap起來，做成一個數據提供執行緒，資料執行緒採用codition機制，根據batch_size大小，提前準備5~10倍的資料量，保證模型每次fit的時候，能立即拿到資料，無法等待。

問題2：訓練集合有小目標，模型訓練適過程中，loss先逐步下降，中間突然變為inf，再變為nan

解決思路：loss變為inf，說明梯度計算出現了爆炸，梯度反向傳播出現了0。需要檢查gt（真實的bbox）的小目標是否過小，訓練過程在準備true box的時候，由於需要計算中gt的中心點（(x1 + x2)/2）導致中心點x或y為0！如果存在過小的gt，需要剔除

問題3：numpy中array的shape，PIL中Image的size的區別：

解決：

numpy的array的shape：先h，再w

PIL的Image的size：先w，再h

問題4：在model過程中，模型的中間權重儲存過多，佔用大量磁碟空間，有指定的批量刪除：

解決：

-- 刪除前40個epoch的模型權重，其他的不刪除

ls | grep "ep0[0123]" | xargs rm -rf

問題5：原始訓練集合中真實樣本過少，怎麼辦？

解決方法：

step1：獲取真實樣本的標籤（只是標籤），再根據其他背景圖和標籤做合成；

step2：生成合成的圖片過程，而非真正的圖片（真正的圖片少則幾千，多則幾萬，數目過多，伺服器磁碟不夠！），這時需要保留標籤在背景中的座標以及背景圖片需要裁剪的座標（如果需要裁剪）

step3：:在模型訓練的過程中，實時的動態合成圖片

問題6：採用pytho的threading庫，自定義執行緒類時，同時加入了condition機制，如何安全的退出執行緒

解決方法：

step1：自定義執行緒類中，新增一個stop函式，呼叫cond.notify()喚醒可能的wait執行緒。

step2：run方法中，如果存在迴圈操作，加入flag標記，保證在wait執行緒喚醒之後，會退出run方法，而不是又進入下一次迴圈。

-- over --