Make WordPress Core

Opened 5 years ago

Closed 4 years ago

Last modified 3 years ago

#47873 closed enhancement (fixed)

Introduce handling of "Big Images"

Reported by: azaozz's profile azaozz Owned by: azaozz's profile azaozz
Milestone: 5.3 Priority: high
Severity: normal Version:
Component: Media Keywords: has-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 5 years ago.
47873.2.diff (13.9 KB) - added by azaozz 5 years ago.

Download all attachments as: .zip

Change History (36)

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


5 years ago

#8 @joemcgill
5 years ago

  • Priority changed from normal to high

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

@azaozz
5 years ago

#9 @azaozz
5 years 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.


5 years ago

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


5 years ago

#12 follow-up: @kirasong
5 years 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.


5 years ago

#14 in reply to: ↑ 12 @azaozz
5 years 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
5 years ago

#15 @azaozz
5 years 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
5 years 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
5 years 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 5 years ago by sjnbham (previous) (diff)

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


5 years ago

#19 @kirasong
5 years ago

  • Keywords needs-dev-note added

#20 @kirasong
5 years ago

What else do you think is left here @azaozz?

Is it okay to make you the owner since you committed r46076?

#21 @kirasong
4 years ago

  • Owner set to azaozz
  • Status changed from new to assigned

Going to go ahead and assign this to you @azaozz, since you've done the most work here.

Do you think there's more to go on this ticket?

I think it'd be a good idea either to close this, with new tickets for further issues, or turn it into a task to track issues that come up. Any preferences?

#22 @kirasong
4 years ago

  • Keywords has-patch needs-testing removed
  • Resolution set to fixed
  • Status changed from assigned to closed

After chatting with @azaozz in Slack, going to go ahead and close this one.

Please open new tickets for any issues found.

Thanks so much everyone!

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


4 years ago

#24 follow-up: @azaozz
4 years ago

In 46353:

Media: Move wp_get_original_image_path() to wp-content/post.php to make it easier to access from plugins.

Props pbiron.
See #47873.

#25 in reply to: ↑ 24 @azaozz
4 years ago

Replying to azaozz:

Ugh, I mean wp-includes/post.php :)

#26 in reply to: ↑ 2 ; follow-up: @justinahinon
4 years ago

Is it possible to have more examples of "big" images cases? Or if there is something generic (for WordPress?) about it... Just asking for docs/devnotes purposes.

Replying to azaozz:

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

#27 in reply to: ↑ 26 ; follow-ups: @azaozz
4 years ago

Replying to justinahinon:

This is controlled by the big_image_size_threshold filter. It sets the max-width or max-height (landscape vs. portrait) value (in pixels) above which an image will be considered "big".

As mentioned before there are several checks possible there apart from dimensions: file size, presence of EXIF Orientation !== 1 (meaning the image is a photo coming directly from the camera), etc. But thinking it is easier to understand and use when it only looks at dimensions, at least for now. So currently any image with width or height above 2560px is considered big.

Last edited 4 years ago by azaozz (previous) (diff)

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


4 years ago

#29 in reply to: ↑ 27 @justinahinon
4 years ago

Replying to azaozz:

Thanks for clarifying.

I don't see in the patch where the EXIF Orientation tag is checked. Is this something that can still be done here and added in 5.3 or do you recommend creating a new ticket for it?

#30 @justinahinon
4 years ago

  • Keywords has-dev-note added; needs-dev-note removed

#32 in reply to: ↑ 27 @yusupba
3 years ago

  • Severity changed from normal to critical
  • Summary changed from Introduce handling of "Big Images" to Introduce handling of "Big Images", Vertical images

Hello

How do I fix it? which line of code I gotta put as nothing works for me atm.
Thanks

Replying to azaozz:

Replying to justinahinon:

This is controlled by the big_image_size_threshold filter. It sets the max-width or max-height (landscape vs. portrait) value (in pixels) above which an image will be considered "big".

As mentioned before there are several checks possible there apart from dimensions: file size, presence of EXIF Orientation !== 1 (meaning the image is a photo coming directly from the camera), etc. But thinking it is easier to understand and use when it only looks at dimensions, at least for now. So currently any image with width or height above 2560px is considered big.

#33 @tobifjellner
3 years ago

  • Severity changed from critical to normal
  • Summary changed from Introduce handling of "Big Images", Vertical images to Introduce handling of "Big Images"

@yusupba
This system (WordPress Core Trac) is used for coordination of development and bug fixes for the Software WordPress itself.
You just edited a ticket that followed up on the development and introduction of a piece of functionality almost two years ago.
Since this ticket has already been implemented, I've rolled back the changes you made, in order to have the right information in the ticket for those who later want to be able to see why something was implemented the way it was, etc.

If you have a question about how to do something, or if something is not working specifically for you, then the best place for you to ask would be by posting in the support forums, https://wordpress.org/support/forum/how-to-and-troubleshooting/?view=all#new-topic-0

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


3 years ago

Note: See TracTickets for help on using tickets.