Provide OOTB Renditions to Asset Compute microservice extensibility

• Either: Pass a default rendition to the worker (instead of, or in addition to, the original).

• Or: Defer worker invocation until default renditions are generated (opt-in), so the worker can fetch them reliably.

• Or: Allow non ARM64 containers and installation of custom binaries like imagemagick for the Asset Compute microservice

We need to generate custom renditions (e.g., square JPEGs with white borders) from assets like .ai (Adobe Illustrator), .psd (Adobe Photoshop), .svg, .eps, etc. These file types are already supported by AEM’s default rendition generation, but not by Asset Compute workers directly (see below for reasons). If workers could use AEM’s default renditions as inputs, they could reliably transform these assets without needing external tools.

AEM Assets and the generation of (default) renditions already supports a wide range of file types. However, the "Asset Compute microservice extensibility" is fairly limited in the filetypes it can process. There currently is no way we and Adobe Support found to support mentioned filetypes (ai, psd, ...).
There is no way of reliably accessing the generated (default) renditions which then could be used as a baseline for the actual conversion from within the microservice, as they are not generated at the time of invocation microservice 

Technical details/background:

• The "recommended" library "JIMP" which is referenced in the demo project is super limited in the filetypes it can support (currently only jpeg, png, bmp, tiff, gif)
• Using other image conversion libraries wasn't successful either, as they always rely on binaries (like imagemagick) which don't work on the ARM64 containers the microservice runs on
• As mentioned previously, trying to access the default renditions and using them as a baseline for the conversion doesn't work either, as they are not generated/available at the time of the invocation of the microservice

In summary: Asset Compute microservice currently only works for a very limited set of filetypes.

Three possible solutions (either would solve the problem):

1. Allow default renditions or custom defined renditions to be passed into workers instead of only the original Asset binary

2. Invoke custom workers only after default renditions exist (opt-in, via processing profile checkbox), so the worker can fetch and transform them.

3. Allow non ARM64 containers and installation of custom binaries like imagemagick for the Asset Compute microservice