From sensor to CinemaDNG從感光元件到 CinemaDNG

Four independent choices feed the next stage: resolution name, frame rate, bit depth, and whether crop mode is on. Only the first two are obvious; the other two silently change which table gets searched.

有四個獨立的選擇會往下傳:解析度名稱、格率、位元深度,還有裁切開不開。前兩個很直覺,後兩個會默默決定下一關要查哪一張表 —— 這點很容易忽略,而且踩過坑。

The CINE menu's own resolution list lives at 0xC0B51044, 14 rows, and it only contains 4096×2160, 3840×2160 and 1920×1080. Anything else has to be added there as well as in the picker, which is why adding a resolution is a multi-table job rather than one edit.

CINE 選單自己的解析度清單在 0xC0B51044,14 列,裡面只有 4096×2160、3840×2160、1920×1080 三種。想加新解析度,選單這張表要加、下一關的 picker 表也要加 —— 所以「加一個解析度」從來不是改一個地方就好。

FUN_c043b828 builds a key by concatenating the resolution name, the frame rate name, and "CROP" if the crop flag is set. Then FUN_c043ccf8 walks a 26-entry table comparing 15 characters:

FUN_c043b828 把解析度名稱、格率名稱接成一個字串,裁切開著的話再接一個 "CROP"。然後 FUN_c043ccf8 拿這串去走一張 26 筆的表,逐筆比前 15 個字元:

key = "" ;  append resolution name   ("UHD" / "FHD")
            append frame rate        ("30" / "25" / "23_98" ...)
            if crop flag: strcat("CROP")

table = (eRawBitType == 4) ? 0xC0BE5810     // 8-bit
      : (eRawBitType == 3) ? 0xC0BE59B0     // 10-bit
      :                      0xC0BE5B50     // 12-bit

entry = lookup(table, key)
if (!entry) { log_error(); entry = 0xC0BE5B50; }   // table 3, row 0 = UHD30

The fallback caused a real bug

那個退路真的害我們出過包

That last line is not harmless. OG3K v0.2.1a registered its format in the 12-bit table only. Selecting 8-bit or 10-bit made the lookup miss, and the fallback silently handed back UHD30 — a working recording of entirely the wrong thing. A format has to be registered in all three tables or the other two have to be blocked.

最後那一行不是無害的。OG3K v0.2.1a 只把自己的格式註冊在 12-bit 那張表。使用者一選 8-bit 或 10-bit,查表就查不到,退路安靜地回傳 UHD30 —— 於是相機乖乖錄了一段完全不是你要的東西,而且看起來一切正常。
教訓:一個格式要嘛三張表都註冊,要嘛把另外兩個選項擋掉。

The three tables are the same formats at different bit depths, and their profile numbers differ systematically by 20:

三張表是同樣的格式、不同位元深度,而它們的 profile 編號系統性差 20:

+0x00   5             constant tag (5 = movie; the stills tables use 1)
+0x04   profile       index into the 306-row PARAM table
+0x08   sensor mode   index into the 70-entry mode table
+0x0C   key ptr       pointer to the lookup string

Because the name is a pointer, a new resolution name can live anywhere and be any length — "OG3K" needed no space negotiation. The resolution-name tables are separate, at 0xC0BE4508 / 4548 / 4588 for the three bit depths, four entries each of {6, id, 222, name_ptr}.

因為名字存的是指標而不是字串本體,新的解析度名字可以放在任何地方、要多長都行 —— 加 "OG3K" 的時候完全不用跟誰搶空間,這點幫了大忙。
解析度名字是另外三張表,0xC0BE4508 / 4548 / 4588 對應三種位元深度,每張四筆,格式是 {6, id, 222, name_ptr}。

For 12-bit CinemaDNG the resolution enums are UHD = 71, FHD = 73, UHDCROP = 391, FHDCROP = 393.

12-bit CinemaDNG 那張的解析度編號是 UHD = 71、FHD = 73、UHDCROP = 391、FHDCROP = 393。

0xC0B59DC0, 70 records of 0x64 bytes. This is the table the compression simulator drives from.

0xC0B59DC0,70 筆,每筆 0x64 bytes。壓縮模擬器的格式清單就是直接吃這張表。

+0x00  mode id        +0x04/+0x08  raster        +0x2C/+0x30  output crop
+0x34/+0x38  crop origin              +0x3C  bit-depth flag
+0x40  nominal frame rate       +0x44..+0x50  four merge factors
+0x54  aspect marker  +0x58  full/crop  +0x5C  vblank  +0x60  analogue fingerprint

13 distinct rasters, 17 distinct frame rates. The merge tuple is (1,1,1,1) for a full readout, (2,2,2,2) for half, (3,2,3,3) and (3,3,3,6) for the thirds.

13 種不同光柵、17 種不同格率。合併倍率那組四個數字:全讀是 (1,1,1,1)、對半是 (2,2,2,2)、三分之一是 (3,2,3,3) 跟 (3,3,3,6)。

The frame rate field lies, on purpose and by accident

那個格率欄位會騙人,而且有兩種騙法

+0x40 is the frame rate, confirmed against measurements: mode 3 says 30 and runs 29.97, mode 98 says 78 and runs 77.27, mode 121 says 25 and runs 24.9997. It is a nominal value.

+0x40 確實是格率,拿實測值對過:mode 3 寫 30、實跑 29.97;mode 98 寫 78、實跑 77.27;mode 121 寫 25、實跑 24.9997。所以它是標稱值 —— 這是第一種騙法,精度而已。

It also becomes an outright lie when a project retimes a donor mode. OG3K drives mode 98 at 29.97 while its metadata still says 78. Anything that reads +0x40 to label a clip is reading a stale number.

第二種比較兇:專案把某個模式的時序改掉之後,這個欄位就變成純粹的謊話。OG3K 讓 mode 98 跑 29.97,但它的 metadata 還寫著 78。任何拿 +0x40 去標記素材的東西,讀到的都是過期的數字。

Each profile is a row; each field is a separate array of 306 words. An element is column_base + row×4. The fields that matter for geometry:

一個 profile 是一列;但每個欄位各自是一個 306 個字的陣列,要取值是 欄位基底 + 列號×4。跟幾何有關的欄位:

+0x58  preview hbin   0xC0BD8EBC      +0x5C  record hbin   0xC0BE1E2C
+0xC4  preview vbin   0xC0BD9384      +0xC8  record vbin   0xC0BE22F4
+0x60  preview zoomH  0xC0BD984C      +0x64  record zoomH  0xC0BE149C
+0xD0  preview zoomV  0xC0BD9D14      +0xD4  record zoomV  0xC0BE1964

Profile 43 and 83 are the hidden 3K

Profile 43 跟 83 就是藏起來的 3K

The firmware already had a 3032×2012 path — on the stills side. Profiles 43 and 83 are the S-size 12-bit photo profiles, and they carry exactly the geometry OG3K wanted:

韌體本來就有 3032×2012 這條路 —— 只是在拍照那邊。profile 43 跟 83 是 S 尺寸 12-bit 照片的 profile,而它們帶的幾何正好就是 OG3K 想要的:

RAW geometry   3032x2012        crop  3008x2000 @ (12, 6)
sensor window  3032x2012        sensor mode  98 (p43) / 143 (p83)
+0x1C          2  = 3:2 marker  +0x30 frame rate  -1.0 (stills have none)
RAW RWZM       0x3FF = unity

That is why swapping to p43 made recording clean immediately: it was not improvised, it was the camera's own full-height 3:2 capture path, previously only used for photographs. The movie side has no 3K anywhere — not in the picker's 78 entries, not in the playback name tables, not in the CINE menu.

這解釋了為什麼一換上 p43,錄影立刻就乾淨了 —— 那不是我們硬湊出來的東西,而是相機自己的全高 3:2 擷取路徑,只是原本只服務照片。
錄影那邊則是完全沒有 3K:picker 的 78 筆沒有、回放名稱表沒有、CINE 選單也沒有。

OG3K ships on p83, not p43. They differ only in +0x030, which turned out to be the nominal frame rate (float): p43 holds −1.0 (0xBF800000), p175 holds 30.0 (0x41F00000). The RAW buffer count is derived from it, and −1.0 means zero buffers — that was the garbled last frame. p43 is the stills view profile; p83 is the capture profile and already allocates three.

OG3K 最後用的是 p83,不是 p43。 兩者只差 +0x030, 後來查明那是標稱格率(float):p43 是 −1.0(0xBF800000)、p175 是 30.0(0x41F00000)。 RAW 緩衝張數由它導出,−1.0 = 零張 —— 那就是「最後一幀花屏」的來源。p43 是照片檢視用, p83 是拍攝用,原廠就配三張。

The register container at 0xC0B5FDA4 holds 70 records of 0x288 bytes. The frame period is hmax × (vmax−1) + tail cycles at 72 MHz, and the rolling shutter is hmax × height / 72 MHz.

暫存器容器在 0xC0B5FDA4,70 筆,每筆 0x288 bytes。一幀的週期是 hmax × (vmax−1) + tail 個 72 MHz 時脈,捲簾時間是 hmax × 高度 / 72 MHz。

Mode 12 is the clean example, because it needs no retiming at all:

mode 12 是最漂亮的例子,因為它完全不用改時序:

raster         2016 x 672      hmax/tail  330 / 330     vmax  910
frame cycles   330 x 909 + 330 = 300,300 @ 72 MHz
actual rate    239.760240 fps  exactly, 0 ppm
rolling        330 x 672 / 72 MHz = 3.080 ms

光柵      2016 x 672      hmax/tail  330 / 330     vmax  910
每幀時脈  330 x 909 + 330 = 300,300 @ 72 MHz
實際格率  239.760240 fps  剛好,誤差 0 ppm
捲簾      330 x 672 / 72 MHz = 3.080 ms

Every other open-gate target has to rewrite a donor mode's timing to get the rate it wants, which is what makes the metadata frame rate go stale. HSW is the only one where the sensor is left completely untouched.

其他每一個 open gate 目標,都得把借來的模式的時序改掉才能拿到想要的格率 —— 那正是上一關講的「metadata 格率變成謊話」的來源。HSW 是唯一一個感光元件一個位元都不用動的。

Covered in full in the reduction path. The short version: an eight-branch selector at 0xC0325228 decides which window is enabled and which of six chain positions it taps. Only Crmf and Hbin2 are ever actually enabled; Gain, Vbin and Spc are never written at all, and Hbin only ever lands on a window that branch leaves switched off.

完整的在縮減路徑那頁。這裡講重點:0xC0325228 有個八分支的選擇器,決定哪個窗開著、以及從鏈上六個位置的哪一個抽料。
實際上只有 Crmf 跟 Hbin2 被真的開啟過。Gain、Vbin、Spc 從來沒被寫過;Hbin 有被寫,但每次都寫在一個「那條分支剛好沒開」的窗上。

Distribution over all 306 profiles: 172 + 81 take the Crmf branches, 36 take Hbin2, 17 take RWZM, and the two-pipeline branch is never reached by anything.

306 個 profile 的分布:172 + 81 走 Crmf、36 走 Hbin2、17 走 RWZM,雙管線那條一筆都沒有。

The part that is easy to misread. The recording hbin/vbin fields (+0x5C/+0xC8) are zero in all 306 profiles, which is where "CinemaDNG never uses hbin" comes from — and taken on its own it is true. But branch E's main pipeline does not read those fields: it reads the recording RWZM ratio together with the preview hbin/vbin tap counts (+0x58/+0xC4), and those are set to 1 on exactly the 17 UHD profiles. So on those 17, hbin÷3 and RWZM÷1.5625 really do run together on the recording path, using a field that otherwise serves the LCD. Everywhere else the two are mutually exclusive branches.

最容易讀錯的地方。錄影那組 hbin/vbin 欄位 (+0x5C/+0xC8)在 306 筆裡全部是 0 —— 「CinemaDNG 不用 hbin」這個說法就是從這裡來的,單看這組欄位它是對的。
但是分支 E 的主管線根本不讀那組欄位:它讀的是錄影的 RWZM 比率, 搭配預覽那組 hbin/vbin 抽頭數(+0x58/+0xC4)—— 而那一組正好在那 17 個 UHD profile 上被設成 1。
所以那 17 筆,錄影路徑上 hbin÷3 跟 RWZM÷1.5625 真的是疊在一起跑的, 用的還是一個平常服務 LCD 的欄位。除此之外,兩者確實是互斥的分支。

A divisor scaled by 1024, clamped so anything at or below 1024 means 1.0×. Horizontal and vertical are independent registers with independent clamps, so anamorphic is possible in code — but no stock profile does it.

它存的是「除數 × 1024」,而且有地板:任何 ≤ 1024 的值都當成 1.0×。水平跟垂直是兩個獨立的暫存器、各自獨立夾制,所以程式上做非等比是可以的 —— 但原廠沒有任何一個 profile 這樣用。

This is the stage that made open gate work. Profile 122's RWZM was 0x640 = 1600 = 1.5625×, which pinned the producer's active area at 1936 wide. Setting all four fields to unity is what let the frame fill 3032×2012.

open gate 能成,關鍵就在這一關。profile 122 的 RWZM 原本是 0x640 = 1600 = 1.5625×,這個值把 producer 的有效區釘死在 1936 寬。四個欄位全部改成 unity,畫面才填滿 3032×2012。

The canvas is assembled in FUN_c043a158 and then derived into several downstream copies. The hook that works overwrites the record after it is built and before anything is derived from it, at 0xC043A19C.

畫布是在 FUN_c043a158 裡組出來的,組好之後會推導出好幾份下游複本。真正有效的 hook,是在「組好了、但還沒有人從它推導」的那個瞬間覆寫它,位置在 0xC043A19C。

result of the working hook:
  0xC37CE210   3032 x 2012 x 9,229,824      (six earlier attempts: 1936 1090 3244544)
  on card      9,229,824 bytes x 81 frames
  overwrite    hit 491 times

成功那次的結果:
  0xC37CE210  3032 x 2012 x 9,229,824   (前六次都是 1936 1090 3244544)
  卡上        9,229,824 bytes × 81 幀
  覆寫命中    491 次

Six rounds of failure came from patching things that were computed downstream of this record. That is the general lesson: in this chain, find where a value is constructed, not where it is visible.

前面六輪失敗,全部都是在改「從這份記錄推導出來的下游東西」。這條鏈的通則就是這句話:要找值被「組出來」的地方,不是找它「看得見」的地方。

The producer writes a packed 12-bit CinemaDNG strip, one stripe per frame. Two pairs of fields in the descriptor turned out to mean different things:

producer 寫出的是打包 12-bit 的 CinemaDNG strip,每幀一條。描述子裡有兩對尺寸欄位,後來才發現它們意思不一樣:

Measured from a camera screenshot during recording: the image band occupied 0.5630 of the non-HUD area, matching 1090/2012 = 0.5417 and nothing else. The producer was writing 1090 rows while the consumer displayed 2012.

這是用相機自己的截圖量出來的:錄影時畫面上的影像帶佔了非 HUD 區域的 0.5630,對得上 1090/2012 = 0.5417,其他候選值都對不上。也就是 producer 只寫了 1090 行,而消費端在顯示 2012 行。

Each frame is a complete DNG: a fixed 78,848-byte header followed by the strip. At FHD that header is 2.4% of the file; it would be 6.3% if the payload were compressed.

每一幀都是一個完整的 DNG:固定 78,848 bytes 的表頭,後面接 strip。在 FHD 這個表頭佔檔案的 2.4%;如果內容壓縮了,它會變成佔 6.3%。

ImageWidth      3032      ImageLength      2012
BitsPerSample   12        Compression      1        // uncompressed, always
RowsPerStrip    2012      StripOffsets     78848
StripByteCounts 9,150,584           // 3032x2012x12/8 = 9,150,576, plus 8

(That block is the early 3032×2012 build. Shipping OG3K records 3024×2010, because 3032 is not 16-aligned and in-camera playback broke on it — see playback.)

(上面那組是早期 3032×2012 的版本。正式的 OG3K 錄 3024×2010, 因為 3032 不是 16 的倍數,機內回放會壞 —— 見回放。)

The main image is in IFD0 with the dimensions inline and no SubIFD, which is why reading a frame's size on-camera only needs the first kilobyte.

主影像在 IFD0、尺寸直接內嵌、沒有 SubIFD —— 所以想在相機上讀一幀的尺寸,只要讀前 1 KB 就夠了。