WordPress.org

Make WordPress Core

Opened 5 days ago

Last modified 5 days ago

#47873 new enhancement

Introduce handling of "Big Images"

Reported by: azaozz Owned by:
Milestone: 5.3 Priority: normal
Severity: normal Version:
Component: Media Keywords:
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.

Change History (5)

#1 follow-up: @joyously
5 days 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 days 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 days 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 days 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 days 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.

Note: See TracTickets for help on using tickets.