WordPress.org

Make WordPress Core

Opened 22 months ago

Last modified 20 months ago

#21038 assigned feature request

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

Reported by: twam Owned by: Otto42
Milestone: Future Release Priority: normal
Severity: normal Version: 3.4
Component: Media Keywords: needs-patch
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 21 months ago.

Download all attachments as: .zip

Change History (25)

comment:1 in reply to: ↑ description jane22 months 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.

comment:2 ocean9022 months 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.

comment:3 follow-up: twam22 months 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).

comment:4 in reply to: ↑ 3 helenyhou22 months 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.

comment:5 follow-ups: dd3222 months 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.

comment:6 ocean9022 months ago

  • Keywords close added

comment:7 nacin21 months ago

  • Milestone changed from Awaiting Review to 3.5

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

comment:8 in reply to: ↑ 5 desrosj21 months 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/

comment:9 nacin21 months ago

  • Keywords close removed

comment:10 desrosj21 months ago

Minimally we could do something like this?

desrosj21 months ago

comment:11 in reply to: ↑ 5 TigrouMeow21 months 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/.

comment:12 markoheijnen21 months 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.

comment:13 Otto4221 months ago

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

comment:14 aaroncampbell21 months ago

  • Cc aaroncampbell added

comment:15 follow-up: Otto4220 months 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.

comment:16 travisnorthcutt20 months ago

  • Cc travis@… added

comment:17 in reply to: ↑ 15 travisnorthcutt20 months 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.

comment:18 Otto4220 months 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.

comment:19 travisnorthcutt20 months 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.

comment:20 travisnorthcutt20 months 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).

comment:21 nacin20 months 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).

comment:22 follow-up: Otto4220 months 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.

comment:23 Otto4220 months 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 20 months ago by Otto42 (previous) (diff)

comment:24 in reply to: ↑ 22 travisnorthcutt20 months 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.

Note: See TracTickets for help on using tickets.