速查 › 圖片的像素怎麼排

圖片的像素怎麼排

大頭照與臉皮那兩頁各留了一個「未解」： 知道格式代號、知道尺寸，但不知道像素是怎麼排的。 這頁把它解開 —— 而且不用寫程式，拿計算機就能驗。

先講清楚：什麼是實測，什麼只是名字

算術自證：拿計算機就能驗

區塊壓縮的規則只有一條：畫面切成 4×4 的小方塊，每個方塊固定用同樣多的位元組。 只有兩種方塊大小 —— 8 個或 16 個位元組。

知道這條規則，就能自己算。大頭照那頁已經量到 「每張圖的像素資料都是 65,536 bytes」，代進去：

算式只有一種填法對得起來。 同一個代號換一個尺寸照樣成立 —— 所以不是湊出來的。

0x60  →  永遠是 0.5
0x61  →  永遠是 1.0

解出來長什麼樣

本站照上面的規則實際解了兩張（EA 原廠的圖不會放上站，那是遊戲的內容。 社群自己做的模組另當別論，見球衣那一課）：

看到的東西本身就是最強的證據。一個位元組排錯，人臉會立刻散成條紋雜訊。

第二次獨立驗證：透明度層

0x61 每個方塊多出來的 8 個位元組是透明度。把它單獨畫成黑白圖：

• 得到一個乾淨的頭肩剪影，輪廓跟彩色圖完全對得上
• 65,536 個像素裡，36,194 個完全不透明、27,610 個完全透明，中間值很少
• 透明區域的連通塊：隨機 30 張裡中位數只有 1 塊
  但不是上限 —— 有一張長捲髮球員的髮絲把背景切碎， 連通塊 64 塊。已確認不是解錯：那張圖解出來是完全正常的證件照。 「中位數 1 塊」可以寫，「最多只有幾塊」這種上限句不能寫 —— 30 張的抽樣抽不到極端值。

如果透明度解錯了，會得到滿版雜點、幾千個碎塊。 得到一個完整剪影，等於第二次獨立驗證。

臉皮 0x60 則相反：隨機 30 張、合計三百九十多萬個像素， 完全透明的像素是 0 個 —— 臉皮是不透明貼圖。

九個代號各是什麼

 # | R  G  B  A
 0 | ff ff ff 00      ← 透明度 = 編號 × 17
 1 | ff ff ff 11
 2 | ff ff ff 22
 …
15 | ff ff ff ff      ← 16 級,一個不多一個不少

修之前   g001.fsh → ❌ 沒見過的格式代號 0x7F
修之後   g001.fsh → 0x7F (RGB24) 128x128 · 像素 49152 bytes · 每像素 3.000

0x7B 圖片 16,400 bytes (128×128)
  → 0x2A 調色盤 1,040 bytes
  → 0x69 附掛文字 80 bytes
  → 0x70 結束

 # | R  G  B  A
 0 | ff ff ff 00
 1 | ff ff ff 11
 2 | ff ff ff 22
 …
15 | ff ff ff ff      ← 16 筆,透明度 = 編號 × 17

順帶解釋一件大頭照那頁量到但沒說明原因的事： 0x7D 的 128×128 × 4 bytes 跟 0x61 的 256×256 × 1 byte 剛好一樣大。一個是每像素四個位元組的完整色彩、一個是區塊壓縮， 平均差四倍，所以能塞的面積就差四倍。

2026-08-29 再掃一次：把以前漏掉的一整類補進來

上面那次掃描是 52,747 筆影像記錄。這次重掃，加了兩類以前沒走到的地方：

• 巢狀封裝檔 —— 有些封裝檔裡只裝一個壓縮過的封裝檔 （見 執行檔裡剩下的原始碼痕跡）。 不多拆一層，裡面的東西在統計上等於不存在。
• 散裝的 FSH 與單獨壓縮的檔 —— 不在任何封裝檔裡的那些。

結論沒有變，但「沒有」這句話的份量變了： 以前是「在剛安裝好的原版上掃了五萬多筆沒找到」，現在是「連裝滿模組的測試機也掃了十萬多筆、 而且把以前漏掉的一整類補進來之後，還是沒找到」。 否定句的可信度取決於你找過哪裡，不取決於你找了幾次。

（2026-09-05 訂正：上面那兩欄不是同一台機器，本頁原本沒有講。 五萬多那次掃的是剛安裝好的原版，十萬多這次掃的是裝滿模組的測試機 —— 光是 0x79 就從 431 筆變成 568 筆， 那正是這台機器多出來的球衣槽（見球衣那一課）。 本站把剛安裝好的原版照這次的口徑（含巢狀與散裝，往下拆三層）重走一次，得到 52,822 筆 —— 比上次只多 75 筆。 所以筆數會翻倍，主要來自換了機器，不是來自補進巢狀與散裝那兩類。 兩台都掃過，兩台都是 0x7B 9 筆、0x7E 0 筆，結論本身不受影響。）

其餘格式這次量到：0x6D 37,633 · 0x78 32,215 · 0x61 13,658 · 0x60 10,978 · 0x7D 10,728 · 0x79 568 · 0x7F 45。

⭐ 每張圖後面都掛著一句 EA 自己寫的話

主圖後面接著一個附掛區塊，代號 0x69，固定 80 個位元組。 裡面是純文字，而且它自己說出自己是什麼：

EAGL64 metal bin attachment for runtime texture management

EAGL 就是 EA 自家的繪圖引擎（執行檔裡有一整排 EAGL::ViewPort::… 的符號）。這是一句給執行時貼圖管理用的註記。

（2026-09-05 訂正：這一欄原本的欄名寫「圖」，跟本頁其他地方的口徑不一樣。 它數的是 .fsh 檔的個數，不是子圖的張數 —— 一個 .fsh 可以裝很多張圖。models.big 那 2,331 個檔裡有 四萬多張子圖（見模型與臉皮那頁）， uniforms.big 的 692 個檔裡有 1,336 張； portrait.big 剛好一個檔一張，所以 7,542 兩種算法一樣。 models.big 的目錄上其實有 2,332 個 .fsh，這裡只數到 2,331 —— 有一個（c333.fsh）本站的 QFS 解壓器解不開。 本頁頁尾的 48,885 用的是子圖那個口徑。）

正常　　：EAGL64 metal bin attachment for runtime texture management
這 3 張：EAGL64 mel   bin attachment for runtime texture management

兩個抓到自己錯的地方

這頁不能告訴你什麼

三個沒有包在封裝檔裡的圖（2026-08-28 量的）

data\igshapes\ 是少數不用解封裝檔就看得到的圖 —— 四個檔直接躺在資料夾裡，而且沒有壓縮， 開頭就是 SHPI。

驗算：512 × 256 × 4 位元組 = 524,288，加上 976 個位元組的表頭 正好是 525,264。而且每個檔的 SHPI 檔頭裡宣告的長度 都等於檔案本身的長度，四個檔全對。

📌 重點整理

• 一句話 大頭照與臉皮的像素排法解開了，而且不用寫程式就能驗，把「像素位元組數 ÷ 寬 ÷ 高」算出來，0x60 永遠是 0.5、0x61 永遠是 1.0，走過兩個倉庫全部 48,885 張圖沒有一張算出別的數字。
• 規則只有一條 畫面切成 4×4 的小方塊，每塊固定 8 或 16 個位元組。256×512 的 0x60 與 256×256 的 0x61 都剛好是 65,536 bytes，128×128 的 0x61 是 16,384，同一個代號換尺寸照樣成立。第二次獨立驗證是透明度層：0x61 多出來那 8 個位元組單獨畫出來是一個乾淨的頭肩剪影，65,536 個像素裡 36,194 個完全不透明、27,610 個完全透明。但「連通塊中位數 1 塊」可以寫，「最多只有幾塊」這種上限句不能寫，有一張長捲髮球員的髮絲把背景切成 64 塊，而那張圖是正常的。
• 本站訂正之一：用途不等於格式定義 0x79 原本寫成「不是圖，永遠 1×1」，依據是 uniforms.big 的 431 個空球衣槽 431/431 都是 1×1。那個量測本身沒有錯，錯在把「它在這個檔裡的用途」寫成了「這個格式的定義」。中文字型的字圖集同一個代號是 1024×512、262,368 bytes、正好 0.500，而定案的證據是調色盤：au20b_en.ffn 後面接的 0x2A 區塊 size 欄位寫 80 = 16 + 16×4，裡面正好 16 筆白色配透明度階梯，2⁴ = 16，一筆不多一筆不少。
• 本站訂正之二：訂正從來沒有進到程式碼 頁面上早就寫著「本站工具裡的名字有三格是錯的」，但被指出錯的那份程式碼一直沒有改，同一份字典出現在當時的五支下載腳本裡，五份一模一樣、五份都是舊的（今天帶著這份字典的是八支，內容都已同步）。複驗還發現不只名字錯，還少了 0x7F 與 0x79 兩格，而那份字典同時被當成守門員，所以做新臉皮那支腳本會拒絕 models.big 裡 45 個真實存在的檔。修好之後 g001.fsh 認得出來是 0x7F 128×128、49,152 bytes，128 × 128 × 3 算術自己對上。⭐ 這個錯的形狀值得記：把錯誤寫進文件，不等於修好了它，而且六道檢查器一道都沒抓到，已補上第九道專門比對「頁面上的結論」與「附在頁面上的程式碼」。
• 另外兩處自己抓到的錯 一、工具表上三格的每像素位元組數是錯的，0x6D 表上 4.0 實測 2.0、0x7D 表上 3.0 實測 4.0、0x7F 表上 1.0 實測 3.0（0x7D 那格還是上線後複驗才抓到的）。二、本站待辦清單上寫著「0x7C 區塊 256 bytes，只在兩個檔出現」，本頁原本判它三個前提全錯，2026-08-29 收回那句訂正：0x69／80 bytes 的註記確實 7,542 張100% 都有，但它跟 0x7C 是兩個不同的區塊 —— 三份剛安裝好的原版各 2,391 張圖裡，2653.fsh 與 2663.fsh 這 2 張真的多一塊 0x7C、256 bytes，三份完全一致。在 portrait.big 裡，原本那條筆記是對的，掃不到是因為測試機上這兩張已經被換過（2026-09-05 訂正：但「只在那兩個檔」只對 portrait.big 成立 —— data\igshapes\igcrsr.fsh 也帶著一塊 0x7C，長度是 576 不是 256）。「只在某兩個檔出現」要先去看第三個檔；「一張都沒有」要先確認自己看的那台機器還是不是原版。
• 驗證器自己也有盲點 本站用「相鄰像素差」判斷有沒有解錯，對大頭照很好用（正解 5.19、各種錯解 16 到 91）。但它對臉皮 0x60 不只是失效，是會選錯邊：誤讀 5.29 分、正解 8.99 分，誤讀看起來還比較好，因為誤讀會讓下半張圖整整 256 列全黑，而全黑區的相鄰差是 0，把平均硬生生拉下去。真正抓到它的是算術。檢查器過關不代表沒錯，要有第二種完全不同的驗法。
• 否定句的份量取決於你找過哪裡 0x7B 原本標成「兩個倉庫裡一張都沒有」，後來在剛安裝好的原版裡 52,747 筆影像記錄中找到 9 筆（md5 只有 3 張相異的圖），調色盤就接在圖片後面，1,040 = 16 + 256×4，而且索引 0 佔了 88% 的像素、剛好是透明背景。2026-08-29 重掃把巢狀封裝檔與散裝檔補進來，總數從 52,747 變成 105,834，0x7B 還是 9 筆、0x7E 還是 0 筆 —— 但這兩個數字不是同一台機器（2026-09-05 訂正）：五萬多那次是剛安裝好的原版，十萬多那次是裝滿模組的測試機，原版照同一個口徑重走只有 52,822 筆。另外每張圖後面都掛著一個 80 位元組的 0x69 註記，7,542 張裡有 3 張的那句字壞了（metal 變 mel），圖本身完全正常，那是不同工具留下的指紋。
• 本站沒驗的 0x7E 這個代號在十萬多筆記錄裡一張樣本都找不到，無從實測，徽章仍然是未解。0x7B 的內部排法也還沒解開，本站沒有解出來也不猜；它那九個調色盤裡有七個是 256 筆全部灰階，剩下兩個雖然各有 133 筆不是灰階，但其中 118 筆第 1 與第 3 個位元組相等、差的只有中間那一格，所以前三個位元組是 RGB 還是 BGR 本站無法判斷（連裝滿模組的測試機都掃過，最大彩度只有 21）。項目名稱 BPP2 到 BPP6 是什麼意思，本站不知道。壓縮那一半後來做了：0x60（DXT1）與 0x61（DXT3）兩種都壓得回去，用在換大頭照、做新臉皮、換開機畫面三課；其餘代號沒有做，腳本遇到會直接拒絕而不是猜。最後要分開講的是強度：「每像素幾個位元組」是本站量到的，「代號叫什麼名字」是 2002 年那份 FSHTOOL 說明書說的，兩件事不一樣。

接下來

• 大頭照 portrait.big —— 0x61 與 0x7D 的家
• 模型與臉皮 models.big —— 0x60 的家
• QFS 壓縮 —— 這些圖在倉庫裡是壓縮過的，要先解開才看得到代號
• 兩套球員編號 —— 哪一張圖屬於哪一位球員