[Functionality] hiDPI images should use FULL reg-img-size as src for thumb.php

Hello Mr. Bjørn Johansen!

I’d like to point out a small issue i encountered. It’s not really a bug, more like a “desired logical outcome” in my case. (Apologies for the long post!)

Imagine the next scenario:

In a certain spot on a theme template i’d like to use a 75 x 75 pixel thumbnail, generated from the “featured image” of a post.
So, i set up everything in my functions.php, upload a nice hi-res image and set it as the post’s featured image.
Indeed, by calling the thumbnail image in php ( the_post_thumbnail('custom-thumbnail'); for instance), i get the following:

<img width="75" height="75" src="path/to/image/image-name-75x75.jpg" class="attachment-thumbnail wp-post-image" alt="alt text" />

So far so good. it effectively shows a 75×75 image, but on a retina display, this image looks pixelated and blurry.

I say, let’s use BJ-Lazy Load, and besides it’s lazy load behavior, let’s activate the”Load hiDPI (retina) images” option to solve this.
It should “update” this standard resolution image on a display with higher pixel density, by loading a higher resolution version (2x it’s the usual i suppose), but maintaining it’s dimensions, width & heigth.

So, on the admin backend, I activate BJ-Lazy Load plugin, activate hiDPI option and save changes.
Next, I reload the page on the device with retina display. Image still looks blurry and pixelated.
What happened?

the HTML we get (after the plugin’s javascript has done it’s magic), it’s the following:

<img width="75" height="75" src="path/to/wordpress/wp-content/plugins/bj-lazy-load/thumb.php?src=encoded/path/to/image/image-name-75x75.jpg&w=150" data-lazy-type="image" data-lazy-src="path/to/image/image-name-75x75.jpg" class="lazy attachment-thumbnail wp-post-image data-lazy-ready" alt="alt text" style="display: inline-block;">

Notice the following:

• The width & height img attributes are both 75px as expected. Check.
• The value of the “w” parameter passed to the resizing script “thumb.php” is 150, which corresponds to twice the original dimension of the image (75 * 2), perfect for a “retina-friendly” image. Nice.
• the image passed to the resizing script (as the “src” parameter) is: “encoded/path/to/image/image-name-75x75.jpg“. Here, something is not right…

The image passed to the resizing script as it’s working source has a dimension of 75×75 pixels. There are no extra pixels for “thumb.php” to accurately generate the 150 px required image.
So, we end with a pixelated upscaled 150 px image, that still doesn’t look crisp on a retina display. Not exactly the end of the world, we got the img; but, we didn’t get the hi-res version that we were expecting.

One possible solution (following the actual logic and JS code) could go along the lines of using the original FULL resolution uploaded image (or at least an uncropped higher res version) as the source for the resizing script (Of course, only do if hiDPI option is active and we are on a hiDPI display):

• Obtain the available image sizes from the $_wp_additional_image_sizes array, that holds the width, height, and bool for “crop” option of registered image sizes. Output this array somewhere for JS to access. “data-lazy-sizes” attribute as JSON or similar perhaps?
• In the frontend, find which registered size (if any) was used as the source of the image, and determine if at this particular registered size, the image was or wasn’t cropped. Obtain the dimensions from the img src string with regex “/(\d+x\d+)(?!.*(\d+x\d+))” (selects the last ocurrence of NUMBERxNumber which should be what we need) or something like that, and compare with images sizes information for a match
• if cropped, determine the width/height ratio, in order to crop the new 2x res image with the proper dimensions.
• find the most suitable image size source for resizing (i guess at least 2x the largest dimension of the needed image, not cropped)
• output new src and additional parameters to allow “thumb.php” to provide a suitable retina image to display (or similar logic in new plugin version 😉 ).

I worked the issue I encountered by setting my thumbnail size twice the dimensions i needed, and then setting a CSS rule like “max-width: required-size-in-px; height:auto;” for the particular img. Just a bypass, not the ideal solution.

Anyway, just an idea. It’s not the most common scenario, but if it can be improved, i figured why not do it.
I’d be inclined to think it becomes more of an issue the larger the retina display gets, with images that fulfill the registered-image-sizes <= screen.width condition being used in the php, as this limits the ability of the plugin to get a proper source to work with.
Tell me what you think.

Again, apologies for the long post.
Have a nice day and happy coding!

Andres Cruz

http://wordpress.org/plugins/bj-lazy-load/