中秋節逛寶雅時，剛好看到兩個砧板架，思索了一下，配合束帶應該可以當我的土砲結構光系統架，於是便開始了第一次嘗試。
整個系統如下：
棋盤板也是很克難的用托盤來代替。
拿我最喜歡的美國隊長來當模特兒。
點雲成像品質，只有簡單用 z 當 filter，把雜點去掉。
當然少不了可愛的郭靜。
可惜 gray code + phase shift 不如我的預期，懷疑是照相機在左邊，故 3D 公式應該要改？
只能克難的在飯桌上架設環境，煮飯時又要清空，回復時還要小心不要讓校正好的投影機和相機跑掉，對於第一次的嘗試，我個人覺得至少有 70 分了吧？
繼續思考數學公式中…
2023/10/03 更新
土砲歸土砲，精度看起來還是有的，我的棋盤格橫格約為 17.5mm。
當初使用單目結構光架構是因為我只有一台 webcam，但投影機畢竟是投影機，兩個不同裝置的 model 不一定能完美 match，如果是雙目架構，投影機只是輔助，理論上精度會比現在好，故問題只剩下雙目相機拍照時要保持同步以避免看到的環境光不一致，看來我皮包的小朋友又要出走了？畢竟孩子的學習不能等呀XD
2023/10/04 更新
還是覺得相機擺哪一邊不應該影響數學公式，也就是投影機 y 座標的那個公式，畢竟是從 P1 和 P2 投影矩陣聯立後解 Ax = 0 來的。
再仔細看了一下《Calibration of fringe projection profilometry: A comparative review》 這篇論文，在公式 29 與公式 30 有這麼一段話：「Assume that the projector and camera are arranged horizontally and only vertical fringe images are projected, we can obtain the horizontal coordinate 𝑥 𝑝 by using the phase 𝜙𝑣 ( 𝑥, 𝑦 ) according to Eq. (23) .」
所以表示我的投影機和相機應該水平擺置？但對我這個土砲結構光系統來說，我很難做精細的微調！
在不讓小朋友出走的情況下，我能不能用純軟的方式來解決這個問題呢？
2023/10/05 更新
昨天晚上很克難的用書架把投影機架高，目測照相機和投影機鏡頭中心應該有接近水平？其實不應該用這樣不科學的方式，應該用投影圖案計算來確認兩者是否有水平，但以我這個土砲系統來說，我連找墊高投影機的東西都很難找到，故我就不花時間去計算了，畢竟下班還要搞這個對老人來說也是很累XD
（謎之音：我只是想拍拍可愛的郭靜， 老天爺不要搞我了，拜託XD）
除了墊高投影機外，這次想說把距離拉遠一點，看是否能讓反光影響變小，順便測試投影機 delay 是否可以縮短，之前因為黑條紋會變藍色橘色等不同顏色，故我使用 dealy 1s 的方式來解決這個問題，但拍照的張數越多，時間就會拉長，查了一下我的投影機延遲時間為 35ms，故先用 delay 100ms 的方式來測試，即使已經放大約 3 倍，但藍橘光的情況依舊，為了保險起見還是維持原本的 delay 1s。
這次一共拍了 29 組角度圖片作 calibration，但反光比之前還嚴重，這次可能連 17 組角度都不到，我也懶得算了，面朝下的所有角度都作廢了，導致我的 RMSE 從原本的 0.53 升高到 1.60。
不只如此，我連正常的 gray code 點雲都有問題，完全看不到我的待測物，但 gray code + shift method 反而有東西，雖然雜點是比之前多，但至少是有東東的？
理論上我可以拿之前校正好的參數來套用這次拍的圖片，除了 R, t 失真以外，測了一下，果然使用之前的參數加我這次拍的圖片是可以看到待測物的，當然雜點更多尚屬合理。
帶著一顆失望的心上床去了…
今天中午吃飯回來把絕對相位值畫出來參考，v 選擇解析度的一半 240，看起來果然有錯位，算有符合點雲看到的現象。
一不做二不休，k1、k2、wrapped phase 都一起來吧。
好像看出些什麼來了？
2023/10/07 更新
星期四下班後，做了幾個調整：
01. 架高照相機而不是投影機，之前眼殘，一直以為投影機比較矮。
02. 懷疑是投影機解析度 848 跟 T 無法 matched，改解析度為 1024。
03. 計算 T 時，使用 freq 16 而不是 stripe numbers 32。
我個人覺得 2, 3 才是之前錯位的原因，但我的土砲系統一動就要重新校正，校正時又容易因為反光而得不到好的校正參數，故我也懶得驗證了。
雖然互補格雷碼法與相移法已經搞定，但坦白說沒有比單純 gray code 好多少。
底下是連假前一天下班後的測試及隔天放假第一天的一些實驗。
克難的用書架墊高照相機。
做實驗時隨手寫的筆記。
上面左邊是 gray code，右邊是 gray code + phase shift。
使用 gray code + phase shift，開燈關燈也會影響點雲品質。
材質不同也會影響點雲品質。
2023/10/09 更新
前天趁著連假的第一天，想辦法搞定 two cameras + one projector 的環境，還好有寶雅，找到便宜的手機三腳架來架設相機，右相機都已經跨到投影機 HDMI 線上才勉強維持一個還過得去的雙目相機視角，整個結構光系統終於克難的架設完畢。
上面不管是 gray code 還是 phase shift，都比原來只有一個相機時差。
中間還遇到傳說中的 OpenCV detect corners bug。
大概想試的都試了，在不繼續看其他 papers 的情況下，我這隻老狗也變不出什麼新把戲了？
額外補充：
想要加快開啟相機速度或是設定相機參數速度，可以調整 flags for VideoCapture class。
cap = cv2.VideoCapture(0, cv2.CAP_DSHOW)
但是 cap.read() 可能就要配合相機的 fps 做 delay，不然會讀到舊的資料。
已經手動拿掉無法匹配的雜點，還是做不出我心目中可愛的點雲，殘念。
精度約差了 4 mm，當然我並沒有很認真 pick points，不過誤差還是 mm 級的，too bad。
2023/10/22 更新
這個假日都在搞管委會資料，趁著煮飯前，再來玩一下結構光，之前看了一篇論文，才恍然大悟為什麼我的點雲周遭雜點很多，我們既然要用結構光來輔助雙目視覺找對應點的難題，我們本來就應該只對投影機有投射的區域做點雲才對，之前都沒認真想過，哈。
即使只是純格雷碼，只關心投影範圍還是能做出不錯的結果，只剩上面哪一小塊匹配不好，以我之前經驗，有些奇怪的地方不一定就是出現在相片 2D 對應的區域，遇到這種問題要查找，只能邊解 3D 邊把點填上點雲，才能看出是在哪裡出錯。
