Normalize floating point cast
Author: amyeroberts
Pull request: yes

# What does this PR do?

This is done if the input image isn't of floating type. Issues can occur when `do_rescale=False` is set in an image processor. When this happens, the image passed to the call is of type uint8 because of the type casting that happens in `resize` because of the PIL image library. As the mean and std values are cast to match the image dtype, this can cause NaNs and infs to appear in the normalized image, as the floating values being used to divide the image are now set to 0.

The reason the mean and std values are cast is because previously they were set as float32 by default. However, if the input image was of type float16, the normalization would result in the image being upcast to float32 too.

Fixes # (issue)

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [x] Did you write any new necessary tests?

Comments:
_The documentation is not available anymore as the PR was closed or merged._

> as the floating values being used to divide the image are now set to 0.

could you explain this a bit more?

>> as the floating values being used to divide the image are now set to 0.

> could you explain this a bit more?

Sure! So for a lot of the image processors, the default normalization constants are floats e.g. `(0.5, 0.5, 0.5)`. In the current `normalization` implementation, `mean` and `std` are cast to the [dtype of the image](https://github.com/huggingface/transformers/blob/c5037b459e117b9286c611092f38663f6cb763b0/src/transformers/image_transforms.py#L384). If the input image is e.g. `int32`, then the normalization constants are cast to int and would become e.g. `(0, 0, 0)`. So when normalizing with `img - mean / std`, we can end up with division by zero errors

> > > as the floating values being used to divide the image are now set to 0.
> 
> > could you explain this a bit more?
> 
> Sure! So for a lot of the image processors, the default normalization constants are floats e.g. `(0.5, 0.5, 0.5)`. In the current `normalization` implementation, `mean` and `std` are cast to the [dtype of the image](https://github.com/huggingface/transformers/blob/c5037b459e117b9286c611092f38663f6cb763b0/src/transformers/image_transforms.py#L384). If the input image is e.g. `int32`, then the normalization constants are cast to int and would become e.g. `(0, 0, 0)`. So when normalizing with `img - mean / std`, we can end up with division by zero errors

I see, thank you a lot for the detail.