Uploaded images are still saved as a "resized" duplicate

[wpdennis]

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.

[joemcgill]

#37197 was marked as a duplicate.

[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

[desrosj]

#38281 was marked as a duplicate.

[galbaras]

@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!

[galbaras]

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.

[nosilver4u]

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.

[azaozz]

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.

2. 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).

[azaozz]

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.

[azaozz]

In 32437.2.diff:

• Refresh the patch and add more inline help/comments.
• Introduces a wp_image_resize_identical_dimensions "boolean" filter. Returning true will create an image with identical dimensions.
• Update and fix the unit tests.

Thinking this is ready to go in. Works well in combination with the "BIG image" handling patch from #47873.

[kirasong]

I haven't had a chance to test this yet, but took a look at the patch. The approach looks solid, and I like the change.

In my reading, the new comments about cropping make it a little harder to understand what's going on. I'll make a pass on it.

[azaozz]

Replying to mikeschroder:

In my reading, the new comments about cropping make it a little harder to understand what's going on. I'll make a pass on it.

Yeah, it's not very easy to explain.

When cropping to 400x400 the resulting image may not actually be 400x400. If the original image is for example 600x300, you will get 400x300 result.

Going to commit it to make it easier to detect any problems. Please edit as you see fit :)

[azaozz]

In 46077:

Media: Improve handling of cases where an uploaded image matches exactly a defined intermediate size. In most of these cases the original image has been edited by the user and is "web ready", there is no need for an identical intermediate image.

Introduces the wp_image_resize_identical_dimensions filter so plugins and themes can determine whether a new image with identical dimensions should be created, defaults to false.

Props wpdennis, HKandulla, galbaras, azaozz.
See #32437.

[azaozz]

In 46078:

Fix "white spaces at end of line" in docblock (IDE) woes after [46077].

See #32437.

[kirasong]

Replying to azaozz:

<snip>
Going to commit it to make it easier to detect any problems. Please edit as you see fit :)

That's great -- thank you!

[kirasong]

Since it looks like this is done, going to go ahead and close it -- thanks everyone!

Feel free to reopen if necessary.