In AEM 6.5 does assets transforms have the capability...

[AEMnewbie]

In AEM 6.5 does assets transform have the capability to take aspect ratio into consideration..Currently we use web renditions which supports that. Is there a simple workaround for it to consider aspect ratio while transforming images?

[Jörg_Hoh · Accepted solution]

what do you mean with "asset transform"? Do you mean the creation of asset renditions (with smaller dimensions)?

Ok, I think I got the case: Because you are unflexible when it comes to renditions (adding a new rendition definition requires to reprocess all assets, which do not have this rendition yet) makes you thinking about creating these renditions on the fly.

Basically that's not a problem (maybe a small extension of the NamedImageTransformerServlet would be necessary to preserve the aspect ratio, I am not sure if it already has that feature), but of course it's not free. Because now you create the rendition more often (on every uncached request), which can lead to performance problems in case of an empty dispatcher cache.

That pre-rendering of these renditions is one side of a trade-off (spending disk, saving CPU), the on-demand rendering the other side (saving disk, spending CPU). Maybe you can find a way in between: If a rendition is already present, use it; if it's not, create it on-the-fly (with or without persisting it in the repo, your choice).

Jörg

[AEMnewbie]

@Jörg_Hoh , for our current flow whenever we upload a new assets , it triggers the DAM Update asset workflow which eventually create the web renditions of specified dimension .. And the web rendition has a note in it which says (Defines a template for a standard DAM web enabled rendition from a given rendition. The aspect ratio of the assets base image will be preserved. Depending on orientation, either width or height of the target size will be smaller.) Offlate we have started adding new dimensions for those renditions.. and everytime a new renditions is requested we end up fixing all the existing ones with this new renditions. So we were looking at other options and we came across the NamedImageTransformServlet , but using this we observed that this is not preserving the aspect ratio.

[Jörg_Hoh]

Sorry, I don't get it fully. I understand that you have the standard Update Asset workflow adapted to create renditions according to your needs, and it works well. And now you changed the configuration to have more renditions, and ... why do you need to fix the existing renditions? Have you manually updated the existing rendition assets with handcrafted ones (which are then overwritten, when you rerun the Update Assets on the original asset again)? Would be great if you could help me to understand that better.

[AEMnewbie]

Jörg_Hoh .. No Let me give you an example -- Lets say we currently had 2 image asset with rendition 400*400 and 850*850. Few more assets were added later and a new renditions were requested for all the existing assets.. So before we added the new assets we update the workflow to generate 3 renditions(400*400 ,850*850,1024*1024) .. When the new assets are added we get 3 different renditions ..But the old assets still have 2 kinds of renditions.So we have are currently fixing the 1 set of assets by running a workflow manager so that all the assets end up having are 3 renditions type.. We are looking for an option just like NamedImageTransformServlet ( But it should also take the aspect ratio into consideration) So its more dynamic and the repository consumes less space

[Jörg_Hoh]

Ok, I think I got the case: Because you are unflexible when it comes to renditions (adding a new rendition definition requires to reprocess all assets, which do not have this rendition yet) makes you thinking about creating these renditions on the fly.

Basically that's not a problem (maybe a small extension of the NamedImageTransformerServlet would be necessary to preserve the aspect ratio, I am not sure if it already has that feature), but of course it's not free. Because now you create the rendition more often (on every uncached request), which can lead to performance problems in case of an empty dispatcher cache.

That pre-rendering of these renditions is one side of a trade-off (spending disk, saving CPU), the on-demand rendering the other side (saving disk, spending CPU). Maybe you can find a way in between: If a rendition is already present, use it; if it's not, create it on-the-fly (with or without persisting it in the repo, your choice).

Jörg