Transformers、RGBA浮動小数点画像の修正を提案　アルファ値のスケール不整合に対応

Transformersコミュニティは11月7日、4チャンネルの浮動小数点画像に対する convert_to_rgb のアルファ合成を修正するPR #50464を提出しました。問題は、値が依然として [0,255] の float32 入力で発生します。コードが浮動小数点型を [0,1] にスケーリング済みとみなすため、alpha値が正規化されず、RGBの結果が有効範囲を大幅に超えていました。確認時点で、この提案は引き続きレビュー中です。修正提案

報告者はTransformers 5.23.0.dev0 で、1ピクセルの再現例を示しました。RGBA値 [64,128,192,128] を白背景に合成すると、期待値は約 [159.13,191.25,223.37] ですが、実際には [8065,16257,24449] となりました。報告によると、PIL経路では変換時に失敗し、Torchvisionバックエンドでは異常値がリスケールや正規化の処理まで進み、気づきにくい入力データの汚染につながる可能性があります。再現例

この問題は、2種類の入力規約の接続に関係しています。Torchvisionの公式ドキュメントでは、浮動小数点画像の値域は [0,1]、uint8 の値域は [0,255] とされています。一方、報告されたケースのTransformersプロセッサでは、後続の処理でリスケールが行われます。そのため、dtypeだけでは前処理時点の値のスケールを判定できず、float32 に変換しただけで正規化が完了したとみなすこともできません。Torchvisionの値域に関するドキュメント

提案された修正では、浮動小数点画像の値域を確認し、それに応じた白背景値を選択してalpha値をスケーリングします。また、NumPyとTorchvisionの各経路で、2種類の値域を対象とする回帰テストも追加しています。ただし、11月8日のレビューでは、この変更によって従来ndarrayを返していた呼び出しがPIL画像を返すようになり、後続処理で .shape や .dtype を参照するコードが失敗する可能性も指摘されました。数値の修正には、インターフェースとの互換性への配慮も必要です。レビューでの議論

ビジョンモデルのデータパイプラインを保守するエンジニアにとって、これはチャンネル数、dtype、値域の整合性を確認する具体例です。再現結果から推測すると、異常な前処理がモデル入力に影響する可能性はありますが、現時点で精度低下を示す測定結果はありません。今後は、互換性に関する調整、テスト結果、正式リリースへの収録状況を追跡するとともに、自身のデータが未スケーリングの浮動小数点RGBAとして合成処理に入るかを確認する必要があります。