Improve intermediate image size handling

[koopersmith]

When discussing the new media workflows on #21390, the need to improve our image size API became apparent.

A quick overview of the improvements that should be made:

• All image attachments have an original, or "golden master", which is never altered.

• An image size creates a new image and stores all transformations applied to the image as metadata. Transformations are described relative to the golden master. An image size has a unique slug (which means a set of dimensions does *not* have to be unique).

• Image attachments have a "master" image size, which is used to create any automatically generated image sizes.

• Automatically generated image sizes can be overridden with manual transformations.

Would love for someone to step up on this ticket, as the media modal editing UI will benefit greatly from these improvements.

[scribu]

This sort of depends on #6821. Been pondering a better API in this area in #15311.

[scribu]

This isn't really about the API, but about how it works internally.

[martythornley]

While looking at image sizes... it would be a huge improvement to allow a max size that uploads will never be bigger than. Currently the "max size" adjusts that large size, but the huge original image is still uploaded and remains on the server.

Working with a lot of photographers, they upload images at the scale of 4,000px wide and more. It can really eat up space, especially in MulitSite. Large images also make import/export much harder. I've seen imports rendered impossible because the first item in the WXR is an image that is 5MB and won't make the trip.

Can I suggest two possible routes?
1) A second size setting so we have one for the "large" size and one for the ultimate "original" size - or
2) Possibly an option that would allow unlimited "original" images to be uploaded, or crop to a max size and delete the actual upload - or a constant that we can define that would do the same.

[Otto42]

I think we should keep the original of whatever image is uploaded, no matter what.

If resizing of the original happens, it should happen on the client side. This is an option with some of the plupload image handling, which may or may not make it in for 3.5.

[scribu]

Related: #19393

[prettyboymp]

Automatically generated image sizes can be overridden with manual transformations.

Does this mean we're looking to include custom cropping per image size in core? Or does this mean something else?

[DrewAPicture]

Replying to martythornley:

While looking at image sizes... it would be a huge improvement to allow a max size that uploads will never be bigger than. Currently the "max size" adjusts that large size, but the huge original image is still uploaded and remains on the server.

There's a scaling option built into plupload that's currently mapped to the dimensions of the 'large' image size. You can enable the functionality ui on upload by adding the following action:

add_action( 'post-upload-ui', 'media_upload_max_image_resize' );`

Granted, you're effectively losing the 'original' image size but we've found this greatly cuts down on photogs filling up the server with full-sized originals that will never be used.

It would nice to see the hook get included in the new modals since we rely on it so heavily.

[nacin]

Related bug? #18799

[scribu]

Related: #22100

[kirasong]

#22512 was marked as a duplicate.

[bigdawggi]

Per-image-size cropping would be great to have in core. There's a plugin that does this currently, but inherent functionality would be excellent.

[tomauger]

Some thoughts on this one:

1. Having an intermediate image size appear as an option within the Image Editor UI should be opt-in. I have seen implementations with many, many intermediate image sizes, some of which don't need anything more than basic crop alignment (now supported in 3.9) and it got pretty hairy having them all in the Target editor group box.

function add_image_size( $name, $width = 0, $height = 0, $crop = false, $include_in_target_UI = false )

2. I think that when the crop is actually performed on a specific image size - the crop coordinates should be stored in the DB. This would allow us to still always display the full-size image (scaled down to fit in the editor as usual) but then load in the current crop as a starting point when a new image size is selected in the Target image editor group. This solves one of the big usability issues with loading the editor on, for example, the thumbnail version of an image included in the content editor, as you'll see right away the crop of the image.

3. You should be able to decide beforehand what image size you want to edit (when appropriate). For example, in the Image Details view for an image in the Editor, you get to choose which image size you want to use for the embedded image. This might be a good place to allow you to select which of those sizes you're actually editing for. Again, the full-size image would be the one displayed, but the crop would default to the crop selected for that image size.

[acorderob]

I would like to see an optional manual hotspot setting so that crops could be directed at the important part of the image. This hotspot could be a rectangle containing the minimum part of the image that should be contained in all crops.

This way the images would always have the correct content, even when regenerating them after a theme change.

It could also be extended to allow several hotspots with priorities, so that for example an image with two people, one on each side, and hotspots on both heads, could be converted to a square crop using only one hotspot and to a horizontal crop using both of them. This means trying to fit the most hotspots that the combination of the aspect ratios of the crop and the original image allows.

[MikeSchinkel]

Repeating what I wrote ​here:

1. Core needs to add a concept of “Image Type” that can be added using PHP code, i.e. maybe something like:

add_image_type( $type, array( 
  'label' => $label, 
  'sizes' = array( 
    'small' => '75x75', 
    'medium' => '200x150', 
    'large' => '500x300', 
    'xlarge' => '1024x768'
  )
));

This would allow core to generate only the sizes needed for those types, allow for easier filtering of images (by type) and empower plugin and core developers to enhance UX for functionality related to images. Examples of types might be 'headshot', 'hero', 'featured' and so on.

2. Once we have image types and sizes, filenames could be augmented with that information, i.e. instead of jsmith-500x300.jpg it could be renamed to jsmith-large-headshot.jpg.

3. And if core does not do 2., at least it could remove the sizes from the filenames when it resizes a file so that you don’t get this kind of name jsmith-500x300-75x75.jpg but instead just jsmith-75x75.jpg.

4. Note the sizes I included above are not the same aspect ratios so it would be nice of by setting those sizes for a type that WordPress core would present a UI to the user to crop those sizes separately.

5. It would really be nice if core could add an option to generate image files on demand the first time an image is externally accessed rather than on upload so that you don’t end up for an order of magnitude more image files on disk then are actually ever used.

Wasn't sure if I should post this as a separate ticket or not...