Custom Image Rendition servlet vs DAM Update Assets workflow Renditons

[avinasht7298469]

In AEM ,I have seen project where we have used custom image rendition servlet (Generating rendition on fly) or DAM update Asset workflow.

If we are using custom image rendition servlet ,It has certain benefits(Named Transform Image Servlet ).

1. can create new image rendition on the fly based upon configuration .

2. Save space in AEM .

3. Also performance vice ,the image are cached in dispatcher for both author and publisher ,so only rendition creation only for the first time.

Limitation

1.New image rendition need to created if cache is cleared.

if we are using DAM update Asset workflow, It has certain limitation.and benefits.

Limitation

1. whenever author upload image this workflow trigger new rendition are created for every image and at at time we dont need all rendition.

2 if we are migrating large asset ,it is again bottleneck.

3. take additional space in author and publisher as well for all images

Benefits

1. new image rendition is not created every time but just once .

Question:

If I evaluate from above reasoning i believe that image rendition servlet is more useful in term of saving space and load on author and publish server .

Is the above approach  is recommendation/best practice from adobe or if someone have completely different perspective.

[rocks]

Let's discuss two approaches:

1. Create Image on the fly: Works only if the Image is saved as a resource pointed to foundation/image component. Use html5smart image widget to save the image as a resource. URL will be pointed to the page jcrcontent.
   • Pros:
     • An image on the fly.
     • Saves space on author, publish servers
     • Can create image to fit into any container without creating new images from Visual Designer
     • An image is saved as a resource in the content node so you do some manipulation like rendering grayscale, rotate.
   • Cons:
     • Crops the image if width or height are not proper.
     • Throws error if image is deactivated but still code refers to the NamedServlet URL
     • Animated GIFs loses its animation.
     • Lose image quality some.
     • An image has to be saved as a resource in the content node then only you can create Images on the fly by specifying the width, height, and quality.
2. Rendition Based: Works for any images in the DAM. URL will be either actual rendition or gives back original image
   • Pros:
     • Renditions are specified based on the containers in the site and created as soon as image is uploaded by the author
     • Renditions are readily available for the author to view how it looks for smaller dimensions.
     • Work great on portrait and landscape images.
   • Cons:
     • Takes space, even though for few image, renditions specified in the DAM Update Asset workflow are not needed.
     • Need to re-run DAM Update Asset workflow if new rendition is needed

[avinasht7298469]

I have few comment for cons on Create image on the fly and pros of workflow

• Crops the image if width or height are not proper: agreed but you can specify to maintain the image aspect ratio and even in the workflow rendition if you define custom rendition you might face the same problem
• Throws error if image is deactivated but still code refers to the NamedServlet URL : if we are storing file reference then i hope its not an issue and its the same case as image component
• Animated GIFs loses its animation: This is the same case with rendition from Adobe workflow
• Lose image quality some: If we use the same API as workflow i hope the quality should be the same
• An image has to be saved as a resource in the content node then only you can create Images on the fly by specifying the width, height, and quality. : If user is not cropping or making change in the image then you can just use the file reference otherwise store the image as resource which is valid for normal image component as well

Pros:

• Renditions are specified based on the containers in the site and created as soon as image is uploaded by the author :This implementation is component specific rather than workflow
• Renditions are readily available for the author to view how it looks for smaller dimensions:It would be same in case for rendition as well
• Work great on portrait and landscape images: I dont understand how it differ in both the scenario.

The question that i have in mind is how creating image on fly vs dam renditon has performance impact when we create image on the fly for first time because then and only then we are creating the image (generally this is overcome once you do smoke testing)

[rocks · Accepted solution]

Performance wise:

1. An Image on the Fly:
   • If there are multiple images on a page and all are images on the fly these request hitting the publisher will certainly have an impact. Each request gets the response from the Servlet and its cached in the dispatcher for the subsequent request.
   • If the same image is used in multiple pages, each page may have it own image URL.
   • For any image update: Clearing those image you may have to activate the parent node(either the dam asset or page)
   • Doesn't consume space in the publisher
2. Renditions Based:
   • The renditions are a readily available resource in the publisher in the DAM and can be served much faster if the same scenario is applied.
   • One Image will have the same URL for all the pages referenced on the site.
   • For any image update: Author can update one rendition or update an original image in the DAM and clears the dispatcher respectively
   • Consumes spaces in the publisher.

You can create a sample page with two different implementations and check the load time of the page for the first time and subsequent times to record the performance metrics. Take decisions based on it.

I could say it depends on the requirement.

If showing images in the multimedia section like displaying photos in an album rendition is better.

If displaying smaller thumbnails rendition size which is not going to be used anywhere on the site you can use adaptive image/named transform image. Instead of having that thumbnails rendition size to be stored by the author and publish's DAM.