Ideogram Precise Edit 局部修圖，大圖只重算選定的那一塊

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

一張 4,016×6,016 的商品照，客戶只要求把包包改成酒紅色。這種需求在電商攝影裡天天出現，難的從來不是改色，是讓整張圖超過兩千四百萬個像素裡沒被點名的部分原地不動。把整張圖交給生成模型重畫，顏色對了、背景的紋理卻可能微妙地變了；先裁出局部改完再拼回去，交界處又容易留下色差與邊框。Ideogram 的 Precise Edit 這次要處理的正是這一段。

官方功能頁把這項能力叫「Precise Edit with context window」，主打可以在最高 8K 的圖上做局部編輯，不必再縮圖、也不必把裁切結果拼回原圖；API 文件則給了它精確得多的形貌：一個叫 context_window 的參數、三種模式，配上幾組寫死的數字。要把大圖交出去之前，值得先弄懂三個問題：回傳的圖還會是原尺寸嗎？遮罩（mask）和 context window 是同一件事嗎？官方說的「最高 8K」到底指哪一個數字？

三個答案都寫在官方 API 文件裡，而且多數是 2026 年 10 月下旬才補上的：預設模式會把超過 4,194,304 像素的圖縮小；遮罩標示要改哪裡、context window 決定模型處理時看見多大範圍，兩件事分開設定；8K 指的是輸入上限，單一處理範圍的面積上限其實是 2048×2048 這個等級。

大圖直接送進 API，回來的會是縮小版

Precise Edit 的 API 端點（POST /v2/image/precise-edit/ideogram-4-5）預設走全圖模式，參數 context_window 不設就是 none。文件對這個預設行為寫得毫不模糊：整張圖的處理上限是 4,194,304 像素，正好是 2048×2048 的面積；更大的圖會縮小到符合上限再處理，文件給的例子是 8192×8192 進、2048×2048 出。

這個數字是面積上限，不能讀成單邊上限。4,016×6,016 的商品照約 2,420 萬像素，是上限的五倍多，走預設模式的結果就是整張縮小。文件只給了 8192 那一個換算例子，沒有各種尺寸的對照表，所以「4,016×6,016 會被縮成多少」沒有官方答案，也不該靠自己推算，只能看回圖尺寸。

換個角度看這個門檻：2048×2048 的面積上限，意味著 3000×3000 這種還稱不上大的圖就已經超標，會被縮小處理。真正能在全圖模式下原樣過關的，只有 2K 等級以下的圖；從手機直出到相機原檔，多數素材其實都落在會被縮小的那一側。這也解釋了官方行銷為什麼直接拿 4K、8K 當對比組。

縮小的代價也不只解析度。官方功能頁用一組對照示範說明：同一張 4K 原圖，不設 context window 時被縮成 2K 處理，織標字母的修復結果放大看就糊了一級；設了 context window 只處理選定範圍，整張圖保住原始 4K。這是官方自己提供的示範，用意正是把兩條處理路徑的差別擺在同一張圖上。

換句話說，context window 存在的理由就寫在預設值的行為裡：想保住大圖，就得把「要改的範圍」從整張圖切出來，讓模型只在那一塊動工，範圍外的像素按文件說法是逐像素原樣複製，輸出在任何輸入尺寸下都保持原圖的寬高。

遮罩標示要改哪裡，處理範圍決定模型看見什麼

很多修圖工具都有遮罩，Precise Edit 的文件特別把遮罩和 context window 拆成兩個控制項，因為它們回答兩個不同的問題。遮罩回答「哪些像素要改」：黑色標示要修改的區域、白色標示保留區，介於兩者之間的灰階值會被歸到黑白其中一邊；遮罩必須跟原圖同尺寸，而且必須同時包含黑色與白色區域。要留意這個黑白定義跟部分修圖軟體的習慣相反，帶著舊習慣過來會做出完全相反的事。

context_window 回答的是「模型處理時看見多大範圍」。auto 模式必須搭配遮罩，系統會在遮罩周圍自動框出一個處理範圍；手動模式直接給四個數字 y_min,x_min,y_max,x_max（y 在前、x 在後，原點在圖片左上角，最大邊界本身不算進範圍），換算下來範圍寬是 x_max 減 x_min、高是 y_max 減 y_min。文件給的例子是 512,1024,2048,3072：一個 2048 像素寬、1536 像素高的範圍，左上角落在向右 1024、向下 512 的位置。

手動範圍有四條硬限制：必須完全落在圖片內、每側至少 256 像素、長寬比要在 1:6 到 6:1 之間、面積不超過 4,194,304 像素。1:6 這條值得記住：想沿著一根細長的欄杆或吊帶拉一條窄長條，比例超過就過不了這關。

auto 跟手動座標的取捨，取決於工作型態。單張作業、手上已經有遮罩，讓 auto 自己框最省事；要進管線、要可重現、要留下「當初改的是哪一塊」的紀錄，手動座標把範圍寫死在請求裡，任何人重播同一組參數都會得到同一個範圍。兩種模式也都能跟遮罩並用，文件唯一的條件是遮罩選取的像素不能落到範圍外。

批次流程最該記下的，是 auto 模式的一個安靜行為：如果遮罩本身選取的範圍超過 4,194,304 像素，沒有任何局部範圍裝得下它，請求不會失敗，而是退回全圖模式、整張縮小處理。對單張作業的人，這只是結果不如預期；對一次跑幾百張的管線，這是不檢查回圖尺寸就會混進交付物的縮圖。

Pin

「最高 8K」指輸入上限，單一範圍上限是 2K 等級

官方功能頁標語寫「images up to 8K」，對應的是 API 文件裡輸入圖的兩個上限：檔案最大 50MB、像素總數最大 67,108,864，文件還特地註明 8192×8192 剛好滿足這個數字。8K 只描述輸入上限；處理範圍與輸出各有各的口徑。

單一處理範圍的面積上限是另一個數字：4,194,304 像素，等於 2048×2048。官方功能頁自己也寫「You can edit any area up to 2K at its original pixels」，任何一塊範圍要以原始像素處理，就是 2K 這個等級的大小。三個數字合起來才是完整圖像：8K 等級的圖進得來，2K 等級的範圍改得動，輸出保持原圖尺寸。

Pin

範圍內要改成什麼樣子，還可以靠參考圖引導：reference_images 最多四張、每張最大 50MB，它們只提供參考、本身永遠不會被修改，被動到的只有 image 那一張；帶遮罩的請求因為遮罩佔掉一個名額，參考圖最多帶三張。官方示範裡換球鞋與修標籤的案例，都是原圖加一張參考圖的組合。而宣傳影片裡那個 6,600 萬像素的場景，換算一下也確實在 67,108,864 像素的輸入上限內，行銷文案裡的這個數字是真實送得進 API 的尺寸。

官方示範裡最能說明比例的是包包換色案例：來源圖 4,016×6,016（標示 24.2 MP），處理範圍只有 1,024×1,024（約 105 萬像素），座標 2538,2038,3562,3062，回圖尺寸與來源相同。整張圖的像素裡，真正交給模型重算的大約是二十三分之一，其餘按文件的說法逐像素複製。這張示範的來源照片標示為 Christopher Macsurak 的 CC BY 2.0 授權作品，提示詞也整句附在案例裡：把淡藍色手提包改成酒紅色、保留皮革紋理與光線。

功能頁另有一支宣傳影片，內容是在 6,600 萬像素的客廳場景裡標出壁爐上方一扇「窗」，以原始像素編輯再放回，接著依序處理樓梯、沙發、戒指與電車旁的車輛。這些都是官方提供的展示，另外多個示範案例的來源圖自述由 Nano Banana Pro 生成，官方在案例標示裡逐一註明。示範能說明用途與流程，取代不了對自己素材的驗證。

這些數字是十月下旬才走進文件的

context_window 這個參數本身並不新。網際網路檔案館保存的 API 文件快照顯示，10 月 16 日的版本裡三種模式、256 像素下限與 1:6 長寬比限制都已經存在，只是當時對全圖模式的描述只有一句含糊的「大圖回傳時可能變小」。10 月 21 日的快照仍然如此。

改動也不只發生在 context_window 一個欄位。10 月 16 日快照裡，輸入圖的限制只有檔案 50MB 一條，67,108,864 像素的上限是 10 月 21 日之後才補上的。補上之後，文件的邊界與行銷頁的 8K 口號才對得起來：67,108,864 像素剛好等於 8192×8192，行銷標語裡的 up to 8K 在文件裡有了對應的硬數字。

到 10 月 30 日造訪時，文件已經補齊全部明確數字：4,194,304 像素的全圖上限與 8192×8192 縮成 2048×2048 的例子、輸入圖 67,108,864 像素上限、auto 模式遮罩超限時退回全圖的規則，還有簡介裡「要編輯 4K 或 8K 圖片的完整解析度，就設定 context_window」的直白說法。可以查證的事件是「文件在 10 月 21 日之後的某一天把行為講清楚了」，而非「功能在那一天上線」；功能頁與文件都沒有標任何發布日期，把查核日期當成上市日期寫，是二手轉述裡常見的錯。

這個區別有實際意義。文件補上明確數字，代表官方願意把這些行為當成承諾寫下來，接 API 的人可以據此設計流程；但「文件何時寫明」與「服務何時開始這樣運作」是兩件事，文件回答不了後者。修訂速度本身也是提醒：這份文件在 10 月 21 日到 30 日之間確定改版過一次，引用它任何數字之前，先回官方頁面核對一遍。

帳單看品質檔位，跟圖多大無關

計費規則是這份文件裡最乾脆的一段：唯一影響價格的欄位是 quality。very_low 最快最便宜、high 較慢較貴、預設值是 medium；送進來的圖多大、context_window 設成什麼，都不改變價格。對 8K 圖的局部修改來說，成本評估只需要看品質檔位，不必為了省錢先把大圖縮小再送。

想在花錢前知道一筆請求的價格，文件提供了 dry_run 參數：設為 true 時只做驗證與試算，不生成、不儲存、不計費，回傳一個價格報價物件。把它當批次流程的前置檢查很自然：先用預計的設定試算一輪，確認單價與參數合法，再放行真正的生成。量大時另有非同步模式與 webhook 交付可選，結果送達以 Ed25519 簽章驗證。

要反覆嘗試同一張圖時，seed 參數可以固定隨機種子、讓相同設定重現；需要版權偵測的場景也有開關，但文件註明會增加延遲，被標記的圖會以 is_image_safe: false 回傳。

官方沒說的三件事，動手前先補齊

文件加功能頁，仍有三件事沒有答案。context_window 的確切上線日期，官方頁面從未標示。網頁版 Precise Edit 的介面是否提供手動輸入座標的控制項，功能頁只展示「送出遮罩與處理範圍」的案例標示，實際介面要登入才能確認。API 單張價格的金額，文件只寫計費規則，實際數字要進開發者後台才看得到。

輸出品質是另一條要自己驗的軸。文件承諾的是範圍外像素逐像素複製、輸出保持原尺寸；「無接縫、無色差」則是功能頁的行銷用語，兩者證據等級不同。顏色尤其如此：生成出來的酒紅色與實物的酒紅色中間隔著螢幕、材質與打光，要用在商品頁之前，對照實物參考資料這一步省不掉。

放進工具箱裡看，它解決的是「重算範圍」的問題：SurgePix 把 AI 生成圖拆成可編輯圖層、改字不必重做整張圖，是同一個方向的不同做法；已經縮過的舊圖想救解析度，那是 Clarity Upscaler 這類 AI 圖片放大工具的領域，兩者不互相替代；只是換個顏色、去掉小物件的輕量需求，也可以先試 Edit0 這種一句話改圖工具，再決定要不要為了局部精度去申請 Ideogram 的 API 金鑰。

動手順序照文件的設計走最穩：先算目標範圍的面積與長寬比，確認每側至少 256 像素、落在 1:6 到 6:1 之間；用 dry_run 試算價格與參數；生成後核對回圖尺寸是否與原圖相同，這一步能當場抓出 auto 模式退回全圖縮小的情況。原圖、遮罩、範圍座標與提示詞留檔，結果不如預期時才知道該調哪一項。