This module is based on the idea that if someone sets the width and height attributes on an image to (for example) 100px and 150px, the image should be resized to 100px by 150px so that it's no bigger than necessary.

By contrast, retina image techniques (such as in the modules https://www.drupal.org/project/retina_images and https://www.drupal.org/project/hires_images) are based on the idea that if the width and height attributes on an image are set to 100px and 150px, the actual underlying image should be sized twice as big in all directions (200px by 300px).

Those two ideas are incompatible, and therefore this module doesn't work with retina images.

It would be useful if it could, so that sites can take advantage of this module's ability to size down gigantic images when they are resized in a WYSIWYG, but still display the images using retina techniques. So for example, if someone resizes a large image to 100px by 150px in the WYSIWYG, this module should be smart enough to make the image itself be 200px by 300px.

Patch coming up.

CommentFileSizeAuthor
#13 multiplier_and_quality-2346923-13.patch4.77 KBanrikun
#12 image_resize_filter-multiplier-and-quality-2346923-12.patch4.75 KBanrikun
#9 image_resize_filter-multiplier-and-quality-2346923-9.interdiff.patch1.34 KBjoelstein
#9 image_resize_filter-multiplier-and-quality-2346923-9.patch4.75 KBjoelstein
#8 image_resize_filter-multiplier-and-quality-2346923-8.patch4.74 KBjoelstein
#1 image-resize-filter-retinafy-2346923-1.patch3.82 KBDavid_Rothstein

Comments

David_Rothstein’s picture

David_Rothstein commented
Status: Active » Needs review
StatusFileSize
new image-resize-filter-retinafy-2346923-1.patch3.82 KB

Here is the patch. It's a bit rough, but so far seems to work in my testing.

Note that testing this patch with https://www.drupal.org/project/hires_images it will not work if the image is being displayed using an image style that has the retinafication effect provided by that module applied. I could not find a way to make that seamlessly work. So instead, this is basically a substitute for trying to use a module like that on embedded WYSIWYG images, rather than something that will work with it.

joelstein’s picture

joelstein commented
Status: Needs review » Reviewed & tested by the community

Works great! Thanks for putting this together, this was exactly what I needed.

quicksketch’s picture

quicksketch
he/him
commented

I'm adding a co-maintainer to this module who hopefully will be able to review this patch and get it in. My only feedback on this issue is that I would like to avoid Apple marketing-speak "retina" from being in our code base. Using it as a description text or label is fine, but underying I'd prefer to see this option stored as "hidpi", "hires", or something like "scale_multiplier" (defaulting to 2.0).

ram4nd’s picture

ram4nd commented
Status: Reviewed & tested by the community » Needs work

Agreed, also I don't think that "$image_jpeg_quality / 3;" the quality should be that low.

joelstein’s picture

joelstein commented

Actually, when scaling an image down for hi-res displays, a low quality has virtually no visual consequence (it still looks sharp) while drastically reducing file size.

This is explained very well in the PDF at http://retinafy.me/.

However, instead of hard-coding it, perhaps the quality should be a configurable option in the text format?

ram4nd’s picture

ram4nd commented

It looks good, scaled down, but there is no reason to scale it in first place? As "retina" display shows it with lesser quality. I would like to get third opinion here.

David_Rothstein’s picture

David_Rothstein commented

Wow, I had no idea "retina" was Apple marketing-speak even. How insidious :)

I would say it doesn't necessarily make sense to keep that word in the user interface either; it's not like it suggests any particular meaning to people who don't already know what it is. The checkbox could say something like "Optimize images for high-pixel-density displays" instead...

@ram4nd, since with this technique the image has 4 times as many pixels as it otherwise would, the goal is to keep the file size manageable (i.e. similar to what it would normally be, rather than ~4 times as large). The project page of https://www.drupal.org/project/hires_images is another place that has some more information about this.

joelstein’s picture

joelstein commented
Status: Needs work » Needs review
StatusFileSize
new image_resize_filter-multiplier-and-quality-2346923-8.patch4.74 KB

Here's another take at this, which removes the "retina" language (and checkbox setting), and exposes two fields to configure the "multiplier" and "quality".

The multiplier field defaults to 1x, and uses the same options as the Breakpoints module.

The quality field lets them change the image quality used to resize the image. If left empty, it will use Drupal's default image quality setting. So site builders can tweak this until they find a setting they like. It also has the positive consequence of giving users the ability to set a quality different than that of Drupal's default setting, even if no multiplier is used.

I tested with different setting configurations, and it all works. (When you test make sure you delete the resized image from the file system, clear the page cache to generate the new image, and refresh your browser to make sure you are getting the new image.)

joelstein’s picture

joelstein commented
Version: 7.x-1.x-dev » 7.x-1.16
StatusFileSize
new image_resize_filter-multiplier-and-quality-2346923-9.patch4.75 KB
new image_resize_filter-multiplier-and-quality-2346923-9.interdiff.patch1.34 KB

Here's an updated patch which fixes an issue where images could be upscaled, and also tweaks the doc (see the interdiff).

adam1’s picture

adam1 commented

I patched version 7.x-1.16 with patch https://www.drupal.org/files/issues/image_resize_filter-multiplier-and-q... but I got following error:

patching file image_resize_filter.module
Hunk #1 succeeded at 49 (offset -3 lines).
Hunk #2 succeeded at 65 (offset -4 lines).
Hunk #3 succeeded at 170 (offset -4 lines).
Hunk #4 succeeded at 427 (offset -4 lines).
Hunk #5 succeeded at 479 (offset -6 lines).
Hunk #6 FAILED at 553.

Can someone tell me, what's going wrong there?

anrikun’s picture

anrikun commented
Version: 7.x-1.16 » 7.x-1.x-dev

This applies to 7.x-1.x-dev, not 7.x-1.16.

anrikun’s picture

anrikun commented
StatusFileSize
new image_resize_filter-multiplier-and-quality-2346923-12.patch4.75 KB

I guess when quality is set, image should be processed no matter what size it has.

EDIT: wrong patch! Please review the one at #13 instead.

anrikun’s picture

anrikun commented
StatusFileSize
new multiplier_and_quality-2346923-13.patch4.77 KB

Oops, forget about the previous patch.
Here is the right one.

quicksketch’s picture

quicksketch
he/him
commented

Browser technology has improved a bit since this was last visited. I think we should rework this patch to use srcset instead of only generating a single image size. And instead of making a select list, we should provide checkboxes so that multiple sizes can be selected. Image resize filter should use the 1x multiplier for the normal src attribute, with srcset providing larger multiplier versions. 1x, 1.5x, and 2x variations should all be generated by default.

We could also generate smaller variations (e.g. .5x) Not sure about that usefulness though, could still be handy for mobile, but as mobile can be 2x or greater resolution, and the images are already resized down, seems the .5x use-case might be fairly limited and just be unnecessary extra image processing.

A little more info on srcset: https://css-tricks.com/responsive-images-youre-just-changing-resolutions...