Provide OOTB Renditions to Asset Compute microservice extensibility - Status changed to: Investigating

[#1]

Request for Feature Enhancement (RFE) Summary:	Provide a way for the "Asset Compute microservice extensibility"/Asset Compute workers to access the default renditions for an Asset so the custom worker can use those as a baseline for further conversions. 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
Use-case:	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.
Current/Experienced Behavior:	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.
Improved/Expected Behavior:	Three possible solutions (either would solve the problem): Allow default renditions or custom defined renditions to be passed into workers instead of only the original Asset binary Invoke custom workers only after default renditions exist (opt-in, via processing profile checkbox), so the worker can fetch and transform them. Allow non ARM64 containers and installation of custom binaries like imagemagick for the Asset Compute microservice
Environment Details (AEM version/service pack, any other specifics if applicable):	AEM as a Cloud Service (2025.8) with Asset Compute microservice running on Adobe AppBuilder/Runtime)
Customer-name/Organization name:	(private), see support case E-001769596 for customer specific details
Screenshot (if applicable):	N/A
Code package (if applicable):	N/A

[#2]

@webera Thanks for proposing this idea. This has been reported to the engineering under the internal reference ASSETS-56546. The product team will triage this request to verify feasibility based on the prioritization model. This post will be updated according to Jira's status.