WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 5 weeks ago

#32437 new defect (bug)

Uploaded images are still saved as a "resized" duplicate

Reported by: wpdennis Owned by:
Milestone: 5.3 Priority: normal
Severity: normal Version: 4.2
Component: Media Keywords: has-patch needs-testing 2nd-opinion
Focuses: Cc:

Description

This is a follow-up to #31296.

The provided patch in #31296 doesn't fix the issue introduced with #19793 in all instances.

For example: Let's say a theme has a content width of 600 and by default authors are uploading images in 600*300. But the admin could have set the media settings to 600*3000, since only the width is mandatory. The height can vary if the author feels it's necessary (e.g. infographics or headline-like images in 600*100).

But since the current version duplicates the image in every case, except both dimensions are equal to the media settings, we would still get every image twice (except someone is uploading an image in 600*3000 in this example).

I think it should check whether $orig_size is equal to the resized dimensions, instead of $size_data in this snippet:

$image = $this->_resize( $size_data['width'], $size_data['height'], $size_data['crop'] );

$duplicate = ( ( $orig_size['width'] == $size_data['width'] ) && ( $orig_size['height'] == $size_data['height'] ) );

An if the resized image has the same dimensions, it shouldn't be saved again.

Attachments (1)

32437.diff (4.4 KB) - added by azaozz 5 weeks ago.

Download all attachments as: .zip

Change History (13)

This ticket was mentioned in Slack in #core-images by joemcgill. View the logs.


3 years ago

#2 @joemcgill
3 years ago

#37197 was marked as a duplicate.

#3 @joemcgill
3 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

#4 follow-up: @HKandulla
3 years ago

Sorry for jumping into this ticket but I am of the exact opposite opinion.
I think that it actually much better if the image is resized eventhough the resized sizes resemble the original size. By resizing WP optimizes (compresses) the image and a lot of Plugins hook into that, I defineteyl want optimized version for all sizes (images) I render. Maybe we can wrap this feature in a apply_filter, so that the user can decide which route to go?

Thanks, Hannes

This ticket was mentioned in Slack in #core-media by joemcgill. View the logs.


2 years ago

#6 @desrosj
2 years ago

#38281 was marked as a duplicate.

#7 @galbaras
2 years ago

@HKandulla if you prefer an optimised image, use an optimising plugin, which will do a better job anyway, e.g. converting to WEBP, removing Exif, etc, which WordPress doesn't do.

The whole point of uploading an image at the precise size you need is doing the preparations ahead of time, which should include saving an optimised version. Otherwise, just upload whatever size you have and let WP take care of smaller sizes.

This situation leaves an extra file that's identical for most people and serves absolutely no purpose.

A better solution than the one above may be the one in #38281.

This ticket has been open since v4.2!

#8 in reply to: ↑ 4 @galbaras
14 months ago

Replying to HKandulla:

Sorry for jumping into this ticket but I am of the exact opposite opinion.
I think that it actually much better if the image is resized eventhough the resized sizes resemble the original size. By resizing WP optimizes (compresses) the image and a lot of Plugins hook into that, I defineteyl want optimized version for all sizes (images) I render. Maybe we can wrap this feature in a apply_filter, so that the user can decide which route to go?

Thanks, Hannes

Actually, when the original is optimised, WP creates a larger file, so large that even my optimisation plugin can't get it down to the original size again, but with a lower visual quality.

This is a waste of space and processing power in most cases. It's much better to either pre-optimise the original file or to let a plugin optimise it after it's uploaded.

#9 @nosilver4u
14 months ago

As Gal has noted, you will sometimes get a larger version of the image when a resize with the same dimensions are created. WP doesn't compress anything really when creating resizes, that's just a side-effect of the way the JPG format works. And more often than not, it fails to produce a fully optimized image. No fault to WP really, just the way GD and Imagick are built, along with the incredible amounts of memory necessary for properly optimizing some images.

While I don't have every IO plugin installed locally, I have all of the popular ones, and came up empty on a search for WP_Image_Editor extensions. So, as far as I can tell, EWWW IO is the only image optimization plugin that even bothers to hook in at the WP_Image_Editor level, and it explicitly disables itself when resizes are being created for a new upload. Most IO plugins are hooking in after all the resizes are done, somewhere like the wp_generate_attachment_metadata filter, where they optimize both the resizes AND the original image.

#10 @azaozz
6 weeks ago

Confirmed this while working on #40439. It is currently fixed in https://core.trac.wordpress.org/attachment/ticket/40439/40439.4.diff but wondering what's the right way to handle it.

  1. When the user uploads a non-edited photo, we need to optimize it. The file size is dramatically reduced. Testing with a few 4128 x 3096 photos (standard smartphone camera), the size goes from ~4.2MB to ~1.5MB.
  1. At the same time when the user uploads an edited and optimized image, the GD/Imagick processing may make it larger and with poorer quality. Testing with an optimized 1024x768 JPEG image, the original is 98KB and the resulting "large" size image is 121KB and slightly pixelated (when viewed on a 2x screen).

The second case seems quite more common. Virtually all digital cameras nowadays produce large images that are not suitable for web use. To account for both cases, thinking we should add a threshold above which images will be optimized when they match one of the defined sizes. A good spot to start optimizing is perhaps above 3MP (2048x1536), or maybe even 5MP (2560x1920).

This means that when there is a defined size larger than 2048px, and an uploaded image matches that size, we will still produce a resized image suitable for web use (in this case "resized" means with reduced file size, not dimensions).

#11 @azaozz
6 weeks ago

  • Milestone changed from Future Release to 5.3

@azaozz
5 weeks ago

#12 @azaozz
5 weeks ago

  • Keywords has-patch needs-testing 2nd-opinion added; needs-patch removed

In 32437.diff: When an uploaded image matches exactly a registered size, use a threshold to determine whether to still create a sub-size with matching dimensions (but hopefully smaller file size). Adds wp_image_resize_identical_dimensions_threshold filter with a default value of 2560.

Note that this changes the current behaviour for this edge case. The reason is that smaller images that match exactly a registered size are likely edited before upload. Currently when we create a sub-size for such image, it usually ends up with a larger file size and slightly reduced quality.

Note: See TracTickets for help on using tickets.