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?
5 Likes
Not at the moment, no, since you can click or tap the image to see it full size anyway.
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.)
3 Likes
This for me is the only annoyance I encounter daily on otherwise amazing forum software.
Example: http://forums.tumult.com/t/on-any-timeline-complete-action/1753
(The screenshot looks not so beautiful)
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.
2 Likes
srcset is arriving in iOS9, and already works in Chrome and Firefox: http://caniuse.com/#search=srcset
http://www.w3.org/html/wg/drafts/html/master/semantics.html#attr-img-srcset
<img src="fallback.jpg" srcset="mobile.jpg 320w, desktop.jpg 640w" />
The holdout is IE (it’s partially working in edge).
6 Likes
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?
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.
1 Like
@zogstrip was the re-compression somehow configurable ?
1 Like
This is now implemented!!! 
Before:
After:
per:
https://github.com/discourse/discourse/commit/ad0e7687428ef11625632c0ae1a283a095529d1a
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.
16 Likes
Hmm so it generates
<img
src="//xxx/optimized/3X/2/2/guid_1_521x500.png"
alt="image"
width="521"
height="500"
srcset="//xxx/optimized/3X/2/2/guid_1_521x500.png,
//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.
2 Likes
@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 
3 Likes
This topic was automatically closed after 5 days. New replies are no longer allowed.