WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 6 months ago

#21038 closed feature request (worksforme)

Provide an option for creating 2x images of user content (for Retina Displays)

Reported by: twam Owned by: joemcgill
Milestone: Priority: normal
Severity: normal Version: 3.4
Component: Media Keywords: responsive-images close
Focuses: Cc:

Description

Providing high-res images for Retina enabled devices like iPad, iPhone or Macbook Pro is rather easy with retina.js (http://retinajs.com/).

The only thing needed is a @2x version of all images. It would be nice to have an option on the image uploader to enable generation of this images.

This should be rather easy to implement, it would make life much easier.

Attachments (1)

theme.php.patch (1.6 KB) - added by desrosj 4 years ago.

Download all attachments as: .zip

Change History (34)

#1 in reply to: ↑ description @jane
4 years ago

  • Component changed from General to Media
  • Keywords needs-patch added
  • Version set to 3.4

Replying to twam:

This should be rather easy to implement

@twam: If you can write a patch for this, it sounds like a good idea.

#2 @ocean90
4 years ago

This should be rather easy to implement,.

Really? Simply scalling up the image is not really a solution. Seems like a @2x version of the image should be uploaded and @1x version can be generated. And what about the thumbnails?

Also for me it sounds like plugin material.

#3 follow-up: @twam
4 years ago

The linked retina.js scripted makes it that simply. After loading the complete website, it checks if the device supports the retina images and then reloads the high-res pictures for every picture available.

So we just need to supply those @2x images for all images (and even for thumbails).

#4 in reply to: ↑ 3 @helenyhou
4 years ago

Replying to twam:

So we just need to supply those @2x images for all images (and even for thumbails).

You might mean this, but not all images so much as the ones that are large enough to create 2x versions.

#5 follow-ups: @dd32
4 years ago

This sounds like Theme/Plugin material to me, for one simple reason: Many sites will not make use of these images, that, and it's not that hard for Themes/Plugins to request larger sized images.

Now, because 2x is all the rage amongst some people today, what we can do, is make it easier for Themes/Plugins to request the generation through add_theme_support() or similar, which would probably just do an add_image_size() for the existing images, and mark the image as a 2x for the 1x alternative.

Different JS libraries are implementing this differently It seems, some rely on a data param on the <img/> some just check to see if a larger image exists with a pre-determined template, and others store a array in JS of the images which have 2x images available for them.. so there's plenty of different ways things can be used that we'll need to look at supporting.

#6 @ocean90
4 years ago

  • Keywords close added

#7 @nacin
4 years ago

  • Milestone changed from Awaiting Review to 3.5

Not a task, but it's something we can consider for 3.5.

#8 in reply to: ↑ 5 @desrosj
4 years ago

  • Cc desrosj@… added

Replying to dd32:

Now, because 2x is all the rage amongst some people today, what we can do, is make it easier for Themes/Plugins to request the generation through add_theme_support() or similar, which would probably just do an add_image_size() for the existing images, and mark the image as a 2x for the 1x alternative.

I have created a plugin that uses this method. There were a few areas that were difficult for me to find an appropriate hook to use though, the gallery thumbnails for example.

I would be happy to help contribute to this! Plugin: http://wordpress.org/extend/plugins/simple-wp-retina/

#9 @nacin
4 years ago

  • Keywords close removed

#10 @desrosj
4 years ago

Minimally we could do something like this?

@desrosj
4 years ago

#11 in reply to: ↑ 5 @TigrouMeow
4 years ago

Replying to dd32:

This sounds like Theme/Plugin material to me, for one simple reason: Many sites will not make use of these images, that, and it's not that hard for Themes/Plugins to request larger sized images.

That's a good point, and I agree. Plus if you want to support the high-res displays you need a lot of work, as different people would use different methods and it's far from being just a little patch. I'm actually the developer of the plugin WP Retina 2x and I debugged + enhanced the plugin thanks to 30-40 WP users who contacted me about it. It started simple but grew a lot during the last weeks, to cover all the requirements. It seems now it is really stable and the plugin satisfies a lot. You can have a look at it here: http://wordpress.org/extend/plugins/wp-retina-2x/.

#12 @markoheijnen
4 years ago

This ticket should be closed in my opinion. It's defiantly plugin/theme material. However we should make it easier to generate those images.

A lot of people will not even use these images if we create them. What happens is creating a lot of images that will not get used an only will result in the need of more disk space.

#13 @Otto42
4 years ago

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

#14 @aaroncampbell
4 years ago

  • Cc aaroncampbell added

#15 follow-up: @Otto42
4 years ago

Image replacement proposal:

Basic outline: Use Javascript image replacement to dynamically replace images that have HiDPI versions available with the larger images.

How to do it:

  • For every image size, generate a HiDPI version at 2x the size if the following conditions are met:
    1. No larger image exists that is at least 2x the desired size, and which has the same cropping conditions.
    2. The "full" image is large enough to support such a resizing.

To simplify, if we have a thumbnail which is 150 wide and not-cropped, then as long as the medium or large size is at least 300px wide and not-cropped, then we don't have to generate a special hidpi-thumbnail image size, since we can simply use the next larger size.

This does mean that we will most likely always need to generate a hidpi-large size that is twice the size of the large size, if the full version is large enough to allow us to do it reasonably.

Next:

  • When inserting that image into the editor, include a data-hidpi-url or similar to provide the browser with the URL of the hidpi version of that image. Since we already include appropriate width/height tags, then the larger image will be displayed correctly at that width/height.
  • For the case where no hidpi version is available or can be created, then simply do not include the data-hidpi-url tag.

Finally:

  • Use some small static JS code inserted into the header or footer to scan for data-hidpi-url tags and do the image replacement for appropriate browsers. Ideally do this without the use of jQuery.

Notes:

  • This intentionally does not cover handling existing posts. Only "new" posts would be covered by this. Older posts don't have the images generated properly, and also won't have the data-hidpi-url in their HTML. A plugin can go retro-fit older posts, if desired. Perhaps add it into the various regen-thumbnail plugins.
  • Same image replacement code with the data-hidpi-url could be used to handle img tags for the custom-headers in #21389.

Finally:

  • All of the above can be made into an "option" on the Settings->Media page if it's felt that it's worth it. Ideally, this approach would be fully backwards compatible and not break anything, but some people may feel it's not worth having the (most likely just one) extra image generated.

Suggestions welcome.

#16 @travisnorthcutt
4 years ago

  • Cc travis@… added

#17 in reply to: ↑ 15 @travisnorthcutt
4 years ago

Replying to Otto42:

  • For every image size, generate a HiDPI version at 2x the size if the following conditions are met:
    1. No larger image exists that is at least 2x the desired size, and which has the same cropping conditions.
    2. The "full" image is large enough to support such a resizing.

What do you think about amending #1 to say e.g. "No larger image exists that is at least 2x (but no more than 2.nx) the desired size, and which has the same cropping conditions" (where n is some reasonable number... perhaps ~2)?

My reasoning: say the desired image size is 300x300, and you have image sizes defined at 150x150, 300x300, and 1200x1200. Without the amendment, when a HiDPI-capable device requests an image that would otherwise be served at 300x300, then the 1200x1200 would be used (and presumably shown at 300x300). That seems like a pretty big waste of bandwidth.

#18 @Otto42
4 years ago

To that I would say that it's probably not worth generating the 600x600 image at first, simply because of the very low number of HiDPI devices out there. It's a fraction of a percent of the total viewers, at present.

#19 @travisnorthcutt
4 years ago

So basically you'd prefer to only generate a 2x image for the "large" image size (barring any additional sizes defined by the theme or plugins)? Assuming, of course, that the full size image is big enough to do so.

#20 @travisnorthcutt
4 years ago

Another question: why not just use retina.js as mentioned above? Wouldn't that eliminate a lot of complexity? (Avoids having to insert extra attributes in the editor, for one, and avoids having to write any js).

#21 @nacin
4 years ago

  • Milestone changed from 3.5 to Future Release

Per the IRC meetup yesterday, HiDPI support for user-uploaded images is no longer part of 3.5's scope, due to the complexities of implementation. With the media UIs and image APIs improving quite a bit in this release, it ideally becomes more feasible in a future version. It is unfortunately too much at once to try it in 3.5 while everything it would be built upon is also shifting around.

Combined with the fact that HiDPI support everywhere on the internet remains a total hack, this also gives browser makers and standards bodies some more time to come up with a sane way to handle HiDPI support.

Otto42 will be watching #21390 (and related tickets) closely to make sure the right hooks are in place so this can be attempted in a plugin.

This applies to #21038 (user content), #21455 (backgrounds), #21389 (headers).

#22 follow-up: @Otto42
4 years ago

@travisnorthcutt:

I'd prefer to avoid creating an extra 2x image for every image size, doubling the number of images created on upload, yes.

The JS replacement technique is one I plan on using, however retina.js and similar varients are simple-stupid solutions that cause extra server load. Basically it hits the server to ask if an "@2x" image exists for every image on the page, and does replacement then. With the proposed method, we can create the 2x images only needed (reducing number of images) and cause JS replacement to occur only on the images where 2x images exist (eliminating the extra server hit overhead).

Essentially, we can be smart about it instead of using brute-force "dumb" solutions. So why not make it more intelligent overall?

With any luck, browsers will implement the srcset attribute on images (or something similar) and eliminate the need for JS hackjobs like this anyway.

#23 @Otto42
4 years ago

BTW, the Community Group seems to be leaning towards a new PICTURE element instead of srcset. Worth a read:
http://www.w3.org/community/respimg/

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

#24 in reply to: ↑ 22 @travisnorthcutt
4 years ago

Replying to Otto42:

@travisnorthcutt:
cause JS replacement to occur only on the images where 2x images exist (eliminating the extra server hit overhead).

Thanks, that makes sense.

Also, FWIW, I'm not suggesting we create a 2x image for every size, only for ones that don't already have a (roughly) 2x image (as a result of the larger size also being a defined image size). I think many cases would be covered by e.g. medium being ~2x small, large being ~2x medium, and only needing to generate a new 2x for the "large" size.

#25 @ericlewis
2 years ago

  • Keywords needs-patch removed

srcset is in Working Draft status1 and is only implemented by Chrome and Opera2.

I think a first step here is to make 2x versions of every image size where possible.

This ticket was mentioned in Slack in #feature-respimg by nacin. View the logs.


16 months ago

#27 @wonderboymusic
8 months ago

  • Keywords responsive-images added
  • Milestone changed from Future Release to 4.4
  • Owner changed from Otto42 to joemcgill

Let's see what can be done here

#28 @TigrouMeow
8 months ago

Are you going to kill my good old' plugin? ;) (WP Retina 2x) Retina is a lot of work, I am working on it everyday, it is not only a piece of code that generate files, that should also be working with CDN and depending on many things, let the user know for which he has Retina or not, opt image sizes out, etc... I kind of feel it would never be in the WP core because of this complexity and the related screens it would require.

#29 @markoheijnen
8 months ago

I'm unsure about adding this at all and at this stage.

The first thing I believe that most users will not care much about it. If it will be a theme support then this should rather be a plugin since most users will not do it. That said I do expect that users will notice the difference in quality. Looking at WP Retina 2x) with 100k active installs.

Handling images is really tricky and the way WordPress handles isn't optimized for disk space. Since a lot of our users are on shared hosts, not having a cleanup mechanisme could easily become a danger to get the disk space to full. Specially since this images aren't small ones. I rather look at what we could do in this area first. We could see what we can do for #15311 which would be step 1.

I would disagree with @TigrouMeow that it isn't complex for CDN since the urls will be different. Also no extra screen should be required. Using the srcset should make things much easier.

Side note:
For my sites I switched to Thumbor (python image server because it makes things so much easier. Currently it auto detects .webp but I could easily just drop all sizes in a picture element. If wanted you could build in support for delivering retina images. Since it has it's own cache, it will clean things up and regenerate if needed. Obviously this isn't for the average WP user but I support for retina could be describe in the same way.

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


7 months ago

#31 @joemcgill
7 months ago

  • Keywords close added

As of #33641 content images automatically have all applicable intermediate sizes included in a srcset attribute using w descriptors. This means that any device with a high density display using a browser with support for srcset and sizes will load the larger version of the image automatically as long as a one is available.

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


7 months ago

#33 @wonderboymusic
6 months ago

  • Milestone 4.4 deleted
  • Resolution set to worksforme
  • Status changed from assigned to closed

This works now but requires themes/plugins to provide. I think that suffices.

Note: See TracTickets for help on using tickets.