You see here that the image rotated without OETF (undo the “gamma”, apply the linear map, redo the “gamma” and save) doesn’t have the dark fringe of the one rotated with the OETF on (apply the linear map and save). PIL supports floating point interpolation, but only for one layer, thus forget about RGB, and is deprecated and soon to be removed. The drawback of uint8 is it cannot store negative values, which is important if you are doing wavelets-style frequency separation. Of course, there are tricks like adding 127 and normalizing, but tricks are bad in general, and the floating point arithmetic capabilities of modern CPU make any integer arithmetic speed-up unworthy of the rounding. Let’s be clean from ground up. The other drawback, that people often forget, is working in uint8 always assumes that your pixels are non-linearly encoded with an OETF ( Opto-electrical transfer function), improperly called a gamma, that is meant to alleviate quantization errors in lower bits (hence lower lights), which produce banding in smooth gradients in low lights. But performing convolutions, thus interpolations and linear maps, on OETF-encoded imagery does not retain the physical consistency of the pixel garbage with the scene light emission and will mess up gradients, possibly giving edge-artifacts : This is quite annoying if you are working with floating point images.

If you are working in image processing and using Python as a prototyping script language to test algorithms, you might have noticed that all the libs providing fast image interpolation methods (to either sub-sample or over-sample) work in 8 bits unsigned integers ( uint8).

Darktable import rotation