Transformers 提出 RGBA 浮點影像修補，處理透明度尺度錯配

Transformers 社群於 11 月 7 日提交 PR #50464，修正 convert_to_rgb 對四通道浮點影像的透明度合成。問題出現在數值仍為 [0,255] 的 float32 輸入：程式把浮點型別視為已縮放至 [0,1]，導致 alpha 未正規化，RGB 結果大幅超出合法範圍。截至查核，提案仍開放審查。修補提案

回報者在 Transformers 5.23.0.dev0 提供單像素重現：RGBA 為 [64,128,192,128]，以白底合成應得到約 [159.13,191.25,223.37]，實際卻得到 [8065,16257,24449]。回報指出，PIL 路徑會在轉換時失敗，Torchvision 後端則可能讓異常值繼續進入縮放與標準化，形成不易察覺的輸入污染。重現案例

這涉及兩套輸入慣例的銜接。Torchvision 官方文件預期浮點影像落在 [0,1]，uint8 則落在 [0,255]；回報案例中的 Transformers 處理器，會在後續才執行 rescale。因此，單靠 dtype 無法判定前處理當下的數值尺度，也不能假設轉成 float32 就已完成正規化。Torchvision 數值範圍文件

提案改為檢查浮點影像範圍，選用對應白底值並縮放 alpha，另加入 NumPy 與 Torchvision 兩條路徑、兩種數值尺度的回歸測試。不過，11 月 8 日有審查者指出，修改也可能讓原先回傳 ndarray 的既有呼叫改回傳 PIL 影像，使後續讀取 .shape 或 .dtype 的程式失敗；數值修正仍須兼顧介面相容性。審查討論

對維護視覺模型資料管線的工程師而言，這是檢查通道數、dtype 與數值範圍是否一致的具體案例。依重現結果推論，異常前處理可能干擾模型輸入，但目前沒有準確率下降的量測。後續應追蹤相容性調整、測試結果與正式版本收錄情況，並確認自身資料是否會以未縮放的浮點 RGBA 形式進入合成流程。