Responsive Content Images & Retina Screens

Hi Enfold Team, I tested this out in hte meantime but am baffled by the results :-)
Can you help me understand?

I doubled the thumb sizes in the child theme functions.php:

// – set WordPress compression of image and thumbnails on upload and resize to 90 or higher
// images are manually resized, compressed and optimized BEFORE upload already
// WP compression on images on resize/for thumbnails is standard = 82
add_filter(‘jpeg_quality’, function($arg){return 90;});

// remove “responsive images” srcset functionality in WP 4.4 and on from this theme
remove_filter( ‘the_content’, ‘wp_make_content_images_responsive’ );

// double-size thumbs for Retina screens and zoom
$avia_config[‘imgSize’][‘widget’] = array(‘width’=>72, ‘height’=>72); // small preview pics eg sidebar news – ORG 36 x 36
$avia_config[‘imgSize’][‘square’] = array(‘width’=>360, ‘height’=>360); // small image for blogs – ORG 180 x 180
$avia_config[‘imgSize’][‘featured’] = array(‘width’=>3000, ‘height’=>860); // images for fullsize pages and fullsize slider – ORG 1500 x 430
$avia_config[‘imgSize’][‘featured_large’] = array(‘width’=>3000, ‘height’=>1260); // images for fullsize pages and fullsize slider – ORG 1500 x 630
$avia_config[‘imgSize’][‘extra_large’] = array(‘width’=>3000, ‘height’=>3000, ‘crop’ => false); // images for fullscrren slider – ORG 1500 x 1500
$avia_config[‘imgSize’][‘portfolio’] = array(‘width’=>990, ‘height’=>800); // images for portfolio entries (2,3 column) – ORG 495 x 400
$avia_config[‘imgSize’][‘portfolio_small’] = array(‘width’=>520, ‘height’=>370); // images for portfolio 4 columns – ORG 260 x 185
$avia_config[‘imgSize’][‘gallery’] = array(‘width’=>1690, ‘height’=>1368); // images for portfolio entries (2,3 column) – ORG 845 x 684
$avia_config[‘imgSize’][‘magazine’] = array(‘width’=>1420, ‘height’=>750); // images for magazines – ORG 710 x 375
$avia_config[‘imgSize’][‘masonry’] = array(‘width’=>1410, ‘height’=>1410, ‘crop’ => false); // images for fullscreen masonry – ORG 705 x 705
$avia_config[‘imgSize’][‘entry_with_sidebar’] = array(‘width’=>1690, ‘height’=>642); // big images for blog and page entries – ORG 845 x 321
$avia_config[‘imgSize’][‘entry_without_sidebar’]= array(‘width’=>2420, ‘height’=>846); // images for fullsize pages and fullsize slider – ORG 1210 x 423
$avia_config[‘imgSize’] = apply_filters(‘avf_modify_thumb_size’, $avia_config[‘imgSize’]);

Save and regenerate thumbs.
But then I watch the regenerated thumbnails and they seems to be back to the standard sizes.
These are the currently registered thumbnail sizes, whether they exist for this attachment, and their filenames:

thumbnail: 80×80 pixels (cropped to fit)
medium: 300×300 pixels (proportionally resized to fit inside dimensions)
medium_large: 768×0 pixels (proportionally resized to fit inside dimensions)
large: 1030×1030 pixels (proportionally resized to fit inside dimensions)
widget: 36×36 pixels (cropped to fit)
square: 180×180 pixels (cropped to fit)
featured: 1500×430 pixels (cropped to fit)
featured_large: 1500×630 pixels (cropped to fit)
extra_large: 1500×1500 pixels (proportionally resized to fit inside dimensions)
portfolio: 495×400 pixels (cropped to fit)
portfolio_small: 260×185 pixels (cropped to fit)
gallery: 845×684 pixels (cropped to fit)
magazine: 710×375 pixels (cropped to fit)
masonry: 705×705 pixels (proportionally resized to fit inside dimensions)
entry_with_sidebar: 845×321 pixels (cropped to fit)
entry_without_sidebar: 1210×423 pixels (cropped to fit)
shop_thumbnail: 100×100 pixels (cropped to fit)
shop_catalog: 300×300 pixels (cropped to fit)
shop_single: 600×0 pixels (proportionally resized to fit inside dimensions)
woocommerce_thumbnail: 300×300 pixels (cropped to fit)
woocommerce_single: 600×0 pixels (proportionally resized to fit inside dimensions)
woocommerce_gallery_thumbnail: 100×100 pixels (cropped to fit)

Thanks in advance for your help (I see you’re a bit flooded with help requests now…)

• This reply was modified 5 years, 8 months ago by rob2701.

After some more testing, thinking and testing:

1.
Changes to the thumbs array in the child theme DO work. I must have done something wrong last time. Sorry.

2.
After a bit of thought I’ve decided that its much more efficient for me to do the exact double-size high compression images by hand and then upload.
While it’s nice to have the theme automatically do resizing and cropping, it just results in much heavier images, most of which I will not use anyway..

3.
I have commented out all thumbnails sizes in the child theme functions.php therefore..
Thus regenerating thumbs loses all other sizes (except the WP ones for the Media Library).
Going to try just using the full size original and having the theme CSS do downscaling.

You can mark this topic as solved. I hope. Unless I’ve made a wrong assumption somwhere down the line :-)

Hi Ismael,

Thanks for the response and the tip, will look into it. Still getting to know the theme, so one step at a time :-)

Regards,
Rob

hI,
For anyone interested in follwoing the same route as me to serve up double-size retina images with high compression to all devices, here’s what I did.

functions.php in child theme:

// remove "responsive images" functionality in WP 4.4 and higher
add_filter('wp_get_attachment_image_attributes', function($attr) {
   if (isset($attr['sizes'])) unset($attr['sizes']);
   if (isset($attr['srcset'])) unset($attr['srcset']);
   return $attr;
}, PHP_INT_MAX);
add_filter('wp_calculate_image_sizes', '__return_false', PHP_INT_MAX);
add_filter('wp_calculate_image_srcset', '__return_false', PHP_INT_MAX);
remove_filter('the_content', 'wp_make_content_images_responsive');

// Disable loads of Enfold & WP image sizes upon upload
// do image sizes manually, double-size with high compression for retina screens
// use Photoshop to set exact double size and quality between Q30 and Q40
add_action('init', 'remove_enfold_image_sizes');
function remove_enfold_image_sizes() {
// do NOT remove widget size, is used in backend portfolio items!
// remove_image_size('widget');
	remove_image_size('square');
	remove_image_size('featured');
	remove_image_size('featured_large');
	remove_image_size('portfolio');
	remove_image_size('portfolio_small');
	remove_image_size('gallery');
	remove_image_size('magazine');
	remove_image_size('masonry');
	remove_image_size('entry_without_sidebar');
	remove_image_size('entry_with_sidebar');
	remove_image_size('shop_thumbnail');
	remove_image_size('shop_catalog');
	remove_image_size('shop_single'); 
  remove_image_size('shop_gallery_thumbnail');
}
// Remove unneeded WP image sizes
add_filter( 'intermediate_image_sizes_advanced', 'prefix_remove_default_images' );
// Remove default image sizes here. 
function prefix_remove_default_images( $sizes ) {
// do NOT remove small and medium sizes, they are used in backend Media Library!
// unset( $sizes['small']); // 150px
// unset( $sizes['medium']); // 300px
 unset( $sizes['large']); // 1024px
 unset( $sizes['medium_large']); // 768px
 return $sizes;
}

List of Enfold/TopMenu image sizes for different image ratios:

w = standard width Enfold
Rw = doubled Enfold width for Retina
GR = Golden Ratio

ENFOLD WITH Top menu

full width header banner frontpage
w 1519 x 430 / Rw 3040 x 860
>>>>> USE:
4:1 > 3000 x  849

news featured
w 81 x 81 / Rw 162 x 162
>>>>> USE:
1:1 > 180 x 180
1:1 > 360 x 360

portfolio 2 column featured
w 758 / Rw 1516
>>>>> USE:
4:3  > 1600 x 1200
3:2  > 1600 x 1067
16:9 > 1600 x  900
GR   > 1600 x  991

portfolio 3 column featured
w 507 / Rw 1014
>>>>> USE:
4:3  > 1024 x  768
3:2  > 1024 x  683
16:9 > 1024 x  576
GR   > 1024 x  624

portfolio 4 column featured
w 378 / Rw 756
>>>>> USE:
4:3  >  800 x  600
3:2  >  800 x  533
16:9 >  800 x  450
GR   >  800 x  496

portfolio single full width
w 1419 / Rw 2838
>>>>> USE:
4:3  > 3000 x 2250
3:2  > 3000 x 2000
16:9 > 3000 x 1688
GR   > 3000 x 1858

portfolio single 2/3
w 918 / Rw 1836
>>>>> USE:
4:3  > 1920 x 1440
3:2  > 1920 x 1280
16:9 > 1920 x 1080
GR   > 1920 x 1189

portfolio single 3/4
w 1043 / Rw 2086
>>>>> USE:
4:3  > 2500 x 1875
3:2  > 2500 x 1667
16:9 > 2500 x 1406
GR   > 1920 x 1549

gallery with right sidebar
w 986 / Rw 1972
>>>>> USE:
4:3  > 2000 x 1500
3:2  > 2000 x 1333
16:9 > 2000 x 1125
GR   > 2000 x 1239

store multi product
w 320 / Rw 640
>>>>> USE:
4:3  >  640 x  480
3:2  >  640 x  427
16:9 >  640 x  360
GR   >  640 x  396

store single product 1/2
w 667 / Rw 1334
>>>>> USE:
4:3  > 1440 x 1080
3:2  > 1440 x  960
16:9 > 1440 x  810
GR   > 1440 x  892

5 column featured
w 216 / Rw 432
>>>>> USE:
4:3  >  480 x  360
3:2  >  480 x  320
16:9 >  480 x  270
GR   >  480 x  297

3/5 of page
w 817 / Rw 1634
>>>>> USE:
4:3  > 1800 x 1350
3:2  > 1800 x 1200
16:9 > 1800 x 1013
GR   > 1800 x 1115

Hi Tanja,
The whole idea about my solution is to serve up ONE high resolution image to all devices, but to make that image bigger with higher compression (for retina screens and zooming sharpness). This is because on all modern devices images can be zoomed (enlarged), so the “traditional” way of serving smaller images to certain devices would result in blurry images when enlarged or when viewd on retina/high resolution screens.
That is why I chose to disable the WP responsive images solution and disable the same approach used by Enfold.
See https://www.netvlies.nl/tips-updates/algemeen/design-interactie/retina-revolution/ for the background on this.

To take this approach you need to MANUALLY upload the correct size and resolution for each image on that particular page, using Photoshop or similar.

When you start this on an already existing site the code changes will ONLY affect NEW uploads, i.e. newly uploaded images will not get all of those resized thumbnails created.
You can then (at your own pace) start to replace the existing images with the new accurately sized ones. I recommend a plugin like “Enable Media Replace” to make this process less “painful”.
Once you have replaced all existing images with new precisely sized ones, you can then use a plugin like “Regenerate Thumbnails” to recreate the proper thumbnail sizes (without all the additional ones) and get rid of all previously created, now unneeded, thumbnail sizes to save space on the server.

I have been using this method for several years now, and I am completely happy with both the loading speed and the image quality even when zoomed.

So try it out and see if it works for you. Hope this helps.

Regards,
Rob

Hi Tanja,
The images for the gallery are two different ones: one for the preview (the thumbnails), one for the originals (full size).
Same for shop product previews and full sizes.
For example:
I name the ones for the preview strip (example, ftd means featured from featured image):
<imagename>-ftd-800×533-q30.jpg
and the ones for the full view:
<imagename>-1920×1280-q30.jpg
to distinguish between them in the Media Library.
The browser takes care of relatively adjusting the relative sizes from the originals in other cases.
Hope that clears it up.
Kind regards,
Rob

In other words, the principle is always the same: double the actual size with high compression.
Consult the list above to see the actual pixel sizes for the type of page you create the image for.

• This reply was modified 5 years, 3 months ago by rob2701. Reason: added some info to clarify

Hi Tanja,
The featured images setting works only on the portfolios of course.
For the galleries you just upload the originals and choose for example small thumbnails and “No Scaling”.
The browser will resize the images for the preview strip from the original and open the original size in the lightbox.
Just experiment.
Kind regards,
Rob

Hi Tanja,
I understand you may be a little worried at the cost of a little more image weight using the non-scaled images also for the preview strip in the galleries…
You can always try to add one of the size which Enfold recommends in the dropdowns then, of course.
But I wouldn’t worry about it too much though, that’s why I suggested using the “no scaling” option for the galleries.
You see, that way the full images to be opened in the lightbox on click are already loaded on the page itself (check the page source), so it saves quite a few extra http requests at the cost of a little more image weight. What you lose on the swings you gain on the roundabouts :-)
Kind regards,
Rob

If that doesn’t do the trick try this (replace the relevant part):

// Remove unneeded WP image sizes
// updated 2020-01-13 because of additional image sizes
function remove_default_image_sizes( $sizes) {
  unset( $sizes['thumbnail']); // 80px thumbnail
  unset( $sizes['small']); // 150px thumbnail - (Size based on Media setting)
  unset( $sizes['medium']); // 300px - (Size based on Media settings)
  unset( $sizes['medium_large']); // 768 - (Size based on Media settings)
  unset( $sizes['large']); // 1024
  unset( $sizes['extra_large']); // 1500
  unset( $sizes['1536x1536']);
  unset( $sizes['2048x2048']);
// Add these 2 lines to remove the "new" WP default image sizes:
  remove_image_size( '1536x1536' );
  remove_image_size( '2048x2048' );
  return $sizes;
}
add_filter('intermediate_image_sizes_advanced', 'remove_default_image_sizes');

By the way, in Settings > Media I have:
Thumbnail size 80×80, crop checked
Medium size 300×300
Large size 1024×1024
Check yours before doing the regenerate

Oh yeah, and you only see the REAL sizes created in an actual image “Regenerate”, the General “Regenerate Thumbnails” setting shows the “default” registered sizes. Strange but true. Perhaps that is the only issue?
After regenerating you can check this by doing a regenerate on an actual image, and of course by checking the actual files through FTP.

• This reply was modified 4 years, 6 months ago by rob2701. Reason: Added remark about how to check for ACTUAL created thumbs

Hi,

Glad to hear the initial code works.

Like I explained above, for some reason the General settings page in Regenerate Thumbnails keeps showing the default registered image sizes in WP. But when you actually regenerate the thumbnails on an actual image, then it correctly shows the registered ones with a green checkmark and the deregistered ones with a red cross. Don’t know why, you should ask the developer of the plugin. Same for why it doesn’t remove the unused redundant thumb sizes, plugin developer will know more than me. But if the Regenerate Thumbnails Advanced by Shortpixel works for removing the redundant ones, great. Use it once, then after that the Regenerate Thumbnails one will handle the new ones correctly.

Trimage says it will work an Mac, macOS Trimage is available from Homebrew, to install, type:
brew install trimage
Launch by executing trimage in Terminal.

ImageOptim (For macOS) may be a good alternative. PNG Gauntlet for PNGs.
Caesium Image Compressor may also be a good choice.

Regarding my choice to disable WP srcset for now:
I have opted out of that to be able to serve “1 double size image with high compression for all devices”. It results in sharp images but no extra page weight. At the moment there is no way with Enfold to serve different images to different devices using the Retina approach chosen. If you enable WP srcset it will just create lots of extra image sizes which cannot be used in Enfold effectively anyway now.
Also don’t be fooled too much by the possibility of using CSS choices for different devices (by duplicating blocks and assigning custom CSS classes to specify the device, it will just result in ALL the images for ALL devices loading on your pages ALL THE TIME (yes, for all devices regardless).
So no, I don’t know at the moment how you could implement WP srcset while using Enfold.
Hence my approach: 1 image fits all. Added bonus: less http requests in galleries, even if images are heavier on smaller devices for now.

Of course, once Enfold implements srcset (which they have promised to deliver at some point) the whole approach changes, as we will hopefully be able to serve different sizes to different devices (but still maintain the double size high compression approach for all of them).

Kind regards,

Rob

• This reply was modified 4 years, 5 months ago by rob2701. Reason: Removed my stupid remark about why Regenerate Thumnails might not be picking up the list of unset image sizes in its on its general page. Turns out others have noticed the same behaviour (on the plugin's Support page)