Responsive Imaging and Dynamic Media done Right — Part II

8 min readDec 23, 2023

Dynamic Media

Today’s websites are experienced on a multitude of different devices. Not only do screens vary in sizes, but they also vary in resolution, orientation, and aspect ratio.

Having different devices requires us to provide images in different resolutions and formats. HTML5 gives some clues how this can be achieved. But the standard is quite complex and it’s easy to make errors. Also, HTML5 is a bit static, and it does not fully exploit advanced rendering features you can use when you have AEM Dynamic Media.

This is Part II of a four-part series. The series is divided as follows:

Part I: What is Responsive Imaging? Why we need it and what use cases it has.
Part II: How can we use AEM Dynamic Media, to increase page loading performance? (This article)
Part III: How can we implement Dynamic Media with HTML 5?
Part IV: Beyond HTML 5: Shrinking the page load time with a custom image loader.

Rendering Binary and Rendering HTML

In Part I we learned the basic use cases for responsive imaging. Now, let’s find out how this can be implemented on our website. There are two sides to an implementation:

1) Creating the image binary (scaled and properly cropped). This can be done with AEM Dynamic Media.

2) Rendering the HTML markup to let the browser choose the proper image in the current context. This usually is a custom implementation, e.g. in an AEM component.

Avoid Browser-Side Cropping and Scaling

Some of these use cases can be implemented in the browser. This is not advised, though: To transform an image in the browser, you still need to transfer the full-size image. Even though the images might look good, the performance — and thus the overall user experience will suffer.

Using Dynamic Media

Providing the image renditions is quite simple. Unfortunately, both the documentation and the UI are somewhat obscure and neither the Core Image Component nor the Dynamic Media Image Component cover all use cases described above.

Also, I find the AEM terminology a bit confusing. We have

Processing Profiles
Image Modifiers
Image Presets
Image Profiles

These all describe similar concepts but implement them differently. Let me break it down:

Processing Profiles are part of AEM as a Cloud Service (AEMaaCS). You can configure pre-defined rendition sizes. AEM scales down the original image when uploading. These are materialized renditions that are physically stored in the DAM. This has nothing to do with Dynamic Media or Smart Cropping, so we’ll not regard this any further.

In contrast to AEMaaCS’ materialized renditions, Dynamic Media creates virtual, non-materialized renditions. It only stores parameters. The renditions are created when the image is requested. Dynamic Media uses the following terminology:

Image Modifiers can be applied to a URL as query parameters to transform an image. For example, you can add the parameters wid, hei and qlt to scale an image to desired dimensions (width and height) and compress it with a certain quality (qlt) on-the-fly:

https://techsupporteu.scene7.com/is/image/AEMEMEAPractice/AdobeStock_178854618?wid=600&hei=300&qlt=90

Image Presets: The Dynamic Media Image Serving and Rendering API [2] provides about eighty different modifiers. You can combine them into Image Presets so that you do not have to append them to each URL. For example, if you have defined an Image Preset “teaser-large” that defines wid=400,hei=400,qlt=90 you can refer to this in a URL like so:

https://techsupporteu.scene7.com/is/image/AEMEMEAPractice/AdobeStock_178854618?$teaser-large$

Image Profiles are used by Dynamic Media to define cropping profiles. E.g., if you have defined a cropping profile named “3by2” it can be referred to “:3by2”

https://techsupporteu.scene7.com/is/image/AEMEMEAPractice/AdobeStock_178854618:3by2

Note, how the profile name is appended after the filename with a colon “:”. It is not a query parameter. Note also, that Dynamic Media does not use file extensions (no .png or .jpg).

Combining Transformations

Modifiers, Presets and Profiles usually are combined:

https://techsupporteu.scene7.com/is/image/AEMEMEAPractice/AdobeStock_636568731:2by1?wid=768&hei=384&qlt=90

This applies the 2by1 cropping profile first and then scale it to 768 by 384 pixels and compresses it with 90% quality.

The most common use case is to use a smart cropping profile to select the motif and image modifiers to scale down to the desired size.

Combining smart cropping via image profile and scaling via image modifier (Source: MS Digital — Adobe Stock)

Performance

Using modifiers and presets yields the same performance results.

You might think that creating a preset first would be faster as this would give Dynamic Media the chance to pre-generate the images. This is not the case, however. Both variations create the renditions on-the-fly and cache transparently. And don’t worry: Dynamic Media is incredibly fast — even when generating fresh and uncached renditions.

Personally, I prefer using modifiers as query parameters explicitly. This approach eases debugging and tinkering.

Note: I do not encourage to let page editors provide these parameters. Instead, these parameters usually come from a central, configurable custom service that is responsible to render images for all components. I prefer writing out the parameters in the HTML markup simply for transparency.

Smart Cropping

We have covered scaling. What about Smart Cropping? Smart Cropping requires a bit more processing and thus needs to be done up-front. I.e., smart cropping cannot be rendered on-the-fly.

Also, you might want to manually adjust the cropping region on a few assets. Here we must be able to refer to a cropping by name to let AEM know what cropping we want to adjust:

Referring profiles by name in manual adjustments

Naming Cropping Profiles

It is a good practice, to name profiles consistently. There are multiple ways for naming schemas.

a) Name profiles by aspect ratio:

1by1
3by1
3by2
2by1
…

b) Name profiles by component or component and breakpoint

hero
teaser-1400
teaser-900
teaser-600
textimage-1400
textimage-900
textimage-600
…

Using a common naming schema not only helps identifying the profiles in the UI it also helps automatically generating URLs to the renditions as we’ll see later.

Personally, I prefer the aspect ratio style. Most likely, it results in a significant smaller number of potential profiles — especially in a well-designed style guide, that explicitly specifies a small number of ratios up front.

You’ll probably re-use the 1:1 ratio in more than one component… so why define it twice?

Why indeed? There is one edge case:

Remember, from the use-cases section we had two cases for cropping:

Cropping to adapt another aspect ratio.
Keep the aspect ratio but zoom in on details.

Same aspect ratio, different cropping (Source: Alexander Raths — Adobe Stock)

If we only have one profile named “1by1” we would have to choose whether we want the version where we reduce the offcut or if we wanted to detail.

Luckily, we can have as many profiles as we want. The solution is simple: Add a “-detail” profile variation:

1by1
1by1-detail
3by1
3by2
…

Whatever naming schema you use: Just make sure it is descriptive and consistent.

Note: “Small”, “Medium”, “Large” are bad names for crop renditions. They neither convey their aspect ratio nor use case. And a “Small” hero might still be bigger, than a “Large” teaser.

How to define crop renditions

Please refer to [3] on how to use the UI in AEM. Here, I’d rather want to point out a few things that will help you understand what you are doing.

When setting up the image profile you’ll be asked if you want to “Preserve crop content across all target resolutions”:

I struggled quite a bit to understand what that means. And the help text did not really help. So, what is this about? The reference [4] might be a bit more insightful for you. But let me try to explain this in my own words.

Smart Cropping has two “modes”:

a) Preserve content — reduce offcut (checkbox is checked)
b) Preserve details — avoid down sampling (checkbox is not checked)

Mode a) tries to cover as much content as possible. The resulting can then be scaled to any size, e.g. to 900x900 pixels.

Mode b) tries to find the most meaningful contents that fit into a 900 x 900 pixels frame.

In most cases, “Preserve Content” will be the better choice. The results are predictable and consistent.

Warning:

You might have realized that I configured the aspect ratio as 300x100, 300x200, 200x100, … though I am referring to the profile as “3by1”, “3by2”, “2by1”. Now, if I am scaling dynamically with image modifiers after cropping anyway, why not configure the aspect ratio as 3x1, 3x2, 2x1, etc. already?

And you are right: In theory, that would yield the same result. In practice, however Dynamic Media fails when using small numbers. In CRXDE, you would find “Division by Zero” errors under the failed renditions node of the assets. The 3-digit numbers are a safety measure against this quirk.

“Preserve Details” has the drawback that the results depend on the resolution of the original material. It always tries to “stamp-out” a frame with fixed dimensions (e.g., 900 x 900 in our example.). If the size of the uploaded material varies, so does the cutout:

Unpredictable cropping results on varying input resolutions.

In practice this setting is not particularly useful. I prefer the “Preserve Content” mode with additional scaling.

Changing Image Profiles

Modifiers are applied to an image on-the-fly. You can alter image URLs by adding new parameters. You don’t need to configure them first.

Cropping Profiles however are processed when an image is uploaded. That means, when you add a cropping profile at a later point in time, you must re-process all assets that already have been uploaded. If you have thousands of assets this can take quite some time. So, it is a good idea to plan the required formats ahead (i.e., in the style guide) and not make this an afterthought.