17

The current image handling is minimal, there is no rescaling a all and the full image is simply scaled to the width of the post.

This works well until you have images that are wider than the 640px available for posts. There are two important categories of images that pretty much always break this limit: Pictures taken with a digital camera and screenshots. Sites that would benefit from an improvement here would be especially Photo.SE, Arqade, DIY and other image-heavy sites.

The current result of this for inexperienced users is that they put the full-sized image in the post. This means a waste of bandwith for everyone looking at it, and also makes the full-sized image not accessible to non-technical users.

An experienced user will rescale the image before uploading. This takes more time and also makes the full-sized version of the image unavailable for everyone.

A very experienced SE user can work around the whole thing and use the automatically created thumbnails from imgur to create a preview image linked to the full-sized one. This is only known to very few users, it is not discoverable and quite a lot of work.

I'll use a project from a developer that is rather well-known around here as an example how the image handling could be done better: Improved Image Handling in Discourse.

When uploading an image

  • it should be rescaled automatically to the width of the post
  • the image should be linked automatically to a lightbox (or to a new tab) that will show the image in the maximum possible size on the screen.

There should be no need for a user to do any manual work, this should just work automatically.

|improve this question
  • I know that there are existing feature requests on rescaling, but none that I found that propose a lightbox-like solution. – Mad Scientist Jul 18 '13 at 12:42
  • Maybe this one? Support showing image in original size in overlay – Cody Gray Jul 18 '13 at 15:42
  • 4
    Man, am I the only one who hates Lightboxes? – slhck Aug 2 '13 at 9:10
  • 2
    Hey there. We are looking into automatically linking to images as they are uploaded. This isn't a lightbox, but it's simpler and done commonly enough on the site to be worth it (it's also less divisive than lightboxes). Rescaling the image is a more complex problem, considering that "the width of the post" depends on whether the user is on web or mobile. I'll mark this as status-planned for now, though in practice we're only addressing half of your request. – Thomas Orozco Jul 14 '15 at 16:12
  • @Thomas still, half more than most feature requests... – Shadow Jul 14 '15 at 17:42
  • This is now live! From now on, the image uploader automatically wraps images in a link to themselves. Balpha is to thank for this change. I have updated your question to status-completed, but let me know if you don't find that a satisfactory resolution and I'll update it back. – Thomas Orozco Jul 22 '15 at 13:14
  • @ThomasOrozco You might want to add this in the form of some kind of canonical answer to the relevant questions (or at least one of them and link to that from the others). – Christian Rau Jul 22 '15 at 13:15
  • @ChristianRau That is very good suggestion ;). Will do. – Thomas Orozco Jul 22 '15 at 13:16
4

This is now live! From now on, the image uploader automatically wraps images in a link to themselves, which looks like this:

[![enter image description here][1]][1]

Success!

Balpha is to thank for this change.

|improve this answer
  • 1
    @ᔕᖺᘎᕊ It only includes a link to the image. The reason we cannot render a smaller image is because the "right resolution" isn't a constant (it depends on mobile vs. desktop, etc.). We've investigated using a smaller resolution in the posts, but this is a significantly more complex change, so we're not there yet. – Thomas Orozco Jul 22 '15 at 13:23
  • Does this only kick in if the image is significantly larger than it would be on the page or does it always create the link? – Christian Rau Jul 22 '15 at 14:05
  • @ChristianRau Always: this changes the markdown (and can therefore be removed), and whether the image is too large or not isn't something we know at markdown generation time. – Thomas Orozco Jul 22 '15 at 14:13
  • One quirk I discovered: If you add one image, both links use the same number [1]. But when you add a second image, the first image gets two separate numbers (whether it's [1] and [2] or [2] and [3] depends on where the new image is inserted). To test it out, edit in a second image on this post. It bugs my less is more mentality. Also (and I can't think of a good fix for this), I prefer the inline link style ([example text](http://example.com)) and this change makes it a bit harder to edit. – Jon Ericson♦ Jul 23 '15 at 17:24
  • 1
    When I see that an image is hyperlinked, I assume it's on purpose: clicking it will lead me to some additional information (such as full size image, or a video from which the image is taken, etc). The new approach defeats this expectation by making everything hyperlinked, most of the time without a reason. The Markdown sources are now uglier too. And all this is to save -- on rare occasion when it's needed -- the trouble of right-clicking and opening full image in another tab? With the new system, I am probably still going to open in another tab, because I need the text of the question too. – user259867 Jul 23 '15 at 17:34
  • @JonEricson Good point. This is arguably a more generic problem / separate issue: if you used the same link multiple times in a post (images or not), inserting a link or an image actually rewrites those (e.g. if your post is [test][0] [test][0] [test][0]\n[0]: http://test.com, inserting a new link won't preserve the existing one). – Thomas Orozco Jul 23 '15 at 17:35
  • The point of the feature request was that the embedded image would be a smaller copy, server-resized. This isn't happening, as you said. As long as the full size image is already embedded in the page, an explicit link to the same content brings redundancy and confusion without a benefit. – user259867 Jul 23 '15 at 17:36
  • Thanks for your feedback @NormalHuman. Here are a few counterpoints I'd like to offer (of course, I'm not trying to convince you that you should like this change, but I hope you'll understand why we made it). 1.: There were other posts that requested it and had positive feedback (here, here, here). 2.: we observed that this was a common pattern on existing posts. (cont.) – Thomas Orozco Jul 23 '15 at 19:17
  • 1
    (cont.) 3. whether the image displayed in the post is full-size or not is device-dependent (and so is resizing), and the decision to wrap it in an link or not would have to be done at post rendering time (before we know what device is looking at the image), so while conditionally choosing whether to wrap the image in a link would be ideal, it's also significantly more complex (it'd have to happen client-side). Now, we've recently noted that this change interacts poorly with our mobile apps, so there might be some upcoming adjustments. – Thomas Orozco Jul 23 '15 at 19:18
  • <s>Maybe you could use HTML5's <picture> tag and add the different sizes in <source> tags, and a full-size <img> as a fallback, as well as having the image link to the full-size version?</s> Or you could use <img srcset="...">. – Solomon Ucko Apr 3 at 3:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .