I've set up a website using the Quarto blog template, which includes a list of several posts and thumbnails for each of the posts. By default the thumbnails are taken from the first image included the post, if there is no image: specified in the YAML-like section at the start of the post's .qmd file. This works great, but many of the images I use in are very high definition (thousands of px across) – this is what I want in the posts themselves, but means that even on fast internet the website's homepage can take a while to load all the images.
Is there any automatic way to resize each of the thumbnail images so they're at most a few hundred px across?
If there isn't already a simple way to do this, I could write a script that found the thumbnail image for each post, created a resized version, saved it to the directory for the post, then specified that thumbnail as the image: for the post – I think I could get that to run using the pre-render: project option. But thought it worth checking there isn't already an easier way to achieve the same thing!
This question is a little vague. Sorry I do not have more details. I did an exam a few days ago that involved containers. One question was about optimizing an existing docker file, creating the image and pushing it to docker hub. The docker file included EXPOSE, CMD, LABEL, FROM RUN, ADD instructions.
One of the characteristics of the image was that one should be able to use it as base/parent image for creating other images.
I can't believe this mention was added for no reason. Yet I am not able to understand why this characteristic had to be listed. Is there something specific that one needs to add in docker files for base images? Or are base images stored differently in the registry?
What makes a base docker image different than a normal runnable image?
There is nothing special that you need to do for an image to be reusable. All images can be used in the FROM clause and thus used as base images. The OS needs to match the commands in the file, of course. Also images are made of layers and layers are usually reused between images.
If I would have to look hard for a reason why that was specified as a requirement, I would say that they wanted you to pay attention to:
the size of the final image (make it as small as possible)
documentation (make it easy for others to understand what your image already does)
I'm looking for a visual tool that would take a Docker image and be able to show (in some kind of a chart) what makes the image e.g. 1,2GB large.
In addition to what disk tools would do, it would also tell me which Docker overlay brought that file in.
Is there such a tool or shall I dream on?
Dive does it.
Mentioned here.
We are trying to increase the page score (google) for our website. One of the options to do this is "Image optimization".
As we have a huge number of images in the DAM, how can we compress/optimize them? Does AEM have any such tool to achieve this?
ImageMagick is one of the tool to achieve this. Do we need to integrate that with AEM or we'll have to re-upload all the images after compressing them using the tool?
Any suggestions?
In contrast to CSS, JS and HTML files which can be gzipped using dispatcher, images can be compressed only by reducing quality or resizing them.
It is a quite common case for AEM projects and there are a couple of options to do that, some of them are coming out-of-the-box and do not even require programming:
You can extend DAM Update Asset with CreateWebEnabledImageProcess Workflow Process Step. It allows you to generate new image rendition with parameters like size, quality, mime-type. Depending on workflow launcher configuration, this rendition can be generated during creation or modification of assets. You can also trigger the workflow to be run on chosen or all assets.
In case that CreateWebEnabledImageProcess configuration is not sufficient for your requirements, you can implement your own Workflow Process Step and generate proper rendition programmatically, using for example ImageHelper or some Java framework for images transformation. That might be also needed if you want to generate the compressed images on the fly, for example, instead of generating rendition for each uploaded image, you can implement servlet attached to proper selectors and image extensions (i.e. imageName.mobile.png) which return the compressed image.
Eventually, integration with ImageMagick is possible, Adobe documentation describes how it can be achieved using CommandLineProcess Workflow Process Step. However, you need to be aware of security vulnerabilities related to this mentioned in the documentation.
It is also worth to mention that if your client needs more advanced solutions for images transformation in the future, then integration with Dynamic Media can also be considered as a possibility, however, this is the most costly solution.
There are many ways to optimise Images in AEM. Here I will go through 3 of those ways.
1) Using DAM Update Asset Workflow.
This is an out of the box workflow in AEM, Where on upload of images renditions get created . You can use those renditions path in img src attribute.
2) Using ACS commons Image transformer
Install ACS commons Package , Use Image transformer Servlet config to generate optimised or transformed images acc to requirement. For more Info on this check ACS AEM commons.
3) Using Google PageSpeed in dispatcher level
If you want to reduce the size of image, Google PageSpeed is an option to consider. Install PageSpeed in dispatcher level and add image optimise rules to achieve your requirement.
This rule Insights detects the images on the page that can be optimized to reduce their filesize without significantly impacting their visual quality.
for more info check here Optimising Images
AEM offers options for "image optimisation" but this is a broad topic so there is no "magic" switch you can turn to "optimise" your images. It all boils down to the amount of kilo- or megabytes that are transferred from AEM to the users browser.
The size of an asset is influenced by two things:
Asset dimension (width and height).
Compression.
The biggest gains can be achieved by simply reducing the assets dimensions. AEM does that already. If you have a look at your assets renditions you will notice that there is not just the so called original rendition but several other renditions with different dimensions.
MyImage.jpg
└── jcr:content
└── renditions/
├── cq5dam.thumbnail.140.100.png
├── cq5dam.thumbnail.319.319.png
├── cq5dam.thumbnail.48.48.png
└── original
The numbers in the renditions name are the width and height of the rendition. So there is a version of MyImage.jpg that has a width of 140px and a height of 100px and so on.
This is all done by the DAM Update Asset workflow when the image is uploaded and can be modified to generate more renditions with different dimensions.
But generating images with different dimensions is only half of the story. AEM has to select the rendition with the right dimension at the right moment. This is commonly referred to as "responsive images". The AEM image component does not support "responsive" images out of the box and there are several ways to implement this feature.
The gist of it is that your image component has to contain a list of URLs for different sized renditions. When the page is rendered client side JavaScript determines which rendition is the best for current screen size and adds the URL to the img tags src attribute.
I would recommend that you have a look at the fairly new AEM Core components which are not included with AEM. Those core components contain an image component that supports responsive images. You can read more about those here:
AEM Core Components Image Component (GitHub)
AEM Core Components Documentation
Usually, components like that will not use "static" renditions that were already generated by the DAM Update Asset workflow but will rely on a Adaptive Image Servlet. This servlet basically gets the asset path and the target width and will return the asset in the requested width. To avoid doing this over and over you should allow the Dispatcher to cache the resulting image.
Those are just the basic things you can do. There are a lot of other things that can be done but all of them with less and less gains in terms of "optimisation".
I had the same need, and I looked at ImageMagick too and researched various options. Ultimately I customized the workflows that we use to create our image renditions to integrate with another tool. I modified them to use the Kraken.io API to automatically send the rendition images AEM produced to Kraken where they would be fully web-optimized (using the default Kraken settings). I used their Java integration library to get the basic code for this integration. So eventually I ended up with properly web-optimized images for all the generated renditions (and the same could be done to the original) that were automatically optimized during a workflow without authors having to manually re-upload images. This API usage required a Kraken license.
So I believe the answer is that at this time AEM does not provide a feature to achieve this, and your best bet is to integrate with another tool that does it (custom code).
TinyPng.com was another image optimization service that looked like it would be good for this need and that also had an API.
And for the record, I also submitted this as a feature request to our AEM rep. It seems like a glaring product gap to me, and something I am surprised hasn't been built into the product yet to allow customers to make images fully web-optimized.
Docker has changed it's backend and now the "docker history" command no longer shows layer IDs of all layers in an image. More details here: https://github.com/docker/docker/issues/20131
Although I understand why it's showing "missing", I still havent found a new way to extract the information I'm looking for. Does anyone know how I can find all the layers in an image? I'd like to be able to cross-reference layers over different images so that I know when a certain layer is used by more than once service, which is why I used the ID shown in the history command up until recentely.
Any help is appreciated, thank you.