Fix a couple of typos and add an illustrative test
Author: rjenc29
Pull request: yes

# What does this PR do?

<!--
Congratulations! You've made it this far! You're not quite done yet though.

Once merged, your PR is going to appear in the release notes with the title you set, so make sure it's a great title that fully reflects the extent of your awesome contribution.

Then, please replace this with a description of the change and which issue is fixed (if applicable). Please also include relevant motivation and context. List any dependencies (if any) that are required for this change.

Once you're done, someone will review your PR shortly (see the section "Who can review?" below to tag some potential reviewers). They may suggest changes to make the code even better. If no one reviewed your PR after a week has passed, don't hesitate to post a new comment @-mentioning the same persons---sometimes notifications get lost.
-->

<!-- Remove if not applicable -->

This PR fixes a couple of types in code / comments relating to COCO annotations.

I added a test to illustrate examples of legal and illegal encodings - possibly marginal utility; if the reviewer feels it's unnecessary, I have no problem removing it.

## Before submitting
- [x] 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?


## Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

<!-- Your PR will be replied to more quickly if you can figure out the right person to tag with @

 If you know how to use git blame, that is the easiest way, otherwise, here is a rough guide of **who to tag**.
 Please tag fewer than 3 people.

Models:

- text models: @ArthurZucker and @younesbelkada
- vision models: @amyeroberts
- speech models: @sanchit-gandhi
- graph models: @clefourrier

Library:

- flax: @sanchit-gandhi
- generate: @gante
- pipelines: @Narsil
- tensorflow: @gante and @Rocketknight1
- tokenizers: @ArthurZucker
- trainer: @muellerzr and @pacman100

Integrations:

- deepspeed: HF Trainer/Accelerate: @pacman100
- ray/raytune: @richardliaw, @amogkam
- Big Model Inference: @SunMarc
- quantization (bitsandbytes, autogpt): @SunMarc and @younesbelkada

Documentation: @stevhliu and @MKhalusova

HF projects:

- accelerate: [different repo](https://github.com/huggingface/accelerate)
- datasets: [different repo](https://github.com/huggingface/datasets)
- diffusers: [different repo](https://github.com/huggingface/diffusers)
- rust tokenizers: [different repo](https://github.com/huggingface/tokenizers)

Maintained examples (not research project or legacy):

- Flax: @sanchit-gandhi
- PyTorch: See Models above and tag the person corresponding to the modality of the example.
- TensorFlow: @Rocketknight1

 -->


Comments:
FYI @rafaelpadilla if you think that's relevant. Changing the class names might be not backward compatible. 
Feel free to ping us once this is ready 

Thanks for the feedback - this PR is probably ready for review. 

If there's a downside risk re: backwards compatibility, it probably isn't worth moving forwards with this PR - I have no issue closing it if so. 

I just thought I would raise it in passing as I was recently wiring up a DETR model and came across a few typos whilst trying figure out why my custom annotations failed to process (as anticipated: user error on my part :) ).

@rjenc29 Thanks for your work on improving this! Agreed with @rafaelpadilla, we should try to fix typos, even for class names, wherever we can (this was my bad!). 

Regarding moving the class to somewhere more central - I think that's a good idea. Originally it was within the model specific image processing files as it was just for DETR. `image_utils.py` seems the natural place, but open to suggestions. 

Generally, for both cases (spelling adjustment and moving) we should to be careful about backwards compatibility. Even though this isn't a public class, we might need at least a small deprecation cycle c.f. [this issue and comment](https://github.com/huggingface/transformers/issues/25948#issuecomment-1758537251). Searching [on github](https://github.com/search?q=AnnotionFormat&type=code&p=5) it seems other repos define the enum outright, so it should be OK without. 

My main request is that you confirm saved image processors with the old annotation format can still be correctly loaded i.e. the annotation format matches the preprocessor config (this should be checked with non-default values). 


Hi @amyeroberts, thanks vm for the feedback.

In the last deluge of commits (mostly, arguments with `black` and `ruff` unfortunately!), I have attempted to reduce code duplication a little.

In terms of backwards compatibility, I have imported `AnnotionFormat` back into the scripts where it was formerly defined and have attempted to add a `FutureWarning` to advertise that it's due to be deprecated - albeit it will get called at import time, and might therefore be annoying / noisy (let me know if so). My ambition was to do something less annoying / noisy, but Enums defeated me once more.

I've added a roundtrip test to create / save / load processors with various `format`s specified, and choose to do so in a way that would make it easy to remove further down the line when `AnnotionFormat` bites the dust. As far as I can see, it should be possible to use  `AnnotionFormat`  or the newfangled `AnnotationFormat` interchangeably. 

If this isn't really what you meant, let me know and I will refine further.







The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_26941). All of your documentation changes will be reflected on that endpoint.

@rjenc29 At the moment, there's a lot of integration tests for trainer failing on the CI, which will need to pass before we can merge. If you run the tests locally are you able to replicate the errors? 

I can't run some of the tests locally, but those that I can run seem to pass for me.


@rjenc29 Thanks for confirming. The following tests: 
* examples/pytorch/test_accelerate_examples.py::ExamplesTestsNoTrainer::test_run_glue_no_trainer
* examples/pytorch/test_pytorch_examples.py::ExamplesTests::test_run_ner

are unrelated to this PR. There's a fix being added to the accelerate library which once pushed and our CI runners updated should be resolved here. The other tests seem to be specific to this PR but might be flaky. 

Let's wait for the update in accelerate to be added, we'll re-run the tests here and then we can debug if some tests are still failing.  

Hi @rjenc29 - there was a recent push to main which should have resolved the unrelated failing tests. Could you rebase to see if this fixes them? Thanks! 

Well, I attempted a rebase but, judging by the files changes count, it looks a bit like I've destroyed my branch...

@rjenc29 oh no! Did you force push after rebasing? The commit history looks like branches I've had when I've just pushed without forcing after rebase. 

@amyeroberts I did not force push - I never, ever use rebase personally so doubtless have brought this on myself & can add it to my catalogue of git fails

haha - don't worry - git remains an enigma to the best of us 🙈 ! 

In this case, all you need to do force push the changes to the branch. Rebasing is effectively re-writing the history, so you need to force for the changes to be reflected on the remote. Worst case, this will all be squashed into a single commit when merging into main, so the history might be big on the PR but we can still clearly see which commits are yours and it doesn't prevent it from being added. 

Outside of that, the other tests that are failing appear to be unrelated to this PR but new. The good news is, you'll get to try rebase again, the bad news is you'll have to wait for us to track down the issue first (sorry :/) 

Thanks very much @amyeroberts - on your advice, I think I may have restored the health of my branch / this PR, which is potentially the first time I have ever successfully resolved a git foul-up - but then again, it is (almost) the season of miracles! 

@rjenc29 Great - glad it worked! 

The failing tests _should_ now have been resolved on main. If you can do one more rebase, things should all pass and we can merge 🟢 

Hi @amyeroberts, I rebased yesterday late afternoon - I think there's one residual test failure in this PR

@rjenc29 Apologies for this - we were having quite a few issues yesterday with stabilising the CI. One last (🤞) rebase should do the trick. 

@rjenc29 do you want me to merge this? Black is no longer used so a last-last-last rebase will be needed 🤣 
Apologies we didn't receive the ping for the green tick! 

Hi @ArthurZucker, I have rebased so this PR should be in good shape

@rjenc29 Thanks again for adding this and iterating to get everything green!