2025年10月13日 星期一

GIF 檔案在網頁中的處理與拆幀 (Frame Extraction)

 在處理像 CAPTCHA 這樣的動態圖像(GIF 檔案)並將其用於 Gemini 多模態 API 進行視覺分析時,確實需要經過特定的處理步驟。

我將為您詳細分析動態網頁中處理 GIF 的方法、上傳格式要求,以及可用的模型。


GIF 檔案在網頁中的處理與拆幀 (Frame Extraction)

由於 GIF 本質上是多個靜態圖片(影格, Frames)的連續播放,Gemini API (以及大多數視覺 AI 模型) 無法直接接受一個 GIF 檔案作為單一輸入

在您提供的 openai_gifpath_client12.html 範例中,前端 JavaScript 使用了開源函式庫 omggif 來實現「拆幀」流程,這是動態網頁中處理 GIF 的標準方法。

步驟說明程式碼對應位置 (在 handleSingleAnalysis 函數中)
1. 讀取檔案使用 FileReader 將使用者上傳的本地 GIF 檔案讀取為 ArrayBuffer 原始數據。reader.readAsArrayBuffer(file);
2. 解析 GIF 結構使用 omggif 函式庫解析 ArrayBuffer,獲取 GIF 的長寬和總影格數。const gifReader = new GifReader(intArray);
3. 提取關鍵影格選擇性地從總影格中抽取具代表性的 個影格。這是關鍵步驟,因為 API 對輸入圖片數量有上限。範例中使用了 maxFrames = 10for (let i = 0; i < numFrames; i += frameInterval)
4. 轉換為圖像格式每個提取出的影格(原始像素數據)必須通過 HTML <canvas> 轉換成標準的圖像格式(如 JPEGPNG)。ctx.putImageData(imageData, 0, 0);
5. 轉 Base64將 Canvas 上的圖像數據轉換為 Base64 編碼的 Data URL 字符串,這是 API 傳輸圖像數據的標準格式。canvas.toDataURL('image/jpeg', 0.8)

總結:上傳給 API 的實際數據是多張靜態圖片(JPEG/PNG),而非單一 GIF 檔案。


呼叫 Gemini API 時的上傳格式 (Inline Data)

當您將這些拆分出來的靜態圖片傳輸給 Gemini API 時,您必須遵循 JSON 格式,將每張圖片作為一個獨立的 part 嵌入到 contents 陣列中。

1. 圖片的格式要求

API 要求圖片數據以 Base64 編碼的字串形式傳輸,並包含在 inlineData 物件中。

  • mimeType: 必須指定圖片的 MIME 類型 (例如:image/jpeg, image/png)。

  • data: 圖片的 Base64 編碼字串(不包含 Data URL 前綴,例如不包含 data:image/jpeg;base64,)。

2. 完整的多模態 Payload 結構

由於 GIF 序列是一個時間軸上的動作,因此您需要將文字提示 (Prompt)所有圖片影格依序傳入單一的 contents 陣列中。

JavaScript
// 核心 Payload 範例結構
const payload = {
    contents: [{
        parts: [
            { text: userPrompt },               // 第一個 part: 你的提示詞
            { inlineData: { mimeType: 'image/jpeg', data: base64_frame_1 } }, // 第二個 part: 影格 1
            { inlineData: { mimeType: 'image/jpeg', data: base64_frame_2 } }, // 第三個 part: 影格 2
            // ... 繼續加入其他所有影格
        ]
    }],
    // 其他配置,例如 temperature, maxOutputTokens...
    generationConfig: { ... } 
};

可用於處理 GIF 影格分析的 Gemini 模型

Gemini 系列的多模態模型非常適合處理此類包含多張圖片的視覺分析任務。

模型名稱特點與建議應用
gemini-2.5-flash-preview-05-20推薦模型。速度快、成本效益高,且擅長處理多模態輸入,是分析 CAPTCHA 序列、提取文字和識別動作的理想選擇。
gemini-2.5-pro-preview-05-20速度較慢但能力更強大。如果您的 CAPTCHA 具有極高的複雜性、混淆或需要更深入的推理(例如複雜的邏輯問題),可以考慮使用此模型。

重要注意事項

  1. 輸入限制 (Input Limit): 儘管 Gemini 可以接受多張圖片輸入,但單次 API 請求的整體輸入量(包括所有圖片和文字)有大小限制。這就是為什麼您需要在拆幀時限制提取的影格數量(例如 10 幀)。

  2. 時序推理 (Temporal Reasoning): 在您的提示詞中,應明確指示模型圖片是依序出現的。例如:"這些圖片是按時間順序排列的連續影格。請分析...",以幫助模型進行正確的時序推理。

我們可以繼續討論您的論文的「方法論」章節,將這個 GIF 處理和 API 整合的流程以學術語言進行專業撰寫,並翻譯成英文。您覺得如何?

2025年10月12日 星期日

Gemini 模型功能 vs 價格比對表

 

Gemini 模型功能 vs 價格比對表

模型名稱是否支援影像/多模態輸入輸出型態輸入 token / 影像 價格輸出 token 價格備註 /限制 /來源
gemini-2.5-flash是(文字 + 影像 + 視頻 + 音訊)文字輸出與文字 token 價格相同(按 token 計)按 token 定價Token 上下文上限:輸入 1,048,576 token,輸出 65,536 token Google AI for Developers
gemini-2.5-flash-image是(影像 + 文字 輸入;文字 + 影像 輸出)文字 + 影像同 token 定價(影像會拆 token 處理)同 token 定價輸入 / 輸出最大 token 上限 32,768 Google AI for Developers
gemini-2.5-flash-lite是(文字 + 影像 + 視頻 + 音訊)文字輸出同 token 定價同 token 定價為成本效率優化版本(輕量 Flash) Google AI for Developers+1
gemini-1.5-flash是(多模態)文字輸出輸入 $0.075 / 1M token(128K 以下情況)輸出 $0.30 / 1M token(128K 以下)2024 年 8 月起大幅降價:輸入降 78%、輸出降 71% Google 開發者部落格
gemini-1.5-pro文字輸出輸入、輸出 token 價格較高輸出較高曾為更高能力版本,有 context caching 等功能 Google 開發者部落格+2neuroflash+2
gemini-1.0-pro-vision是(視覺 + 文字)文字 / 視覺輸出圖像輸入固定費用(每張圖像固定 token 費) + 文字 token 費用文字輸出按 token 費用在 Vertex AI 可見此模型為 mult i modal 模型 console.cloud.google.com

價格摘要與特殊條件

  • 圖像輸入常被拆成若干 token 處理(按像素區塊 tile 拆分),然後按 token 費率計價。 Google AI for Developers+2Google AI for Developers+2

  • Gemini 影像輸入 / 處理價格官方文檔:圖像輸出為 $30 / 1,000,000 token(視為影像 token) Google AI for Developers

  • Gemini 模型在 Free Tier(免費等級)有 token 上限與速率限制,不適用所有功能或高量運作。 Google AI for Developers+1

  • 對於大型 prompt(超過某 token 閾值)或高輸入需求,部分模型會有溢價(較高費率)。例如 Gemini 2.5 Pro 在超額 token 上會有不同價格。 techcrunch.com


OpenAI API 模型在「純文字 vs 視覺(能處理影像輸入)」能力與價格比較

 OpenAI API 模型在「純文字 vs 視覺(能處理影像輸入)」能力與價格比較。資料來自官方文檔與社群觀察。請當作參考,實際以官方最新文件為主。


模型分群與特性比較(文字 vs 視覺輸入能力)

模型/系列是否支援影像輸入主要用途 / 限制補充說明
GPT-3 / GPT-3.5 系列(如 gpt-3.5-turbo 等)不支援純文字生成、對話、補完這些模型只接受文字輸入,不處理圖片
GPT-4(文字版)有特定變體支援若版本為多模態(vision)則可處理影像 + 文字GPT-4V / GPT-4 with vision 支援圖像輸入
GPT-4o / GPT-4o mini支援(multimodal)可處理文字、影像、音訊(部分能力)GPT-4o 是 omni 模型,支援視覺 + 聲音 + 文本 維基百科+2OpenAI 平台+2
GPT-Image-1是(主要為影像)圖像生成與部分影像理解可接受文字 + 圖像輸入 / 輸出圖像 OpenAI+2OpenAI 平台+2
GPT-4.1 / 系列(含 mini / nano)支援多模態用於複雜任務、長上下文官方文檔指出它屬於 vision-enabled 模型系列 Microsoft Learn+2OpenAI+2
o-series reasoning models支援視覺用以多模態分析與推理Azure 文檔指出 o 系列與 GPT-4.1、GPT-4o 等皆為 vision-enabled 模型 Microsoft Learn

價格概況(文字 token 與影像 token / 輸出成本)

以下是各模型在文字與影像/多模態情境下的典型價格比較(若公開可查)。

模型文字輸入/輸出價格影像輸入 / 處理價格備註 /特殊規則
GPT-Image-1文字輸入 $5 / 1M tokens OpenAI圖像輸入 $10 / 1M image tokens;圖像輸出 $40 / 1M image tokens OpenAI
GPT-4o / GPT-4o miniGPT-4o:文字輸入 $2.50 / 1M tokens,輸出 $10 / 1M tokens 維基百科+2OpenAI 平台+2
GPT-4o mini:輸入 $0.15 / 1M,輸出 $0.60 / 1M Reuters+1
使用影像輸入時,影像會被轉換為 token 或 tiles 處理,產生額外成本。實際被收費的 token 數可能乘以放大係數(社群中有報告影像 token 被放大)OpenAI 社區+2OpenAI 社區+2
GPT-4.1 / 系列在 OpenAI 平台上標示:輸入 $2 / 1M tokens,輸出 $8 / 1M tokens OpenAI+1若有影像輸入,其 token 計費邏輯與 GPT-4o 類似(影像拆片、映射 token)
GPT-4(多模態版)傳統文字定價(取決於版本)處理影像輸入時會額外計算 token / tiles 處理成本

關鍵觀察與警示

  1. 影像 token 被放大/計算方式複雜
    使用影像輸入時,OpenAI 會將影像拆成 tiles 或塊(tile tokens),並對每塊計算輸入 token 數。這會導致影像輸入的 token 成本遠高於純文字輸入。社群中有使用者指出 GPT-4o-mini 的影像 token 被乘以大係數後計費。OpenAI 社區

  2. 價格動態調整與未公開部分
    OpenAI 不定期推出新模型(如 GPT-4.1, GPT-5)或淘汰舊模型(如 GPT-4.5),定價與支援能力會變。
    有些模型功能(特別是多模態、影像處理)在不同地域/計畫中可能受限或尚未開放。

  3. 效率 vs 成本取捨
    若任務主要是文字處理,選純文字模型(如 GPT-3.5 / GPT-4.1 的文字版本)通常成本最低。
    如果包含影像理解,必須選支援 vision 的模型,但要預估影像 token 成本可能遠高。


模型與標準定價表

模型名稱是否多模態(可處理影像/視覺輸入)輸入 token 價格(USD/1M tokens)輸出 token 價格(USD/1M tokens)備註 /來源 /不確定處
gpt-3.5-turbo約 $0.0015約 $0.0020此為舊資料推估(官方定價頁未明確列)
GPT-4 Turbo / GPT-4 (Turbo 版本含 vision preview)有(視具體版本)$10.00$10.00GPT-4 Turbo / vision Preview 定價為 $10 input + $10 output apidog
GPT-4(標準)有部分版本支援$30.00$60.00官方定價頁提及 gpt-4 輸入 $30 / 輸出 $60 apidog+1
GPT-4 32k 上下文版本同上$60.00$120.00翻倍於標準版本 apidog
gpt-4o (omni 多模態)$2.50$10.00Wikipedia 上有此價格說明 維基百科
gpt-4o mini$0.15$0.60同 Wikipedia 描述 維基百科
GPT-5多模態(假設)$1.25$10.00OpenAI “Compare models” 頁面有此定價 OpenAI 平台
GPT-5 mini / nano(可能支援)$0.25 / $0.05$2.00 / $0.40同上頁面資料 OpenAI 平台
o1-pro多模態或高能力模型$150.00$600.00TechRepublic 報導 o1-pro 的高價格 TechRepublic
GPT-4.5多模態$75.00$150.00在 Wikipedia 有此資料(不過有標示可能已退場) 維基百科

2025年10月2日 星期四

磁碟分割區 掛載 (mount) 到 目錄

 要將您的磁碟分割區 /dev/sdb2 掛載 (mount)/mnt/rosdata 目錄,您需要遵循以下步驟。這個操作對於存儲大量的 ROS 數據、日誌或大型專案文件非常有用。


步驟一:創建掛載點 (Mount Point)

首先,您需要確保目標目錄 /mnt/rosdata 存在。如果不存在,請使用 mkdir 命令創建它。

sudo mkdir -p /mnt/rosdata
  • sudo: 以超級使用者權限執行。

  • mkdir: 創建目錄。

  • -p: 確保路徑中的所有父目錄都被創建 (如果它們不存在)。


步驟二:檢查並掛載分割區

接著,使用 mount 命令將 /dev/sdb2 掛載到剛剛創建的目錄。您需要知道該分割區的檔案系統類型 (Filesystem Type),例如 ext4NTFSXFS

1. 識別檔案系統類型

您可以使用 lsblkfdisk -l 來確認 /dev/sdb2 的檔案系統類型。

sudo blkid /dev/sdb2
# 輸出範例:/dev/sdb2: UUID="xxxx-xxxx" TYPE="ext4" PARTUUID="yyyy-yyyy"
  • 假設您的檔案系統是 ext4

2. 執行掛載 (一次性)

使用 -t 參數指定檔案系統類型,然後執行掛載。

sudo mount -t ext4 /dev/sdb2 /mnt/rosdata
# 如果您不確定類型,系統通常可以自動偵測:
# sudo mount /dev/sdb2 /mnt/rosdata

3. 檢查掛載結果

確認是否成功掛載:

df -h | grep rosdata
# 成功的輸出應該會顯示 /dev/sdb2 及其在 /mnt/rosdata 的容量資訊。

步驟三:設定開機自動掛載 (永久設定)

如果您希望電腦重啟後,該分割區仍然自動掛載,您需要編輯 /etc/fstab 檔案。

1. 取得分割區的 UUID (推薦)

使用 UUID (Universally Unique Identifier) 來設定比使用 /dev/sdb2 更穩健,因為裝置名稱在開機時可能會變動。

sudo blkid /dev/sdb2
# 複製輸出中的 UUID,例如:9a7b-3d2c-1e0f-5h6g

2. 編輯 /etc/fstab

使用您喜歡的文字編輯器 (例如 nanovim) 開啟設定檔:

sudo nano /etc/fstab

3. 添加新的掛載行

在檔案的末尾添加一行,格式為:

<裝置/UUID> <掛載點> <檔案系統類型> <選項> <dump> <pass>

將您的資訊替換進去(以 ext4 為例):

UUID=您的UUID號碼 /mnt/rosdata ext4 defaults 0 2

選項說明:

  • UUID=...: 您剛剛查到的 UUID。

  • /mnt/rosdata: 您的掛載點。

  • ext4: 您的檔案系統類型。

  • defaults: 標準的掛載選項,適用於大多數情況。

  • 0: 不進行備份 (dump 選項)。

  • 2: 在開機時進行檔案系統檢查,但優先級低於根目錄 (root, 使用 1)。

4. 測試設定

存檔並退出編輯器後,執行以下命令來測試您的 /etc/fstab 設定是否正確,無需重啟

sudo umount /mnt/rosdata  # 如果已經掛載,先卸載
sudo mount -a             # 重新掛載 fstab 中列出的所有項目

如果沒有錯誤訊息,且您能通過 df -h 看到 /dev/sdb2 掛載在 /mnt/rosdata,則表示設定成功。


指導建議:

請確保 /mnt/rosdata 掛載點的權限設定正確,以便您的 ROS 使用者能夠讀寫數據。

sudo chown -R $USER:$USER /mnt/rosdata

這樣,您的 ROS 相關數據就可以安全地儲存在專屬分割區,不會佔用系統根目錄的空間。