Transformers Proposes RGBA Floating-Point Image Fix for Alpha-Scale Mismatch

On November 7, the Transformers community submitted PR #50464 to fix alpha compositing for four-channel floating-point images in convert_to_rgb. The issue occurs with float32 inputs whose values remain in [0,255]: the code treats the floating-point data as already scaled to [0,1], leaving alpha unnormalized and pushing the RGB result far outside its valid range. As of this review, the proposal remains open.

The reporter provided a single-pixel reproduction using Transformers 5.23.0.dev0: compositing RGBA [64,128,192,128] over white should produce approximately [159.13,191.25,223.37], but instead produces [8065,16257,24449]. The report says the PIL path fails during conversion, while the Torchvision backend may allow the anomalous values to flow into rescaling and normalization, quietly contaminating the input. Reproduction

The issue arises where two input conventions meet. Torchvision’s official documentation expects floating-point images to be in [0,1] and uint8 images to be in [0,255]; in the reported case, the Transformers processor applies rescaling later. Dtype alone therefore cannot determine the value scale at the preprocessing stage, and converting to float32 does not mean the data has been normalized. Torchvision documentation on dtype and expected value range

The proposal checks the floating-point image range, selects the corresponding white-background value, and scales alpha. It also adds regression tests for both NumPy and Torchvision paths and for both value scales. However, on November 8, a reviewer noted that the change might cause existing calls that returned an ndarray to return a PIL image instead, breaking downstream code that reads .shape or .dtype. The numerical fix still needs to preserve interface compatibility. Review discussion

For engineers maintaining visual-model data pipelines, this is a concrete example of why channel count, dtype, and value range need to be checked together. The reproduction suggests that faulty preprocessing could interfere with model inputs, but no accuracy impact has been measured. Follow the compatibility changes, test results, and inclusion in a released version, and confirm whether your own data enters the compositing path as unscaled floating-point RGBA.