Retina image inline attachments

(Larry Salibra) #1

Inline image attachment thumbnails in Discourse are only generated for 1x pixel density screens.

Is there any work being done (or planned) to support thumbnails for higher pixel density screens?

(Jeff Atwood) #2

Not at the moment, no, since you can click or tap the image to see it full size anyway.

(Jakob Borg) #3

This is kind of sad, as when writing a post and uploading an image that is showed full-width (i.e. as wide as the text column), it looks really nice. Then you save, and a few moments later the baked version of the post comes back, replacing the nice illustration/screenshot/photo with a blurry horror. So I wouldn’t call this “thumbnails” as such, even though they are indeed clickable. Often the click isn’t expected, when the image is used as an illustration in the post.

An option to have the locally cached / regenerated images be created at 2x resolution would be nice. Many forums would perhaps prefer to not do this and save the bandwidth so the default could be as it is today. But for forums where images are a common thing and quality is desirable, this would be nice.

(Bonus points for generating both and only serving high resolution images to high-DPI screens, but still.)

(DanielMorgan) #4

This for me is the only annoyance I encounter daily on otherwise amazing forum software.

Example: On Any Timeline Complete Action - Animation - Tumult Forums

(The screenshot looks not so beautiful)

(Jeff Atwood) #5

I believe there is an emerging way in HTML to do this, where you specify alternate URLs for different, higher pixel density images and the device uses the correct one rather than blindly serving up 4x larger images to everyone.

That’d be preferable, so my desire here is to wait and see that be more widely supported.

(DanielMorgan) #6

srcset is arriving in iOS9, and already works in Chrome and Firefox: Can I use... Support tables for HTML5, CSS3, etc

<img src="fallback.jpg" srcset="mobile.jpg 320w, desktop.jpg 640w" />

The holdout is IE (it’s partially working in edge).

(Jakob Borg) #7

Could we enable this as an experimental feature or something? Perhaps keeping the unmodified image around too and serving it in the the srcset if it’s larger than the rescaled version Discourse creates?

(Thorbjørn Lindeijer) #8

Since I upgraded to a 4K HiDpi screen this is also my main annoyance with Discourse. Every time I upload a screenshot, it first looks great but then gets replaced by an ugly blurry version created for low resolution displays.

Clicking on the image for the large version doesn’t help much, because it makes it too large. It serves the original image but the browser will interpret it as a low resolution image and applies the scaling, making it a huge blurry image.

(Sam Saffron) #9

@zogstrip was the re-compression somehow configurable ?

(Sam Saffron) #10

This is now implemented!!! :confetti_ball:




We resize to 1.5x and 2.0x when creating the SRCSET. You can configure this as needed using the responsive post image sizes site setting.

(Jeff Atwood) #11

Hmm so it generates

          //xxx/optimized/3X/2/2/guid_1_781x750.png 1.5x, 
          //xxx/optimized/3X/2/2/guid_1_1042x1000.png 2.0x"

I noticed the srcset URLs in the output sometimes start with // and sometimes https:// … is that intentional?

It looks like you can use 2x instead of 2.0x to save two bytes there, per the documentation on srcset.

(RĂ©gis Hanol) #12

@sam already fixed it in Missed one spot where url needed cooking · discourse/discourse@eba3117 · GitHub

I rebaked the post and all the URLs are clean now :ok_hand:

(Sam Saffron) #13

This topic was automatically closed after 5 days. New replies are no longer allowed.