Allow relationship fields to define image resize/crop options

[kpc2]

Currently, if you want Payload to handle image cropping, there are two approaches for organizing media that I am aware of:

1. Single collection for all images with global imageSizes options
   This approach is convenient because it provides a single source of truth for all media. However, it is wasteful in terms of storage and compute power, since every uploaded image is cropped and resized for every possible use case—even ones that may never be needed.

2. Separate collection for each use case
   This approach saves space because each collection can have tailored imageSizes options. The downside is increased clutter in the admin UI, and you may need to upload the same image multiple times if it is needed in more than one situation.

I propose a third approach, which was briefly discussed in this Discord thread from two years ago, that could combine the best of both worlds:

3. Single collection with cropping/resizing at the relationship field level
   In this approach, images are stored in a single collection, but cropping/resizing only occurs when the image is added to a relationship field. Each relationship field could define its own imageSizes options. This could avoid unnecessary crops and resizes, saving both storage and compute resources, while maintaining a single source of truth for original images.

The only missing piece in Payload currently is the ability for a relationship field to specify imageSizes when pointing to a media collection. Payload could also adopt a filename convention similar to other image processing services so that if an image has already been cropped/resized for one field, it doesn’t need to be regenerated if another has the same settings (other than the name field in imageSizes).

[antony-mota-hel]

The suggested approach would be extremely helpful, especially when migrating from another headless CMS like Prismic, which supports multiple image variants per-field with their own crop options.