WordPress.org

Make WordPress Core

Opened 5 weeks ago

Last modified 5 days ago

#47873 new enhancement

Introduce handling of "Big Images"

Reported by: azaozz Owned by:
Milestone: 5.3 Priority: high
Severity: normal Version:
Component: Media Keywords: has-patch needs-testing needs-dev-note
Focuses: Cc:

Description

There are generally two types of images that are uploaded:

  • Images that have been edited or created in an image editing application.
  • Photos that are uploaded either directly from the camera or haven't been edited.

In the first case the images are usually "web ready". They may have been scaled down to an appropriate size and optimized.

In the second case the images are usually much bigger than needed and are not optimized for web use. A photo taken with an average modern smart phone is easily over 5MB in file size. Photos taken with a good quality camera can be much larger.

The Big Image "special handling" idea has been around for quite some time. The two options are:

  • Edit the image after upload and make it "web ready" (including scaling and file size optimizing).
  • Store the original image but not use it on the website.

Each option has drawbacks, but considering that generally storage is cheaper than bandwidth, and that we would want to preserve the user's photos, the second option seems more desirable.

Attachments (2)

47873.diff (14.0 KB) - added by azaozz 3 weeks ago.
47873.2.diff (13.9 KB) - added by azaozz 11 days ago.

Download all attachments as: .zip

Change History (21)

#1 follow-up: @joyously
5 weeks ago

I have seen support topics asking about why their big image is all fuzzy after uploading to WP. (this was a photographer, another was trying to do those huge astronomy photos)
Or why the file size grew once WP processed the image (usually PNG).

#2 @azaozz
5 weeks ago

Related #47872, #14459, #14459, #32437.

As far as I see the simplest, backwards-compatible and sufficiently future-proof solution is to:

  1. Detect when an image is "big". This should be by looking at both file size and dimensions and would need some comparison data. For example a 3000 x 2250 JPEG image is "big" if the file size is over 1600KB, etc. This test may also include looking at EXIF orientation data. An edited image would always have that set to 1 (proper orientation).
  1. When an image is big, create a "web optimized maximum size" of it. Then use that max-size as the largest available size in WordPress. There is an edge case when the original image dimensions match the max-size dimensions. Then it should still create the max-size if the file size is over the limit, and can compare the file sizes.

On the technical side that would need only a small change to how we store image meta. When there is a big image, the "full" size would be the path to the max-size created after uploading, and the original image path would be in original-image. Alternatively we can add separate meta key for it.

Then these "original images" will be available for downloading from the Media Library for users that use WP as online albums/image storage (in case they want to print them, etc.). They also will be available for making additional image sub-sizes in the future.

#3 in reply to: ↑ 1 @azaozz
5 weeks ago

Replying to joyously:

Yeah, think that WP shouldn't process big images unless they are photos uploaded without editing. Thinking we can detect that pretty easily, and when in doubt, err on the side of image quality (i.e. not resize) :)

#4 follow-up: @tobifjellner
5 weeks ago

Why not let the user select in the settings whether the BIG original photo should be stored or not? Default value should then obviously be to keep it, since that's what a user would expect until they change the setting themselves.
Perhaps even save these huge photos in a separate directory or mark the filename somehow, to let the new "big" file take over the original filename?

#5 in reply to: ↑ 4 @azaozz
5 weeks ago

Replying to tobifjellner:

Why not let the user select in the settings whether the BIG original photo should be stored or not?

Yep, that definitely will be a possibility. Just wondering if it should be another checkbox on the Settings => Media screen or just settable from a plugin. If the users don't want to use their sites as "photo storage" they should be able to set that.

Perhaps even save these huge photos in a separate directory or mark the filename somehow, to let the new "big" file take over the original filename?

Not sure about the separate directory. That makes sense only when the users access the back-end through FTP. But the file names should definitely be "marked". Thinking appending something like -original right before the file extension would be sufficient.

#6 @azaozz
4 weeks ago

Thinking a bit more: the path to original images should be added as (new) attachment meta. This ensures the widest/best compatibility. The only change in the UI would be to add a link to the original image in the "attachment details" section. Then, in the future, perhaps can consider adding a "download your files" view/list/section that would list all original images regardless if they are used as the full size.

Also been looking at what should be the "max-size" we'd like to use on the front-end. It will, of course, be filterable but thinking 2560px (width or height) makes sense/is a good starting point.

Any suggestions, ideas, or more considerations welcome! :)

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


4 weeks ago

#8 @joemcgill
4 weeks ago

  • Priority changed from normal to high

Marking this as "high priority" since it's part of the release focus.

@azaozz
3 weeks ago

#9 @azaozz
3 weeks ago

In 47873.diff:

  • Determine if an image is "BIG" by using a (filterable) threshold. If it is, scale it to the threshold value (either width or height) and use it as the "full-size" image.
  • Add (helper) functions for retrieving the path and URL to originally uploaded images.

TBD:

  • Currently a string -scaled is added to the new full-size image's file name. Alternatively the {width}x{height} can be used as any other resized image, or perhaps a short hash? Any "for" or "against" on this? :)
  • The default BIG image threshold is set to 2560px. This produces JPEGs (photos) of approximately 850KB. That seems like good "biggest" image size, by dimensions and by file size. Would another default be more appropriate?
  • The original images are used when creating other sub-sizes later on, and so the users can download them if needed. Perhaps can add a helper function to select them or delete them but thinking it would be better if there is no UI by default for that.

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


3 weeks ago

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


3 weeks ago

#12 follow-up: @mikeschroder
12 days ago

Just to give a quick opinion: I think we should store the original in all cases, and default to that behavior to help users generate larger sizes, if/when they need them, in the future.

This would also allow WordPress to create these larger (or other dynamic sizes) for users' sites in high quality when as WordPress gets better at handling images. It's never a good idea to resize from an already resized image when it's possible to work from the original.

I think a filter to disable that behavior makes sense, but an additional option for the admin (decisions, not options) isn't necessary here.

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


12 days ago

#14 in reply to: ↑ 12 @azaozz
11 days ago

Replying to mikeschroder:

I think we should store the original in all cases, and default to that behavior to help users generate larger sizes, if/when they need them, in the future.

This would also allow WordPress to create these larger (or other dynamic sizes) for users' sites in high quality when as WordPress gets better at handling images. It's never a good idea to resize from an already resized image when it's possible to work from the original.

Completely agree!

Thinking that deleting the original image should be left for plugins, and should not happen immediately after uploading an image. We still need the original to make all the image sub-sizes (which can be slow process over several requests).

The current patch stores the original image's file name in another array key in the image meta array: original_image. It is trivial for a plugin to check for its existence, remove the key, and delete the original file. In that case the resized image will be used instead when creating new sub-sizes in the future, but the quality will be reduced and the size will be restricted to the "big image threshold" value from the time the image was uploaded.

@azaozz
11 days ago

#15 @azaozz
11 days ago

  • Keywords has-patch needs-testing added

In 47873.2.diff:

  • Refresh/some cleanup.
  • Introduce wp_get_original_image_path() that looks in image meta and always returns the path to the originally uploaded image file.
  • Some enhancements to wp_create_image_subsizes() and _wp_make_subsizes().

Thinking this is ready to go in. Please test :)

#16 @azaozz
10 days ago

In 46076:

Media: Add handling for "BIG" images. When the users upload a big image, typically a photo, scale it down to make it suitable for web use. Then use the scaled image as the "full" size, and keep the originally uploaded image for creating high quality sub-sizes in the future and in case the users want to download it later.

Introduces wp_get_original_image_path() that retrieves the path to the originally uploaded image in all cases, and big_image_size_threshold filter to set the pixel value above which images will be scaled. The same value is used as max-width and max-height when scaling.

See #47873.

#17 @sjnbham
6 days ago

This enhancement caught my attention because it's an issue I quickly ran in to when working on adopting WordPress and selecting image optimization products. Many modern cameras and stock photo services provide high res images over 8,000 x 8,000 pixels. Many hosting companies don't support resizing images of that size. We've tried working with the likes of WPEngine and they've declined thus far to increase the size limit on the image resizing utility they use.

https://wordpress.org/support/topic/width-or-height-exceeds-limit-2/

I realize this has more to do with the hosting companies and how they configure WP. But thought I'd mention it because this enhancement may not help those who use WP hosted options.

Last edited 6 days ago by sjnbham (previous) (diff)

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


5 days ago

#19 @mikeschroder
5 days ago

  • Keywords needs-dev-note added
Note: See TracTickets for help on using tickets.