Create standard way for preprocessors to do graphic resizing

[jeffbl]

Talking with @AndyBaiMQC this morning, it will likely be necessary to resize graphics going to local ML models, each of which may have its own constraints. We've been burned by resizing issues numerous times throughout the project (example example , and there are others). Goal of this work item is to come up with a clear and documented way for preprocessors to resize graphics. Key functionality includes:

• Must support a wide variety of graphic formats (jpg, png, gif, etc.)
• good performance
• easy to integrate (easy, clean API that is hard to mess up)

Assigning to @JRegimbal first to weigh in on architecture, before going to @jaydeepsingh25 for implementation. Some options:

• Choose a library and have each preprocessor use it directly
• Implement a service that encapsulates resizing so that if we want to change it in the future, we only have to change it in one place (e.g., to support a new graphic format, or if the library we initially choose turns out to have flaws or is no longer supported, etc)
• Have the orchestrator resize before sending to preprocessor based on a parameter in docker-compose
• ???

BONUS: If we centralize this, we could also use it to transform photos into a common format, to support a wider variety of weird graphic types. E.g., if the library can transform .png into .jpg as well, then we don't have to rely on preprocessors supporting .png. Probably should break out into separate issue, or generalize this one into "transform graphics before they go to preprocessors)

[jeffbl]

Putting in current sprint to at least decide what to do, even if implementation is later. @AndyBaiMQC please don't spend time on resizing now, so that we can decide on an overall plan.

[JRegimbal]

Hmm...if we really want to have image resizing as a shared feature I think the most convenient options would be to build it into the orchestrator or have all the preprocessors just use pillow. My immediate reaction to including it in the orchestrator is hesitancy, since we want to keep it small to avoid bugs, but we could probably use something like sharp in cases where 1) a graphic is included in the request, and 2) the preprocessor uses labels to request some maximum size/format.

Is resizing/reencoding the only tasks that would be necessary, @AndyBaiMQC?

[JRegimbal]

Reassigning to @AndyBaiMQC and @jaydeepsingh25 since we're taking the common library route.

[jeffbl]

Moving to backlog until there is space in a sprint for this.

[AndyBaiMQC]

@jeffbl Circling back to this one: Need a comprehensive review on list of models/methods for existing preprocessors, and the changes following Ollama adoption (which hopefully makes it easier to do 'one size fits as many as possible')