pretty code

顯示具有 結構光 標籤的文章。 顯示所有文章
顯示具有 結構光 標籤的文章。 顯示所有文章

2023年12月11日 星期一

買新不買舊

雖然我後來為了精度選擇購買 REVOPOINT MINI,但如果讓我再選擇一次,我應該會改買 POP3!

REVOPOINT POP3 是今年推出的機種,本身有內建陀螺儀加上購買豪華版有附贈手機用的移動電源套組,整體使用上會比較通用。

POP3 光掃描範圍就比 MINI 大上一些,配合旋轉盤的標誌點,比較能夠對付一些沒有顯著特徵點的物件。

但我也沒有後悔選擇購買 MINI 就是,畢竟要作比較當然要跟最好的機型比,這樣也比較知道我們跟消費型機種 3D 結構光掃描儀的真實差距!

附上一張兩者的比較圖(多放上 RANGE,此機器是掃描大物件用)。


MINI 放在桌上的大小示意圖。

2023年11月29日 星期三

REVOPOINT MINI 入手

網路購物確實是比較方便,下單四天內就已到貨,比我一個一個打電話去問展示店家是否有銷售快。

只可惜我的白雪公主演唱會票夾掃不出來,應該是因為平面無特徵點緣故?


在手動刪除多幀只保留單幀後,我的土炮結構光系統與消費型機種單看 3D 點數確實沒有那麼大差異!不過這只是很初步的嘗試,等到假日有時間再來研究。


我大概能理解消費型機種設計,他們是將 3D 掃描與點雲配準綁在一起,預期使用者是要掃瞄一個整體物件,故他直接偵測待掃瞄物體是否有特徵點可供辨識,這就是為什麼我的票夾無法被他接受,解決辦法便是貼上配件裡的小圓點貼紙。

不過我購買這台機器最主要的目標是要知道點數差異,對我來說如果能有所謂原始單幀的操作模式,我在做比較時就會更方便,我猜是沒有這樣的功能,但回頭還是把說明書或操作軟體說明書看過一遍。

2023/11/30 更新

試著將美國隊長放遠,距離約 25 ~ 27 cm,軟體介面上顯示位在較遠的範圍,這次單幀點數只剩 2 萬 7 左右。



2023/12/01 更新

將兩個點雲同時用 CloudCompare 開啟,MINI 的 Z 座標是負的,且似乎跟我的土炮系統是上下顛倒?


將我的土炮點雲對 Z 軸做 translation 彼此拉近好一起放大比較,我的點雲確實是比較疏鬆。


雖然我的土炮結構光系統到消費型機種這條路還是有很多軟硬體整合步驟要做,要學習點雲配準以及其他未知補強,但整體感覺並沒有我想像的困難,哈。

晚上拿出 turntable,讓它自動轉 2 圈,使用預設一鍵處理的情況下,點雲數約為 31 萬。


一些操作小技巧

左上角曝光視窗盡量不要有紅色跟藍色,Red is overexposed,Blue is underexposed。

非彩色模式下,綠色表示現在被 scanner 看到的部分,藍色則表示之前掃描過的部分。

2023/12/02 更新

即使旋轉盤上有小圓點,票卡夾還是無法被辨識到,不想貼上貼紙的情況下所有的測試也在此告一段落。

有時候真想不通,我的土炮結構光第一次嘗試時,校正做得並不好,投影機解析度也只有 640 x 480,反光手機表面卻還能依稀看到妹子?是因為背景用全黑嗎?至少 MINI 一樣對反光面沒轍!



有了對照組 MINI 後,之後如果又想玩結構光,大概知道努力的方向了。

有沒有人想花兩萬接手近全新 REVOPOINT MINI 呀?

2023/12/04 更新

昨天晚上總覺得哪邊怪怪的?後來才想到拼接模式應該要選標記點拼接,可惜時間太晚無法驗證,早上起來試了一下,勉強可以配合旋轉盤掃出點雲,但在多轉了幾圈後,因為標記點確實過少(MINI 掃瞄範圍過小,標記點被物體擋住,單幀最多沒有超過 8 個標記點),追蹤就出現問題了,最後在拿掉後面的幀數後,點雲總點數約為 31 萬 5 千(雙面),我的土炮結構光系統只掃一次的情況下,點雲點數約為 9 萬 5 千(單面)。



2023/12/11 更新

拿出原始照片計算一下,票卡物件約在圖片座標 (580, 289) ~ (1102, 486) 這個區間,換算 pixel 應該約為 523 x 198 = 103,554 個點,有效 3D 點數比例約為 91.74 %。

換句話說,那個座標範圍內的 pixel 我幾乎都可以轉成有效點。


將 mask 中,black_image 比 white_image 亮的地方顯示為綠色,整個投影機投射的範圍內有效點數數量確實還不錯。


美國隊長相較之下就差了一點。

2023年11月23日 星期四

有內鬼,停止交易

沒想到老婆大人居然沒聽過這句臺詞,看來我們有代溝?

前天主管突然告知某部門想要和我跟我同事聊聊,看看是否有機會過去幫忙,我們都覺得聊聊也不錯,便在今天跟該部門主管聊了一下。

初步感覺要做的事還蠻有趣的,應該也是我擅長的,便表達有意願過去試試,當然前期免不了要多學一些新的東西,但與純數學比起來確實有趣多了,最主要還是做的事對公司有幫助,畢竟我還蠻喜歡這家公司,我想該主管一定覺得奇怪幹嘛問了好幾次對公司有沒有幫助XD

總之,目前就看該部門最後意願,上不上都不錯。

假設最後過去,手上想做的事要做些安排才行。

簡易管委會財報系統原本預期花 2 天簡單學 Vue.js,3 天時間開發,再留 2 天跑一下 use case,確認這樣的設計對委員們有幫助,畢竟做事還是要有意義,去的話這些事可能就要分段進行,最糟情況在過年放假時完成所有事項?

3D scanner 雖然已經決定買 Pop3,之前問了兩家代理商都沒有現貨,還是改採網路下單排預購?

還是想讓 KOReader 離開後藍牙可以正常,這個應該只能趁假日零碎時間來應用,就讓水到自然渠成吧。

假設最後沒過去,就照之前順序完成相關事項並順便放大假,但中間還想多完成一個 Kobo EInkBro,畢竟 GCP VM 都還沒砍,每月一直燒錢也不是辦法(目前來到歷史新高 NT $170 / per month)XD

2023年11月13日 星期一

才下眉頭,卻上心頭

昨天在回父母家前終於把上上星期打好的管委會舊資料電子檔再核對一次,只有兩年半的資料也花了我了六日不少時間,雖說在打舊資料時就會核對一次,也趁使用 Python tool 填上分析總表時自動重新計算一下每月活存餘額作檢查,但沒有再核對一次,心裡總覺得不踏實,畢竟資料正確性才是第一重要, 目前總算是搞定了一件事。

因為一直把這件事放在心上,導致其他想到的事情都只能先用頭腦當暫存區,再加上本週已經開獎,因為沒時間原本已經想放棄了,後來還是覺得有點可惜,記錄一下自己的思路避免以後再次回想。

01. 退出 KOReader 後,bluetooth 無法使用問題。

我能理解開發團隊為什麼要 kill bluetoothd,一來可以省電,二來希望回去 Kobo Nickel 時可以讓 bluetooth 正常,無奈這招行不通。

我想以那團隊的能力 review chip spec 功力一定是不在話下,連他們都沒想到的事代表真的不可行嗎,還是只是純粹對藍牙翻頁器沒有興趣?畢竟會看電子書的人分為兩派,一派很喜歡用翻頁器,另一派卻對翻頁器嗤之以鼻XD

首先,需先釐清問題所在,假設是硬體問題,想辦法 reset chip 再 init 一次應該就可以了?

如果只是 bluetooth status 不同,導致 Nickel 認為有問題而不使用藍牙,是否可以去 /etc/rule.d 看開機時對藍牙做了什麼事,只要再呼叫一次該 script 即可?

02. 點雲點數的差異是如何而來。

雖然還未購買 3D scanner,但我內心總隱隱覺得我的土砲結構光系統跟幾萬塊的消費型機種應該沒有到 100 倍的差距?

回想一下,點雲起手式是什麼,不就是從 pixel cord decode projector cord,故 1 個 pixel 只要是 valid,就會作三角測量產生 1 點才對

換句話說,1920 x 1080 的 camera resolution,假設 valid mask 是 60%,則一次的總點數就是 1920 x 1080 x 0.6 = 1,244,160。

KEYENCE 這樣厲害的廠商一定是重覆拍照拼接或是做額外插值才能得到那麼豐富的點雲資訊?(印象中 33 mm size chip 似乎就拍了 10 幾張?用有 1000 多顆錫球那面來看,點雲點數約為 551 萬

以後如果請廠商 demo 還是得先有基礎知識才不會霧裡看花,什麼重點都沒看到

2023年9月30日 星期六

第一次結構光初嘗試

中秋節逛寶雅時,剛好看到兩個砧板架,思索了一下,配合束帶應該可以當我的土砲結構光系統架,於是便開始了第一次嘗試。

整個系統如下:


棋盤板也是很克難的用托盤來代替。


拿我最喜歡的美國隊長來當模特兒。


點雲成像品質,只有簡單用 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 邊把點填上點雲,才能看出是在哪裡出錯。

2023年9月27日 星期三

9 又 4 分之 3 月台

結構光也研習了一陣子,反正家裡也有之前買的 webcam 和 projector,想要真的來跑看看結果,不然都只是紙上談兵,正所謂魔鬼就藏在細節裡,只有真的動手去做,才能知道理論與實務的差距,另外,有一些眉角,沒有真的動手做你永遠不會知道!

結構光第一件事就是要打 pattern,gray code 算是一個比較簡單,正確性也還不錯的編碼,很適合第一次嘗試。

原本以為要全螢幕投影 pattern 是件很麻煩的事,是不是要透過 OpenGL 之類的比較底層的控制,稍微 Google 了一下(Google 25歲生日了,時間過得好快,我算是看著他出生的XD),原來用 OpenCV 就可以了,一點都不困難,看起來不需要特別用 Linux 環境。

由於我的投影機很陽春只有幾千塊,故我本就打算解析度只用 640 x 480,沒想到用之前學習的專案產生投影 pattern 後,看著這些 pattern 就讓我不禁產生了疑問,結構光的第一張圖片不是應該黑白各半,為什麼我的白色只佔很小的一部份?

一開始以為是不是作者寫的 code 有問題,看了一下,都是用 OpenCV graycode class,理應沒問題才對,稍微看了下 OpenCV document,他是參考某篇論文實做 class,害我一直往光的二值化方向去思考?

沒關係我有之前寫的 decoder 的程式,一跑完看到 project x index 是從 0 ~ 639,我就馬上知道為什麼了,一開始不知道為什麼想不到?

640 取 log2 要 10 個 bit,故範圍是 0 ~ 1023,但我的投影機解析度是 640,當然只有這張圖前面的 8 分之 5 而已! 

2023年9月13日 星期三

遺珠之憾的雞肋

這個標題下的有點誇張,但我的感覺還真是如此XD


上面是一個使用 binary code 的結構光專案,有趣的是作者使用 blender 軟體來建構所有物件資訊,並非由真實的照相機及投影機所產生。

純以 decode 來說,gray code 相臨數字只差一個 bit 的編碼特性會比 binary code 在找對應點時好很多,故實務上應該是比較少使用它來編碼,目前以我在大衛朗基羅的經驗來看,gray code + phase shift method 應該是有比較好的成像品質。

之前在開始學習結構光相關主題時,我就把 github 上的 700 多個專案看過一遍,坦白說這是個苦差事,在只知道結構光皮毛知識下,要如何分辨哪個專案能幫助學習確實有點困難!單純看 README.md 不太能得到有用資訊,除非專案作者很用心在寫文件XD

故我的 SOP 就是檢查 code 是否齊全,有沒有相機圖片,是否有給相機內參或 R、t,當然最重要的一點就是 code 是否能跑?

如果單純是 Python 還好辦,相關 modules 裝一裝就好;Matlab 沒有軟體就算了,只要有 code 可以 porting 就好;但遇到 C++ 類的就沒輒,我一定要先能成功編譯它才能夠去跑它! 

這個專案很不巧的就屬於這種,即使我有 vcpkg 的加持,還是要經歷邊報錯邊檢查少了什麼再繼續安裝的無限循環,這個專案為了平行處理還使用了 halide 的函式庫,故還需要 llvm 的相關工具,印象中當初為了這個專案,假日時常要遠端登入公司電腦好確保 vcpkg 安裝相關函式庫時有順利執行,沒有半途發生錯誤被中斷,因為 llvm 很吃硬碟空間,為了這個還要搬移資料分割區資料,並執行微軟硬碟工具內建動態擴充功能擴充 C 槽才能順利安裝。

我還記得當初因為硬碟空間不足,vcpkg 安裝常出現莫名錯誤,當時沒意會到是這個原因,故我在某一次的放假遠端登入中終於放棄,改使用家裡電腦安裝。雖然最後有成功安裝,但因為兩邊電腦發生過的安裝錯誤實在太多,故我也來不及寫筆記XD

好不容易順利執行,即使都是使用 blender 的假資料,binary code 的 dense match 還是很吃二值化設定,故成像品質也只是 so so,所以最後這個專案也沒有放進我安排的學習清單中,所以我才說它是一個遺珠之憾的雞肋XD

剛在電腦看到殘缺的筆記資料,還是把它記錄一下好了,凡走過必留下痕跡。

build llvm error
'atlbase.h': No such file or directory

印象中,這個 error 是 VS building tool 少裝 ATL 相關的套件,再 Google 一下應該就有答案?

-----------------------
vcpkg install halide:x64-windows
vcpkg install glm:x64-windows
vcpkg install glfw3:x64-windows
vcpkg install llvm[target-all,clang-tools-extra]:x64-windows

-----------------------
cmake . -A x64 -DCMAKE_TOOLCHAIN_FILE=C:/src/vcpkg/scripts/buildsystems/vcpkg.cmake
msbuild xxx.sln /p:Configuration=Release

2023/09/14 更新

花了好幾個假日編譯好的東西還是想要留個記錄,於是在辦公室的電腦又做了一次XD

果然,憑著殘缺的筆記是不夠的,這次在 build halide 又遇到奇怪的問題,改先安裝 llvm,It is building …

2023/09/14 更新

llvm 遇到錯誤了,沉思中…

2023/09/27 更新

擴充記憶體到 16G 後,看起來記憶體不足的問題有解決,但在寫入檔案時會失敗。

mt.exe : general error c101008d: Failed to write the updated manifest of xxxxx.

試著將 C:\src\vcpkg 加到 Windows Defender 的例外掃瞄資料夾,但這個問題還是沒解決,可能真的必須關掉防毒軟體才行,我們可能沒有權限做此件事?