(dam I use that site several times a week and I never realised it was Joomla - well done)

(Haha! Well, that cheered me up today!)

How does it work with article images?

It doesn't at present work with images in article text, although it works with intro and full-text images.

To make it work with images in article text it needs a content plugin, to search for image tags and create the src links via the data model. A benefit of this is that the plugin could process the image according to the width and height specified in the WYSIWYG editor, to produce an optimised image. We use the scaler component to create responsive images for different DPIs, which could be an additional feature for a plugin.

It doesn't at present work with images in article text, although it works with intro and full-text images.

That is actually what I meant ;)

I can't speak for anyone else but it does sound like a good addition for Joomla 4 to me. Maybe the quickest thing to do to gauge opinion would be to make a small video recording of it in action in the admin?

sounds good to me too, at least on the paper, looking forward to see at some RFC/POC/PR

There's very little to show in the admin, so I'm not sure how much value a video would be. Here's the extent of the admin section.

Options. You may want to handle the existing options differently as the CDN and live domain options are just there to help us with how we arrange things, and it would help to have a default JPEG quality option.

A menu item. This is the SEF end-point for rendered images

And that's it!

This would have to be able to be turned off and I would like to know a LOT more about the technology doing the cropping/resizing. For some sites and some people touching an image in anyway is a quick way to lose a J! user.
For example, only product photography site I would blow a gasket if J! decided I didn't know what I wanted my images to look like.
Unless your developers are EXTREMELY familiar with how images are built internally I doubt they could do anything to my image(s) that wouldn't degrade them. Not bragging, ijs, I've got pro grade tools I run them thru before they ever land in my storage folders.
To the best of my knowledge there is no perfect responsive image handler YET.

Yes, definitely it needs to be able to be turned off. Currently on our projects we include it where we need it, however if it's included in Joomla then the component should have an "off" option which simply returns back the original image url, rather than a url for a processed image. If there is a content plugin as well, to handle in-text images, then that could be turned off separately if required.

We've done a large-scale professional photography site before and this isn't the technique we use for generating images for that. This is a usability enhancement to ensure that images fit with the design, which we find is a habitual problem which users struggle with.

The code we use is very simple and no doubt there's room for improvement. In the model, once the query is validated, we do a scaled centered crop using ImageMagick.

		$imagick = new Imagick(JPATH_ROOT . '/' . $path);
		
		$imagick->cropthumbnailimage($width, $height);
		
		$format = $imagick->getimageformat();
		if ($format == 'JPEG' || $format == 'JPG') {
			$imagick->setimagecompressionquality($this->params->get('jpeg_quality', 70));
			$imagick->stripimage();
		}
		
		$data->img = $imagick->getImageBlob();

The way you build responsive images using this is that you request multiple images in the template code, each one being a separate request. So, you are fully in control of how you map onto screen resolution, screen size or a bit of both.

Wow nice!!!

We typically use a thing like this... https://gist.github.com/simbus82/3eb70128691ab93a6fd420ed6592e99f
but it is really "rude" (it's an old version, the actual used for some our customers generates scrset too.)
Really slow on the first load of page... but then it's good ;-)

I like a lot the Magento 1.9.x Image Processing.
In the frontend you simply call a function "$this->image(original_url)->resize(300,200)" to have a perfect cached resized image without losing the original.

Hi @simbus82 ,
Yes, it's very analogous to the Magento processing.

imagemagick has a great algorithm, although I've heard there are a couple of better ones but they were far above my brain cell capacity lol.
that magento behavior looks exactly like imagemagick's process.
@simbus82 your method sounds alot like retina behavior. I wonder what sites like smugmug use for their compression.

@waveywhite please submit PR for consideration/testing.

Yes. Sorry for the delay. I'll get on to this.

Modified title as this would have to be done for 4.0 (new feature).

I've uploaded the code to https://github.com/waveywhite/com_scaler - is someone able to take it from there? I'm unsure of the proper way to integrate it as a Joomla 4 PR.

A few issues with the code:

1. It's Joomla 3 code and uses the MVC libraries which are being deprecated. However, it is extremely simple and there's no admin section apart from some settings.
2. It uses a "fixed" inflector which can easily be taken out given that there is only one view
3. The options could probably be simplified. It has an option to specify a pull CDN and the live domain of the site, which is when the pull CDN should be applied. Please feel free to remove these
4. Caching needs thought! We use CDNs and Joomla file caching to mitigate server load. I suggest that somewhere is found in the images folder instead, so that the scaled images aren't flushed out with cache pruning.

Hi all. I'm looking at moving over to the Joomla 4 MVC for com_scaler. Is there a good example of best practice for a J4 MVC component? Or are we doing things like com_content does?

I've found https://github.com/ceford/j4xdemos-com-mywalks so I'll base my changes on that.