Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publication preview image not enlarged on click #2668

Open
2 tasks done
WYF99 opened this issue Aug 28, 2024 · 1 comment
Open
2 tasks done

Publication preview image not enlarged on click #2668

WYF99 opened this issue Aug 28, 2024 · 1 comment

Comments

@WYF99
Copy link

WYF99 commented Aug 28, 2024

Have you checked that your issue isn't already filed?

  • I read through FAQ and searched through the past issues, none of which addressed my issue.
  • Yes, I have checked that this issue isn't already filed.

Bug description

Publication preview thumbnails are not enlarged and displayed at original size upon mouse click

How to reproduce the bug

  1. Go to any publication entry with a preview image which originally is of larger size than the thumbnail (e.g., any image from my personal site).
  2. Click on the thumbnail to zoom in.
  3. The image is centered but still displayed at the same small (and unreadable) size.

Error messages and logs

No error message.

What operating system are you using?

Not applicable (e.g. you're using GitHub Pages or other hosting)

Where are you seeing the problem on?

Deployed site

More info

A publication thumbnail is displayed at a reduced size by default, which is supposed to be centered, enlarged, and displayed at its original size upon click. In reality, the thumbnail is simply centered without any size change.

According to @george-gca from #2662

imagemagick creates a reduced version of those images, since they are displayed in this location at a really small size, and simply doesn't use the original version.

@jcblum
Copy link

jcblum commented Sep 5, 2024

I was struggling with the same thing, so I dug into it. I think this is not technically a bug, but instead the interaction of non-obvious expected behavior from two different plugins:

  1. jekyll-imagemagick only scales images down (not up)
  2. medium-zoom calculates the zoomed size based on what's in sizes, not the source image's actual dimensions

jekyll-imagemagick only scales images down (not up)

All the details are in here…

It turns out that small original images aren't being resized at all, because jekyll-imagemagick is hard-coded to request that Image Magick shrink images, not enlarge them. This is a big part of why the tiny gif preview images in the example site content don't enlarge.

In the jekyll-imagemagick source, the line that constructs the Image Magick -resize command is:

cmd += "-resize "#{long_edge}>" #{resize_flags} "

You can also see this by examining what jekyll-imagemagick prints to the Jekyll logs, which looks like:

Imagemagick: Running command "convert "/path/to/assets/img/1.jpg" -quality 85 -resize "1400>" "/path/to/_site/assets/img/1-1400.webp""

The > in the geometry "shrinks an image with dimension(s) larger than the corresponding width and/or height argument(s)" (source).

…but the TL;DR is: images that start out with a width smaller than what's requested in site.imagemagick.widths will be output without any resizing, no matter what their file names claim.

If you inspect the responsive images created by jekyll-imagemagick for the example site content, images that are supposed to be 1400px wide are still 800px wide, since the originals are all 800px wide. This means the default srcset is also mis-specified, since width descriptors are supposed to match the actual image widths.

What to do about it?

Most immediately, perhaps the documentation of this feature in al-folio and the example content could clarify for users what to expect? Namely:

  • Images will only be down-scaled (never up-scaled)
  • The largest size in site.imagemagick.widths should be smaller than your smallest image width, otherwise you will be needlessly generating (and incorrectly plugging into srcset) duplicate images with unchanged size.

People who are up for customizing might want to look into the other responsive image plugins out there, some of which offer more flexibility.

So for @WYF99, the upper limit on the zoomed thumbnail size will be 480px wide, even though there are images in the srcset that claim to be 800px and 1400px (they aren't – they're all 480px, too). But that doesn't solve the tiny zoom problem, since the zoomed previews often aren't even making it to 480px wide. That's because…

medium-zoom calculates the zoomed size based on what's in sizes, not the source image's actual dimensions

On @WYF99 's page, the thumbnails have been given sizes="200px". The thumbnails actually render at 70px–125px width (depending on viewport size) for the larger Bootstrap breakpoints.

Taking the viewport >1200px case as an example, the concrete size of the thumbnails is 125px wide, while the physical width of the source image is 480px. But instead of the zoom scaling factor being calculated as 480 / 125, it's being calculated as 200 / 125, resulting in a too-small zoomed image.

The gory details are in here…

medium-zoom uses CSS animation to create the zoom effect. It finds the ratio between the intrinsic size of the image and the concrete size of the image as rendered on the page and then calculates a scaling factor to pass into transform: scale (basically — there are a few more twists to the algorithm, code here).

The problem is that for images with a srcset, the intrinsic dimensions (naturalHeight and naturalWidth) are adjusted based on the sizes attribute, or the default "100vw" that's assumed if sizes is missing.

You can check what scaling factor is being applied by bringing up the Javascript console, clicking on a thumbnail, and entering this at the console prompt:

> document.body.getElementsByClassName('medium-zoom-image--opened')[0].style.transform
'scale(1.59289) translate3d(243.269px, -108.779px, 0px)'

The transform is using a scale of ~1.6, causing that dinky zoom. To understand where that scale number came from, enter this at the console prompt (while the zoom is still displayed!):

> document.body.getElementsByClassName('medium-zoom-image--hidden')[0].naturalWidth
200

The intrinsic width of the thumbnail image is being reported as 200px instead of 480px, thanks to sizes, resulting in the scaling factor being calculated as 200 / 125.

If you read this far, you might also be interested in this code pen I made demonstrating how sizes affects intrinsic dimensions.

What to do about it?

  • Try to be much more granular with the sizes specification (but this is non-trivial and maybe even sub-optimal).

  • Use medium-zoom's data-zoom-src attribute to explicitly point to a larger image to use for the zoomed view. You can specify it like:

    <img src="/assets/img/1.jpg" 
         srcset="/assets/img/1-480.webp 480w, 
                 /assets/img/1-800.webp 800w" 
         sizes="95vw" 
         data-zoomable 
         data-zoom-src="/assets/img/1-800.webp">

    I think this could be incorporated into figure.liquid, perhaps even with some logic for picking which image size you want assigned as the zoomed source.

The second approach is probably easier, since highly granular sizes specs get really verbose and painful to generate, and what you need to get desirable zoom scales might trade off against what you need to optimize page loading speed. Also, you'd still be leaving the browser in charge of picking exactly which size image is used for the zoomed view, which can result in visibly inconsistent behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants