[Trainer] Allow passing image processor
Author: NielsRogge
Pull request: yes

# What does this PR do?

Fixes #29790. Also reported here: https://discuss.huggingface.co/t/vitimageprocessor-object-has-no-attribute-pad/32511.

Currently, passing an image processor to the Trainer is pretty hacky, as users need to do `tokenizer=image_processor`. 🤔 yes, that's right.

This PR adds the `image_processor` argument to the Trainer, such that the default data collator is used by default in case an image processor is passed.

To do:

- [x] update example scripts to no longer use tokenizer=image_processor

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_29896). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Can we add enabling passing a feature_extractor and processor too?

@ArthurZucker feel free to approve the PR, @amyeroberts I would add those in a separate PR

cc @NielsRogge @tomaarsen the addition of the new param to `trainer_callback.CallbackHandler` is currently causing problems for the [`setfit.Trainer` class](https://github.com/huggingface/setfit/blob/c64b16160e6ea6df08414d240be13f5f4f3b8b89/src/setfit/trainer.py#L234) in the SetFit library. can we either make the param optional, or update `setfit.Trainer` to pass a value in for the new param?

self.callback_handler = CallbackHandler(callbacks, self.model, self.model.model_body.tokenizer, None, None, None)

> Can we add enabling passing a feature_extractor and processor too?



> @ArthurZucker feel free to approve the PR, @amyeroberts I would add those in a separate PR

useful, waiting...

> cc @NielsRogge @tomaarsen the addition of the new param to `trainer_callback.CallbackHandler` is currently causing problems for the [`setfit.Trainer` class](https://github.com/huggingface/setfit/blob/c64b16160e6ea6df08414d240be13f5f4f3b8b89/src/setfit/trainer.py#L234) in the SetFit library. can we either make the param optional, or update `setfit.Trainer` to pass a value in for the new param?


self.callback_handler = CallbackHandler(callbacks, self.model, self.model.model_body.tokenizer, None, None, None)

@NielsRogge @ArthurZucker For Preprocessing classes. Suggest modifying the tokenizer parameter name instead of adding parameters. Consider changing tokenizer to processors.

Yes @chenin-wang I was also considering this, rather than having various attributes for tokenizer, image processor, feature extractor and multimodal processor it probably makes more sense to just have a single argument called `processor`. Although that would be a breaking change since many people alreasy use `tokenizer=...`

Will await opinion of Arthur and Amy

> Yes @chenin-wang I was also considering this, rather than having various attributes for tokenizer, image processor, feature extractor and multimodal processor it probably makes more sense to just have a single argument called `processor`. Although that would be a breaking change since many people alreasy use `tokenizer=...`
> 
> Will await opinion of Arthur and Amy

You are right. Will change user habits.


Reflecting more on this, I think the best way is to have a proper deprecation message.

Basically now whenever people pass the `tokenizer` argument, we should add a message saying "the tokenizer argument is going to be deprecated in v4.xx of Transformers and you need to update your code to pass `processor` instead."

=> this way people can safely update their code without having breaking changes from the start. Will open a follow-up PR for this.

@NielsRogge @amyeroberts The problem remains. https://github.com/huggingface/transformers/pull/30102#issuecomment-2044383955

Hi @chenin-wang could you clarify your issue?

@NielsRogge tokenizer=image_processor is a confusing API (as highlighted by a few issues from users) and considering we have more and more multimodal, audio and vision models increasingly out-of-date，what amyeroberts saied https://github.com/huggingface/transformers/pull/30102#issuecomment-2044383955.

Yes @chenin-wang I agree. So indeed we should continue with #30102. However I'm thinking about the term `preprocessor` rather than `processor`, as processor is already used for multimodal processors like CLIP, BLIP-2, etc.

Not sure if people prefer `processor=image_processor` or `preprocessor=image_processor`.

Hence I'll ask the question to some HF members and see which term they prefer. Will then proceed.