Usually, it is conventional that the dtype of the image determines the range of an image. For example, when

• dtype is uint8 image is assumed to be 0 and 255 and:
• uint16 -> [0,65535]
• float -> [0,1) or [0,1] depending on the library

This is expected in many Python libraries such as matplotlib and tensorflow.

However, in bob.bio.face, it is assumed that images are between 0 and 255 irrespective of their type:

• https://gitlab.idiap.ch/bob/bob.bio.face/-/blob/8c50e1ee70d866b6c39d7c228cdf1df475a63822/bob/bio/face/database/pola_thermal.py#L103
• https://gitlab.idiap.ch/bob/bob.bio.face/-/blob/8c50e1ee70d866b6c39d7c228cdf1df475a63822/bob/bio/face/embeddings/resnet50.py#L138
• https://gitlab.idiap.ch/bob/bob.bio.face/-/blob/8c50e1ee70d866b6c39d7c228cdf1df475a63822/bob/bio/face/embeddings/tf2_inception_resnet.py#L19
• https://gitlab.idiap.ch/bob/bob.bio.face/-/blob/8c50e1ee70d866b6c39d7c228cdf1df475a63822/bob/bio/face/embeddings/mobilenet_v2.py#L68

I think this problem has arisen due to unconventional conversion of the image dtype in: https://gitlab.idiap.ch/bob/bob.bio.face/-/blob/8c50e1ee70d866b6c39d7c228cdf1df475a63822/bob/bio/face/preprocessor/Base.py#L102 where the range of the image is not changed during the conversion.

I think it is worth the effort to refactor the code and respect conventional image value ranges in bob.bio.face; a function similar to https://www.tensorflow.org/api_docs/python/tf/image/convert_image_dtype?hl=en could alleviate this problem.