把 GPX 路線動畫搬回 GPU:一個 4K60 Windows 原生工具的設計筆記
GPX Animator GPU Edition 是我做的一個 Windows 原生路線動畫工具。它把 GPX 路線畫在地圖上,讓鏡頭跟著路線移動,最後輸出成可以播放的 MP4。
它把路線統計、地圖動畫、GPU 繪圖與 MP4 編碼放在同一個工具裡,適合把一份騎乘紀錄整理成可以播放的路線影片。
載入一份 GPX 路線
以 0706路線.gpx 為例,程式載入後會顯示:
- 路線長度:61.27 km
- 爬升:794 m
- GPS 點:4,161 個
- 程式移除停留點:254 個
地圖畫面也真的把路線畫出來,左上角可以看到目前的公里數與海拔,右上角則有整段路線的海拔變化。

實際載入 0706路線.gpx 後的原生 Windows 介面。這張圖同時保留了路線統計、地圖預覽、HUD 與海拔圖設定。
從載入到輸出
整個操作很直接:
- 開啟 GPX Animator GPU Edition。
- 載入
0706路線.gpx。 - 確認地圖上有路線,並檢查距離、爬升與 GPS 點數。
- 選好輸出設定,按下「輸出 MP4」。
可以保留衛星地圖,讓攝影機跟著路線走,也可以開啟 HUD 和海拔圖。最後的影片不只是地圖上有一條線,還能看出目前走到哪裡、爬升變化如何。
輸出設定
這組輸出設定是:
- 畫面比例:16:9
- 解析度:1080p,也就是 1920×1080
- 影格率:30 FPS
- 編碼:H.265 / HEVC
- 影片秒數欄位:20 秒
- 品質:高畫質
GPU 負責把地圖動畫畫出來,HEVC 負責把畫面壓成 MP4;30 FPS 則讓播放看起來比較順。
讓「不禮讓行人」變成可追蹤的事件:YOLOv8 × DeepSORT
這個專案的目標很簡單:把交通影片放進去,讓程式找出人、車和斑馬線,再把可能的「不禮讓行人」畫在輸出影片上。它不是只看單張圖片,而是把一段影片連續看完,才能判斷車輛和行人之間發生了什麼。
影片進入系統後,YOLOv8 會在每一格畫面裡找出行人、車輛、機車和斑馬線;這個步驟就是物件辨識,結果會以框線標在畫面上。接著 DeepSORT 會替這些物件保留 ID,讓程式知道前後畫面中的「車輛 3」是同一台車,而不是每格都重新計算。OpenCV 負責讀取與寫回影片,PyQt5 則把選檔案、預覽、旋轉校正和進度顯示整合成桌面介面。
使用流程
操作流程是四步:
選影片 → 選模型 → 選「車輛不禮讓行人偵測」→ 輸出標記後影片
選好偵測模式後,系統會先用 YOLOv8 找出畫面裡的人、車和斑馬線,再用 DeepSORT 把同一個物件在不同畫面中的位置串起來。這樣程式才有辦法從一張一張的畫面,累積成「這台車有沒有在行人通過時停下來」這種事件,而不是只根據某一格畫面猜測。
使用者介面
載入影片後,PyQt5 做成的主畫面會顯示影片路徑、預覽畫面、模型選單,以及「車輛不禮讓行人偵測」按鈕;下方還有單部影片和全部影片的處理進度。使用者不需要另外操作命令列,就能在同一個視窗完成設定。

載入 zebra7.mp4 後的主畫面:影片、模型和偵測模式都可以在同一個介面中設定。
開始處理後,預覽畫面會顯示目前的影片狀態,進度列也會跟著更新。

執行中的介面會同時顯示目前影片和整批影片的處理進度。
旋轉校正
如果原始影片是歪的,可以先在校正頁調整角度,再進入後面的偵測。程式會用 OpenCV 將畫面旋轉後再交給後續流程,讓斑馬線、道路方向和物件位置更容易被規則判斷;這不是改變影片內容,而是先把視角整理成比較好辨識的方向。

旋轉校正前,畫面中的道路方向還沒有對齊。

旋轉校正後,影像方向已經調整成比較適合繼續偵測的角度。
實際輸出結果
原始畫面和輸出結果可以清楚對照:輸出影片會加上偵測框、物件 ID,以及「Fail to yield to pedestrians」提示。偵測框代表系統在畫面中找到的物件,ID 則用來追蹤它在連續畫面中的移動。

原始畫面:還沒有加入偵測標記。

輸出結果:畫面中標出行人、車輛、斑馬線,以及「Fail to yield to pedestrians」事件。這個提示不是 YOLOv8 直接猜出來的,而是程式把辨識和追蹤結果放在一起,再根據斑馬線區域、行人位置、車輛方向與移動軌跡做判斷。
不同時間與道路場景都會留下相同格式的標記結果。白天的畫面可以看到斑馬線和車輛標記,夜間畫面則保留了車燈、道路與偵測框。

日間道路場景的實際標記結果。

夜間道路場景的實際標記結果。
輸出影片中的畫面也會保留物件 ID、偵測框和事件提示。因為 DeepSORT 會延續物件的 ID,使用者可以從連續畫面看出同一台車如何接近斑馬線,以及事件提示是在什麼情況下出現。下面是兩個不同道路場景的畫面:

日間影片畫面;可看到跨畫面的物件 ID 與不禮讓提示。
LadaGAN 做得太逼真之後:一場生成器與判別器的拉鋸
這是我在國立東華大學資訊工程學系「深度學習基石與實務」課程的第二個作業。作業表面上是在 CelebA 上訓練 GAN、生成一批人臉,實際上卻把三件事綁在一起:生成影像、建立可追蹤的 synthetic dataset,以及訓練一個能分辨真假的模型。
我一開始把問題想得很直覺:生成器越逼真,成果就越好。真正跑過幾輪模型之後,才發現事情沒有這麼單純。生成器越接近真實資料,判別器越難找到可以泛化的線索;判別器若只記住資料前處理或某一個 checkpoint 的風格,漂亮的 accuracy 也沒有太大意義。這篇筆記保留模型失敗、中間 epoch、loss 曲線與評估圖,記錄我如何在清晰度、多樣性、穩定性和運算成本之間做取捨。
Purpose:這份作業在問什麼
這份作業的目標不是只交出一張「看起來像人臉」的圖片,而是一條可以被檢查、被重跑的影像生成與分類流程:
- 在 CelebA 上訓練 LadaGAN,產生有多樣性的 64×64 人臉。
- 保留不同 epoch 的 checkpoint,從每個 checkpoint 生成固定數量的圖片,建立足夠大的 synthetic dataset。
- 把真實圖片和生成圖片混合,訓練多個分類 backbone,找出比較能辨識兩種影像分布的判別器。
- 使用最後的 EfficientNetV2-B1 對測試資料做真偽判斷,輸出 test.csv。
所以我想回答的問題不是「能不能生成一張好看的臉」,而是:
當生成器已經做得很逼真時,判別器到底還能不能學到穩定、可泛化的差異?
作業流程:從生成到判別
HackMD 報告把整個工作拆成三個階段。第一階段訓練 LadaGAN;第二階段從生成 checkpoint 建立判別器資料;第三階段用教師提供的 1,000 張測試圖片產生最後的分類結果。
64x64"] --> B["LadaGAN training
36 epochs"] B --> C["Checkpoints
epoch 1-30"] C --> D["150K synthetic faces"] A --> E["Real images"] D --> F["300K discriminator set"] E --> F F --> G["EfficientNetV2-B1
240x240"] G --> H["Real / Fake prediction"] H --> I["test.csv
1,000 images"]
三個階段的實際數字
第一階段以 64×64、像素值正規化到 [-1, 1] 的 CelebA 人臉訓練 LadaGAN。訓練曲線記錄到第 36 個 epoch;生成資料的腳本則以第 1 到第 30 個 checkpoint、每個 checkpoint 5,000 張圖片為主要設定:
從 SQL 到 Text-to-SQL:讓資料庫聽懂人話
公司、醫院、學校和政府每天都在累積資料,但「資料存在」不代表「每個人都能使用」。很多時候,我們知道自己想問什麼,卻不知道資料放在哪張表,也不知道該怎麼寫 SQL。
我的碩士論文研究的,就是如何讓使用者直接用自然語言提問,再由系統自動產生可以執行的 SQL。這項技術稱為 Text-to-SQL。
不過,在介紹我的方法之前,我想先從最基本的問題開始:資料庫到底長什麼樣子?SQL 又在做什麼?
先認識資料庫:表、欄位與資料列
關聯式資料庫可以想成一組彼此有關聯的試算表。假設一間商店有兩張表:
顧客表 customers
| customer_id | name | city |
|---|---|---|
| 101 | Amy | Taipei |
| 102 | Bob | Tainan |
訂單表 orders
| order_id | customer_id | amount |
|---|---|---|
| 9001 | 101 | 1200 |
| 9002 | 101 | 650 |
| 9003 | 102 | 800 |
直向的 name、city、amount 稱為欄位,描述資料具有哪些屬性;橫向的每一筆內容稱為資料列。整個資料庫有哪些表、欄位與型別,合起來稱為 Schema(資料庫結構)。
其中,customers.customer_id 是每位顧客不重複的編號,稱為主鍵。orders.customer_id 則指向顧客表中的同名編號,稱為外鍵。靠著這個關係,我們才知道訂單 9001 和 9002 都屬於 Amy。
真實資料庫當然比這複雜得多:可能有數十張表、數百個欄位,而且名稱常是縮寫。使用者只看到「顧客」和「訂單」,系統看到的卻可能是 cust_info、txn_hdr 和一大串編號。
SQL 是怎麼向資料庫提問的?
SQL(Structured Query Language)是操作關聯式資料庫的語言。若要找出住在台北的顧客,可以寫:
SELECT name
FROM customers
WHERE city = 'Taipei';
這三行可以直接讀成:
SELECT name:我要取得姓名。FROM customers:資料來自顧客表。WHERE city = 'Taipei':只保留城市為台北的資料。
如果問題改成「台北顧客總共下了幾筆訂單?」,就必須同時使用顧客表和訂單表:
如何架設N8N伺服器在本地端的部署教學
本文將帶你一步步從零開始,在本地端(Windows 系統為例)架設 n8n 並使用 Cloudflare Tunnel 將本地服務映射為網路可訪問的固定公開網址。過程中會詳細解說重要設定與可能遇到的注意事項。
1. N8N是什麽
n8n 是一個開源的自動化工作流程平台,讓用戶可以透過圖形化介面(拖拉節點)來串接和自動化各種工具、平台與服務,無需寫程式也能輕鬆建立自動化流程(雖然我的這個要寫不少JS跟SQL就對了)。
像是下面的圖片,有許多的節點跟綫條連接,這樣做的好處就是可讀性高,以及維護容易。

主要特點
- 開源免費:n8n 完全開源,任何人都可以免費下載、使用、修改,並根據需求自行部署在本地或雲端。
- 視覺化操作:只需拖拉節點、設定參數,就能設計複雜的自動化工作流,適合沒有程式基礎的使用者。
- 高度彈性與擴充性:支援自訂節點、腳本(如 JavaScript),也能安裝社群第三方擴充,適合開發者進行進階自動化。
- 豐富的整合能力:內建超過200~400種第三方應用整合(如 Google Apps、Slack、Trello、GitHub、AWS、Notion、LINE、Shopify 等),可滿足各式自動化需求。
- 自我託管:用戶可選擇將 n8n 部署在自己的伺服器,完全掌控資料安全與隱私
爲什麽需要N8N?
先想清楚:什麽事值得自動化?
- 重複性高:每天、每週都要做的瑣事。
- 很花時間:不是難,但就是煩、耗時。
- 流程固定:步驟一樣、邏輯清楚。 訂閲系統就符合以上所有需求
如何開始使用n8n
你可以使用:
- 官方的托管伺服器: https://n8n.io/
- 本地端伺服器: 本次使用Docker Desktop來建立。
- 其他部署平臺
1. 環境與準備條件
- Windows 電腦已安裝 Docker Desktop
- 已擁有自己的網域且 DNS 交由 Cloudflare 管理(或可自行將 DNS 指向 Cloudflare)
- 了解 Cloudflare Tunnel 基本概念
2. 用 Docker 安裝 n8n
確認 Docker Desktop 已安裝啟動
Gemini Balance 部署體驗:從零開始的AI代理服務搭建心得

前言
在探索AI服務部署的過程中,我發現了一個非常實用的項目 - Gemini Balance。這是一個專為 Gemini API 設計的輪詢代理服務,能夠實現負載均衡、API密鑰管理和使用監控等功能。本文將分享我從零開始部署這個服務的完整體驗和心得。
什麼是 Gemini Balance?
Gemini Balance 是一個開源的 Gemini API 代理服務,主要特色包括:
- 🔄 負載均衡:支援多個 API 密鑰輪詢使用
- 📊 使用監控:提供詳細的 API 使用統計和監控面板
- 🔐 訪問控制:支援自定義訪問令牌管理
- 💾 數據持久化:支援 SQLite 和其他數據庫存儲
- 🌐 易於部署:支援多種部署平台
技術架構分析
核心組件
Gemini Balance 的技術架構包含以下核心組件:
MCP 客戶端建置與設定教學

我們將說明如何建置與設定 MCP 客戶端,特別聚焦於 RooCode 工具與本地模型的整合,以及實際的應用。
1. 安裝與設定 Roo code
roo code 是一款支援本地 AI 助手的 VS Code 擴充套件。安裝步驟如下:
- 前往 Visual Studio Marketplace 或Extensions 搜尋「Roo code」並點擊安裝。

- 安裝後,Roo code 圖示會出現在 VS Code 側邊欄。
2. 本地模型支援
Roo code 支援多種本地模型,包括 Ollama、LM Studio 等。這些工具可讓你在本地運行大型語言模型(LLM),並與 MCP 協議整合。
Hugging Face Spaces 部署指南

前言
當你嘗試按照官方指引部署 Hugging Face Spaces 時:
git init
git add app.py requirements.txt
git commit -m "Initial commit"
git remote add origin https://huggingface.co/spaces/YOUR_USERNAME/mcp-sentiment
git push -u origin main
你可能會遇到各種錯誤。本指南將帶你逐步解決這些問題,並成功部署到 Hugging Face Spaces。
為什麼原始指令無法運作?
自 2023 年 10 月 1 日起,Hugging Face 停止支援密碼身分驗證,因此當你使用 HTTPS URL 推送時,會收到以下錯誤訊息:
使用 Gradio MCP 建立伺服器,并部署在Hugging Face Space

Gradio MCP 整合介紹
Gradio 透過自動將您的 Python 函數轉換為 MCP 工具,提供了一種簡單的方式來創建 MCP 伺服器。當您在 launch() 中設置 mcp_server=True 時,Gradio 會:
- 自動將您的函數轉換為 MCP 工具
- 將輸入元件映射到工具參數架構
- 從輸出元件確定回應格式
- 設置 JSON-RPC over HTTP+SSE 進行客戶端-伺服器通訊
- 創建網頁介面和 MCP 伺服器端點
專案設置
首先,讓我們為專案創建一個新目錄並設置所需的依賴項:
# Windows
mkdir mcp-sentiment
cd mcp-sentiment
python -m venv venv
source venv/bin/activate
pip install "gradio[mcp]" textblob
創建伺服器
Hugging Face Spaces 需要一個 app.py 檔案來建立 space,所以 Python 檔案的名稱必須是 app.py 創建一個名為 app.py 的新檔案,包含以下程式碼:
