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?
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
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
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
@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.
Views
Replies
Total Likes
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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
Views
Replies
Total Likes
Views
Likes
Replies