Add vision contribution guide

[molbap]

What does this PR do?

This updates the vision contribution guide, to help external contributors merge their work faster and reduce the load on maintainers with a checklist. It is a very minimal checklist that will need to be completed with specific model implementation guides following the new API.

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[zucchini-nlp]

Nice, my top pain points when reviewing model PR are below. Feel free to re-use them if you think it's valid to be added in the doc 😄

• Do not add code path with if/else if the released weights have only one path supported. Code path used for experiments are not needed and bloat up in the end
• Try to use @autodocstring and @check_model_inputs
• The model structure has to follow standards of other VLMs with correct class names. Some users add a vision backbone with its original name, i.e. RiceModel used in llava-onevision-1.5. IMO we can either add a separate vision model and call it RiceModel, or we add it in llava model-file and call it LlavaOnevision1_5VisionModel
• Users add many assertions, some are basic shape checks and not needed, while some are valid but without actionable error message. Let's nudge to add only valid checks with good error messages
• Users call model inputs as x, y, z, we can nudge for better naming conventions pixel_values, hidden_states. Especially in audio backbones, apparently copy from source code
• Always go over the PR again , look for commented code or left-over TODO/FIXME comments
• Do not use _checkpoint_conversion_mapping, convert checkpoints and release in the hub if needed
• The vision language models should have get_image_features() and get_placeholder_mask() methods
• When copying tests from similar models, delete all skipped tests and check if that applies for your model as well. Blind test skipping is not good

[zucchini-nlp]

maybe "or any multimodal model that processes images/videos" or simply vision objects?

[zucchini-nlp]

"it's better if configuration and processing is in it"

[zucchini-nlp]

can we nudge to add tests for all components which are not 100%-copies? In other words, if model has its own processing, then we also need processor tests etc. I've seen several times ppl adding only model tests and then we find issues in processing...

[zucchini-nlp]

to clarify maybe: checkpoints should fit in our runners so if the model size is huge, they need to load in 4-bit or in half precision etc. Also using small image sizes helps

[yonigozlan]

One small comment, but very eager to have this merge in general, this should simplify first reviews quite a bit 🤗

[yonigozlan]

I would add auto_docstring, can_return_tuple, check_model_inputs and _can_record_outputs. I think the more precise we can be the better! I see a lot of confusion on the use of the decorators, and how it's not necessary to add the output_attention, output_hidden_states etc.

[yonigozlan]

🤗

[ariG23498]

Adding links to scripts might make it more useful for the readers.

[ariG23498]

I have added the review from @zucchini-nlp and @yonigozlan as suggestions for the ease of @molbap.

Hope this helps!