What the IMX410’s binning actually doesIMX410 的像素合併到底做了什麼

Why these two modes為什麼是這兩個模式

The sensor has about 24 million light-collecting cells. A video frame needs two to eight million, so cells have to be turned into fewer numbers before anything reaches the card. Most modes do part of that on the sensor and part in a resizing circuit afterwards. OG3K and OG2K are the only two that go through the sensor and nothing else — which makes them the only clean look at what the IMX410 itself does.感光元件上大約有 2400 萬個收光的小格子。一張影片畫面只需要兩百到八百萬個,所以在寫進卡之前,一定要把很多格子變成比較少的數字。大部分模式是感光元件做一半、後面的縮圖電路做一半。OG3K 和 OG2K 是唯二只經過感光元件、後面什麼都沒有的模式 —— 所以它們是唯一能乾淨看到 IMX410 本身在做什麼的窗口。

Up and down: it really does combine rows上下:它真的在合併列

In the ÷2 mode two rows of the same colour are combined into one, half and half, exactly as you would hope. Nothing is weighted more than the other, and nothing is skipped.在 ÷2 模式下,兩條同色列被合成一條,各佔一半,和你期望的完全一樣。沒有哪一條權重比較高,也沒有跳過任何一條。

The proof is in the spacing. If rows are genuinely merged in pairs, the rows that come out are not evenly spaced — each output row sits at the middle of its own pair, so the gaps go long, short, long, short. That is measurable inside a single frame, without any reference image: the two green channels of the Bayer pattern should sit exactly half a pixel apart, and in OG3K they sit a quarter apart instead. No resizing circuit produces that. It is what row merging looks like from the outside.證據在間距上。如果列真的是成對合併的,出來的列間距就不會均勻 —— 每一條輸出列落在自己那一對的中間,所以間隔會長、短、長、短。這件事在一張畫面裡就量得出來,不需要參考圖:拜耳圖案的兩個綠色通道本來應該正好差半個像素,而 OG3K 裡它們只差四分之一。任何縮圖電路都做不出這個。這就是列合併從外面看起來的樣子。

The ÷3 mode only combines two rows, and bins the third÷3 模式只合併兩列,第三列丟掉

The menu calls M139 a 3×3. It is not. Vertically it still combines only two rows of every three, and the third is simply not used. A third of the light that landed on the sensor never reaches the file, and the detail that was on that row is gone.選單把 M139 寫成 3×3。它不是。垂直方向它還是只合併每三列裡的兩列,第三列根本沒有用到。打在感光元件上的光有三分之一沒有進到檔案裡,那一列上的細節也就沒了。

This is not guesswork from the pixels. The firmware carries a four-number tag for every mode, and for the eight ÷3 modes it reads (3,2,3,3). The first two numbers are the tap counts per axis, and that lone 2 is the vertical one. The pixels and the camera’s own ROM table say the same thing.這不是從像素上猜的。韌體為每個模式帶了一組四個數字的標籤,八個 ÷3 模式上寫的是 (3,2,3,3)。前兩個數字是每個方向的抽頭數,那個孤零零的 2 就是垂直方向。像素和相機自己的 ROM 表說的是同一件事。

The third row is skipped by configuration, not by nature. It was worth checking whether the sensor could be told to collect all three, and it can: two registers hold the vertical tap count and one widens the row window, and with those three changed OG2K merges three rows instead of two. Noise falls 10–15%. The catch is that widening the window also slides the odd colour rows a third of a row out of step with the even ones — a shift a raw converter can take out, but the camera cannot. Whether the softer vertical is a good trade for the cleaner noise is still an open question. The measurements are on the technical page.第三列是被設定跳過的,不是天生如此。 值得試試看能不能叫感測器把三列都收進來,答案是可以:兩個暫存器存垂直抽頭數, 另一個把列視窗放寬,改掉這三個之後 OG2K 就從併兩列變成併三列,雜訊降 10–15%。 代價是放寬視窗會讓奇數顏色列相對偶數列錯開三分之一列 —— 這個位移 raw 轉檔可以修掉, 相機自己不行。垂直變柔換到比較乾淨的雜訊,划不划算目前還沒有定論。 量測在技術頁那一節。

Left and right: nothing is combined — it is calculated左右:根本沒有合併 —— 是算出來的

Sideways, no cells are merged. The camera picks a position between two neighbouring cells and works out how bright it would probably be, by mixing the two in some proportion — like mixing two paints to get a shade in between. Nothing is collected twice. A new number is invented from the numbers next door.橫的方向,沒有任何格子被合併。相機挑一個落在兩個相鄰格子中間的位置,再按比例把那兩格混起來,算出它「大概應該多亮」—— 就像把兩種顏料調出中間色。沒有東西被多收一次,只是從旁邊的數字生出一個新數字。

The giveaway is that the mixing proportions are unequal, and they flip between even and odd output columns — roughly 27:73, then 73:27. Combining charge cannot do that. Resampling onto an evenly spaced grid does exactly that.看出來的地方在於混合的比例是不相等的,而且在偶數行和奇數行之間對調 —— 大約 27:73,然後 73:27。電荷合併做不出這件事,而「重新取樣到一個均勻的網格上」正好就會這樣。

It averages, it does not sum — so you get no free stop它是平均,不是相加 —— 所以沒有白送的一級

People expect binning to gather light: merge four cells and the one you keep has four cells’ worth. That is not what comes out. Whatever gets combined is divided back down afterwards.一般人期望合併會收光:四格併成一格,留下的那格就有四格份的光。出來的結果不是這樣。不管合併了什麼,後面都會除回去。

How you can tell: ÷3 is not brighter than ÷2. At the same ISO and shutter the two sit at the same level — 127.1 against 124.8. If charge were really being added up, ÷3 would be more than twice as bright. Every video mode also sits 1.32 EV below the 6K still at identical settings, and the DNG files say so themselves in their exposure tag.怎麼看出來的:÷3 並沒有比 ÷2 亮。同樣的 ISO 和快門下,兩者亮度一樣 —— 127.1 對 124.8。如果電荷真的被加起來,÷3 應該要亮兩倍以上。而且在完全相同的設定下,每個影片模式都比 6K 靜態暗 1.32 EV,DNG 檔自己的曝光標籤也是這麼寫的。

What this test cannot tell you is whether the dividing happens before or after the read. “Add the charge, then halve it” and “read both rows, then average” give the same brightness and the same noise in daylight, and differ only in the dark. That one is still open.但這個測試分不出來的是除法發生在讀出之前還是之後。「電荷相加再除以二」和「兩列都讀出來再平均」在白天會給出一樣的亮度和一樣的雜訊,只在暗部才不同。這一點還沒解。

What it costs代價是什麼

Because the mixing weights are uneven, an output pixel does not average as many cells as the name suggests. Count them properly and a “2×2” averages 3.2 cells, not 4. A “3×3” averages 5.33, not 9 — that is the discarded row showing up as a number.因為混合的權重不均勻,一個輸出像素平均到的格子數並沒有名字說的那麼多。認真數的話,「2×2」平均了 3.2 個格子,不是 4;「3×3」平均了 5.33 個,不是 9 —— 被丟掉的那一列就體現在這個數字上。

The noise side is the good news and it is small. The real cost is elsewhere: a reduction that skips rows cannot represent fine repeating detail, and what it cannot represent does not vanish politely — it comes back as a coarser pattern that was never in front of the lens. On a dense fabric weave, ÷3 goes wrong about six times as often as ÷2.雜訊這一側是好消息,而且差距不大。真正的代價在別處:一個會跳列的縮減方式沒辦法表現細密的重複花紋,而它表現不了的東西不會乖乖消失 —— 會變成一個鏡頭前根本沒有的、比較粗的圖案回到畫面上。在密織的布料上,÷3 出錯的程度大約是 ÷2 的六倍。

Lower is better; the numbers are how much of the picture came out as something that was not there. ÷2 is close to the best a two-row merge could possibly do. ÷3 is nowhere near, and the gap is the thrown-away row.數字越小越好,它代表畫面裡有多少東西變成了原本不存在的樣子。÷2 已經接近「兩列合併」能做到的極限;÷3 差得遠,差的那一段就是被丟掉的那一列。

Which mode to actually use實際該用哪個模式

M117 is not the quiet one. It used to be written up that way here, from two folders whose names had been swapped. Measured properly it reads 1.205 against M98’s 0.904 — it buys 26% off the rolling shutter and nothing else. When a measurement contradicts the person who was there, check the labels before trusting the measurement.M117 不是比較安靜的那個。這裡以前是那樣寫的,來源是兩個名字被對調的資料夾。正確量出來是 1.205 對 M98 的 0.904 —— 它換到的只有 26% 的捲簾改善,沒有別的。當量測和在場的人矛盾時,先檢查標籤,再相信量測。

If you are developing the RAW如果你要自己解 RAW

OG3K’s rows are not evenly spaced, for the reason in the second section. Most demosaic code assumes they are, and on a diagonal edge that shows up as a faint stair-step. Resampling the frame to an even row grid first, before demosaicing, removes it.OG3K 的列間距不是均勻的,原因在第二節。大部分去馬賽克的程式都假設它是均勻的,結果在斜邊上會出現淡淡的階梯。先把畫面重新取樣到均勻的列間距,再去馬賽克,就不會有。

On OG2K, a chroma median pass helps more than changing algorithm. Its false colour comes from the discarded row, not from the demosaic, so a better demosaic cannot fix it — but cleaning up the colour after the fact can.OG2K 上,色度中值濾波比換演算法有用。它的偽色來自被丟掉的那一列,不是來自去馬賽克,所以換更好的演算法救不了 —— 但事後把顏色清一清可以。

Where this comes from這些是怎麼來的

Every number on this page is fitted from seven stills shot and released by Jose: one frame per mode of the same scene, ISO 400, 1/25 s, f/3.5, 25p, Ver.5.02 with fpSup, camera serial zeroed and the image data left byte-identical. Nothing else went into the kernels.這一頁上每一個數字,都是從 Jose 拍攝並公開的七張靜態照片擬合出來的:一個模式一張,同場景,ISO 400、1/25 秒、f/3.5、25p,Ver.5.02 搭 fpSup,相機序號歸零、影像資料保持逐位元相同。核裡沒有放進別的東西。

Three separate methods had to agree before anything here was written down: fitting the weights directly, checking them against how noise grows with brightness, and measuring the row spacing inside a single frame. Where they disagreed, the page says so.這裡每寫下一件事之前,三種獨立的量法都必須對上:直接擬合權重、用「雜訊如何隨亮度增長」交叉檢查、以及在單張畫面裡量列間距。有對不上的地方,頁面上都寫了。

Still open: whether the dividing happens before or after the read, and whether a true three-row merge is configurable at all — nothing in the decoded register set separates two rows from three, so it may simply not be.還沒解:除法發生在讀出之前還是之後,以及真正的三列合併到底能不能設定 —— 已解碼的暫存器裡沒有任何一個把兩列和三列分開,所以有可能它根本不可設定。

The stage that comes after the sensor — the resizing circuit every other mode goes through — is a separate page: What the RWZM resizer does. The full technical version of both, with every table, is here.感光元件後面那一關 —— 其他模式都會經過的縮圖電路 —— 在另一頁:RWZM 縮圖電路做了什麼。兩者的完整技術版、所有表格,在這裡。