143

Update on the Imgur migration, May 15th 2024

The work described in the Imgur URL migration post will be under way shortly. The rollout will take place gradually over the next week or so, give or take a few days. Please report if you run into any issues loading images from Stack Exchange via i.sstatic.net.

Update on the Imgur migration, May 7th 2024

Last week, we completed work migrating existing images out of Imgur into our new image service. Starting next week, we are moving into the final phase of the migration, and will begin rolling out updates to replace Imgur links (i.stack.imgur.com/<image ID>) with the new i.sstatic.net domain.

Similar to the initial rollout of the new image service, we are planning a staged rollout for the final phase, so that we can monitor for any issues during the rollout process. For more information, please see this Meta post.

Update on the Imgur migration, April 29th 2024

As of today, we have rolled out the new image uploader to chat. It looks like this deployment is stable and holding well, and we will continue to monitor error rates, as well as Meta Stack Exchange. This deployment concludes phase one of the migration. All image uploaders across the Stack Exchange network should now point to our internal image hosting service.

We are now transitioning to the next phase of this project. Our priority is now to migrate images from Imgur and update the corresponding URLs across the Stack Exchange network. We plan to provide you with some advance warning once we know when we will be editing old Imgur links to point to our image hosting service - this date is not yet firm.

Update on the Imgur migration, April 25th 2024

As of today, we have rolled out the new image uploader to Stack Overflow, Metas, and the international Stack Overflow sites, and plan to transition chat to the new uploader early next week.

We'll keep a close eye on the error rate to ensure a smooth transition as we mark the completion of the migration's initial phase. There is still work to do, and your patience and support throughout this project is greatly appreciated. Rest assured, we will continue to keep you updated on ongoing progress.

Update on the Imgur migration, April 23rd 2024

As of today, we have rolled out the new image uploader to every site, excluding Stack Overflow and international Stack Overflow sites. We will monitor the error rate and update when the full transition is complete.

Update on the Imgur migration, April 15th 2024

Due to an elevated error rate discovered at launch time, we delayed the network-wide deployment of the new image uploader from its planned time during the week of April 8th (last week, as of this update). Our new plan is to enable the image uploader on all non-Stack Overflow sites this week, followed by Stack Overflow sites early next week. This plan may shift a few days in either direction as needed to accommodate internal release scheduling. With the exception of the modified release timeline, all the details from the below update remain accurate.

Update on the Imgur migration, April 8th 2024

This week, we will wrap up the first phase of our rollout process by deploying the new image uploader to all sites network-wide. Beginning today, all sites and their Meta sites except Stack Overflow and non-English Stack Overflow sites will use the new image uploader. Later in the week, we will complete the rollout by deploying the new image uploader to all remaining sites, including Stack Overflow.

Once the rollout is complete, all new images uploaded to the main sites should use the new i.sstatic.net image hosting endpoint. (For Chat fans - hang on a bit longer, it’s coming.) As always, please let us know if you encounter any unexpected issues, preferably on a new report Meta post.

We are currently on track to complete all required work for this migration on time.

Update on the Imgur migration, April 3, 2024

The first phase of our rollout process, detailed in the update below, is now under way. This will be a staged rollout, beginning with a few smaller sites around the network to ensure that everything works as expected. Please let us know if you encounter any unexpected issues, preferably on a new report Meta post.

Update on the Imgur migration, March 13, 2024

As we have outlined in this post previously, we are working towards an in-house solution for Stack Exchange’s image-hosting needs. This message is to provide an update on that process.

To date, we have successfully completed the following:

  • i.sstatic.net will be used as our new image upload endpoint
  • Updated image uploaders via profile pages, post-editors
  • Support for uploading photos from external URLs
  • Image resizing with s|m|l and additional resizing with ?s= parameter
  • Sensitive EXIF data removal

There is still a lot to be done, but we are working diligently and believe all should be in place before the migration so that this transition does not disrupt the daily workflow of the network.

Our current plan is to switch over to the new image uploader within the next few weeks. This will be a staged rollout, beginning with at most a few smaller sites around the network to ensure that everything works as expected. We’ll then roll the new uploader out network-wide. Following that, we will begin the process of transferring existing Imgur images into our new image hosting service.

We will continue to update this post during each phase of the migration to our own in-house image hosting.


Since 2010, Imgur has provided image hosting services to Stack Exchange, but that hosting contract with Imgur comes to an end this upcoming April 2024. This April will conclude a 13-year-long successful relationship between Imgur and Stack, for which the whole company has been deeply grateful. However, Imgur no longer provides an enterprise image hosting product, and therefore, it has come time to find an alternative solution.

This post serves as your advance notice that this change is coming down the pipeline. This post is coming to you very early - so you have time to prepare. Here’s a rough sketch for how the next few months are going to look.

We are working on a plan to develop a solution to the image hosting problem. The exact implementation details are still being finalized, and we are in the research and discovery phase for a new image hosting solution. An internal proof-of-concept will inform the image hosting provider we ultimately settle on, and we expect this preliminary work to conclude some time in December of this year. Once our image hosting concept is proven out, we will transition to developing the solution we’d like to hold for the long term. We are aiming to complete core work on this new solution before the end of March 2024. However, as we are in the proof of concept stage, this schedule may shift considerably.

Some time in late December or early January, after proof-of-concept work completes, I will update this post to contain more details on how our solution will work, the sort of impact it will have on the network (if any - ideally very little), and the timeline on which that work will be completed.

For now, if you’ve got concerns about this change, feel free to leave them in answers below and we’ll answer them as best we can. Bear in mind that our plans are not settled yet, so our ability to answer technical or implementation questions may be limited.

Kyle Pollard, who is working on this project, has given more updated information about the transition in an answer post here.

25
  • 18
    Will transitioning and mass-editing of existing pictures/posts be taken care of by the devs/CMs?
    – Mast
    Nov 28, 2023 at 18:38
  • 34
    @Mast Data integrity is among our top priorities. At this point in the process, we do not anticipate any need for community-driven reuploading or preservation efforts.
    – Slate StaffMod
    Nov 28, 2023 at 18:43
  • 31
    @Joachim There are a lot of reasons to discuss early even with so few details. See who in the community is interested, check to make sure we've identified the main concerns, make sure the change will be received in the normal and routine way we expect, help folks with niche or narrow needs prepare... in short, so that (hopefully) neither we nor you are surprised when it happens. And, yes, emotional preparation. It's a large migration, so some anxiety is natural. We don't want people to worry more than is necessary, which can happen if caught off guard.
    – Slate StaffMod
    Nov 28, 2023 at 20:14
  • 1
    I can't edit it for you (any more) but it probably would better to have/use a transcript link for the room-for-starball-and-slate Nov 28, 2023 at 23:41
  • 45
    @Joachim Most mods and community members have been barracking for this exact style of announcement for years - announce things early enough so we can identify any missed points, any opportunities, or potential pitfalls. The alternative is getting an announcement like "We've had to move off imgur, the work is all done and it's too late to change anything now, so... hope you're happy!" in April 2024.
    – Robotnik
    Nov 29, 2023 at 3:36
  • 4
    @Robotnik Oh, that was not at all meant as a critique on the announcement, just on the word "preparation", since to me it felt like it implied the basis for a more practical readiness than could be gathered based on the information alone. Basically, it only talks about the (big) change(s)—which, obviously, is (are) very good to know about in advance—but it doesn't yet contain the practical information we could use to actually get into action.
    – Joachim
    Nov 29, 2023 at 12:15
  • 1
    @TylerH Now that would be something this post could have pointed out to begin with, but how "very easily" could it go wrong? I assume a proper alternative will be found long before Imgur deletes all images linked to on the SE network, and that SE will at least temporarily have a backup (apart from the data dumps and the good old Internet Archive).
    – Joachim
    Nov 29, 2023 at 20:06
  • 1
    @Joachim apparently they can download a backup mirror. see meta.stackexchange.com/a/291682/997587 Nov 29, 2023 at 20:09
  • 8
    @Joachim They have millions of URLs to scan and replace, and close to a million image files to replace on a file server. They have a new file upload process with multiple restrictions to design and implement. That's a lot of work to do, where a problem along the way can cause serious issues for anything that is supposed to occur afterward.
    – TylerH
    Nov 29, 2023 at 20:43
  • 2
    @Slate In case your weren't aware of it, Impact on CircuitLab schematic integration of moving from Imgur to a different image hosting service is a question I raised on the Electrical Engineering stack meta about the impact on the Circuit Lab schematic editor integration with Imgur, which is specific to the Electrical Engineering stack. That question was given a status-review tag by a moderator, but I not sure who monitors that tag. Jan 21 at 16:51
  • 3
    @ChesterGillon [status-review] sends the post over as a Jira ticket to staff. I'll find that post and send it over to the dev team. At first blush I want to say that anything currently on Stack Exchange will be fine (the image links should remain valid after the migration), but that we might not support whichever method CircuitLab is using to generate i.stack.imgur.com links - they will probably need to update that. But it's possible I'm not quite understanding how this integration works, since I haven't encountered it before.
    – Slate StaffMod
    Jan 22 at 15:13
  • 1
    @SonictheAnonymousHedgehog I read them, yeah
    – Slate StaffMod
    Feb 11 at 19:36
  • 1
    @JNat When you talk about deploying the new image uploader to a site, does this also include the user profile editor on the site? I tested it out on a site where the new uploader was deployed and it still uses Imgur. Apr 10 at 19:38
  • 1
    All new images uploaded should use the new service, @SonictheAnonymousHedgehog, regardless of which portion of the site you uploaded them from. Old images would still show imgur, though, because those haven't been migrated yet.
    – JNat StaffMod
    Apr 11 at 16:13
  • 5
    Just a quick question: why is the minimum upload size 160x160px? In several of my posts on tex.stackexhange.com, the needed images are significantly smaller, so that I have to pad them with white pixels...
    – Rmano
    Apr 13 at 8:52

24 Answers 24

79

I met with Imgur yesterday and have some more information to share.

The total scope of the data on Imgur is (and these are just rough stats):

  • ~2.6 TB of images
  • ~48 mil individual images
  • ~1.5k requests per second during peak traffic

They plan to give us full control of the *.stack.imgur.com subdomain, which we plan to point at our own servers to take care of the redirection. We're hoping to redirect requests to a subdomain of sstatic.net or another domain we control. Instead of relying on this redirect, our preference will still be to update any existing images to point to the new domain. We plan to edit the content automatically when we switch over.

We're also working on a migration plan with them. They're working on supplying us with a full list of the IDs in their database so we can ensure that we've moved everything over. When we've received that, my strategy will be to iterate over each of these IDs, see if they're in our own backup, and if not fetch them directly from Imgur. This migration happens later in the project once we've built out a proof of concept, though.

Fun fact: they said their company name is pronounced Image-urr, as in "they're images, and they're yours. Image your!". One dev also said that gif was pronounced "gif" and not "jif", but I'm not sure if that's an official company position or not. 🤠

11
  • 18
    Physical meeting? Did they serve cookies? ;) Dec 1, 2023 at 21:08
  • 10
    Not a physical meeting unfortunately, though I did eat some Bear Paws
    – Kyle Pollard StaffMod
    Dec 1, 2023 at 21:26
  • 17
    dumb question. 2.6 tb isn't very much. Couldn't they just.. mail you over a dump of everything in a hard disk or two Dec 2, 2023 at 0:53
  • 18
    @ShadowWizardIsSadAndAngry considering it's the staff of two websites meeting, they could have served cookies even without meeting physically. Dec 4, 2023 at 13:32
  • 5
    @Karl finally someone got it! :D Dec 4, 2023 at 14:45
  • 9
    @JourneymanGeek I don't have specifics, but the cloud storage they have our images in is painful to iterate over and retrieve the images en masse. Since we have a backup, we're preferring to use that first then fall back to retrieving from Imgur.
    – Kyle Pollard StaffMod
    Dec 4, 2023 at 18:33
  • 4
    @KylePollard which is a great reason for them to talk to their cloud provider to get things shipped over in a drive and pass that on, especially for a one off. AWS even has 50TB appliances these days, or an entire truck for example. They're likely a big client of their cloud storage, and probably have... options. Dec 5, 2023 at 2:20
  • 3
    @JourneymanGeek we already have a backup of the images, so there isn't anything for Imgur to really hand off. Fetching directly from Imgur will be the exception, and only used if something technical is wrong with our backup. I see what you're saying though, and this could save us transfer costs from uploading from our backup to a cloud provider, but for now I'm not worried.
    – Kyle Pollard StaffMod
    Dec 6, 2023 at 21:22
  • 2
    image upload is now broken, did you start working on it early? Jan 30 at 10:21
  • 1
    I hope the dev who said that gif was not pronounced "jif" was summarily fired!
    – TylerH
    Jan 30 at 18:03
  • I know "u" means "you" in chat, but "ur" is new and I wouldn't guess to split imgur as "img ur" either. Thanks for fun facts.
    – Sinatr
    May 13 at 8:56
63

Imgur strips EXIF/metadata from images.

EXIF data/metadata is removed from all images upon upload. There is no setting available to retain the data.

I think we need to maintain that level of user privacy. Pictures from phones can (do) contain a LOT of identifying information and having that automatically removed by the system is important.

2
36

Questions

  1. How exactly will the lifetimes of the imgur images work? Do the image URLs just insta-rot in April 2024? And when do you expect the images on the new platform to be all copied over by?

    Image links will likely insta-rot [...] we're [...] focused on completing the migration in time. – Kyle Pollard

    [Imgur] plan to give us full control of the *.stack.imgur.com subdomain, which we plan to point at our own servers to take care of the redirection – Kyle Pollard

  2. What's going to happen to the pending feature-requests that have to do with images- especially those with relation to imgur hosting? If there are requests that had aspects that were tied to imgur as the hosting platform but can be generalized, should we re-raise the feature-request?

    In terms of extra feature requests, they're out of scope for now as we're just focused on completing the migration in time, but I'm happy to read any if you bring them forward. – Kyle Pollard

  3. Will there be any degree of URL / image ID stability? Ex. http://i.stack.imgur.com/12345.jpg can be translated to new-hosting-domain.com/12345.jpg.

    wizzwizz4 gave an example of a case where this could matter (in puzzles on puzzling that rely on them).

    I keep a list of i.stack.imgur URLs pointing to funny "screenshots" of code (people using their phone to take a picture of their laptop) that I stumble upon in the wild on SO, and while I've been lucky enough to also have kept track of the post IDs so that I can find them again even if the image URLs change, it'd be nice for other reasons:

    I plan on keeping the exact same IDs – Kyle Pollard

  4. Is there any possibility of getting Imgur to maintain a basic redirection endpoint?

    I ask this out of consideration for archives like the data dumps, which don't include images. Also like... the rest of the internet. Ex. google search link:i.stack.imgur.com -site:stackoverflow.com -site:stackexchange.com -site:imgur.com <etc.>, which turns up about 10M results. Compare that with searching for pages within SE that link to i.stack.imgur.com which is roughly 82M results. 10M is more than 10% of that. To put it lightly, it would be no small amount of negative impact to the rest of the internet if old links do not auto-redirect to the new links.

    It would suck for there to be no user-friendly, reliable way to get from an i.stack.imgur.com URL on a non-SE site or from the data dump to the new URL on the new hosting service.

    User friendly would be like if you could get Imgur to maintain a basic endpoint where they just redirect a request to http://i.stack.imgur.com/<path> to the new URL. There are different ways this could happen. If there's image ID stability, then the Imgur redirection endpoint could do it pretty easily. If there's no image ID stability, then you could keep a translation database from old to new image IDs, and the Imgur endpoint could redirect to a Stack Exchange endpoint that does that translation using the translation database.

    I don't expect we'll get redirects from Imgur but I'll ask them. – Kyle Pollard

    can we ask them to just make that a CNAME to some SE server that can then do the redirections? - muru

    This is exactly what they're going to do. - Kyle Pollard

  5. Assuming that you'll update links to images in comments, are you going to make sure that the new URLs can still fit within comment length limits for comments that link to images? If not, what's going to happen? unceremonial truncation?

    The comment length is an interesting edge case I hadn't considered, thanks for calling that out. – Kyle Pollard

Reminders

  1. Please be careful not to unnecessarily use the thumbnail URLs instead of the original-size URLs when transferring. I.e. don't transfer http://i.stack.imgur.com/12345m.jpg. Transfer http://i.stack.imgur.com/12345.jpg.

    We'll be using the original source image, not thumbnails – Kyle Pollard

7
  • 18
    Hey! I'm working on this project and can answer these. Image links will likely insta-rot, I don't expect we'll get redirects from Imgur but I'll ask them. In terms of extra feature requests, they're out of scope for now as we're just focused on completing the migration in time, but I'm happy to read any if you bring them forward. I really value the image ID stability too and plan to keep them in the same format, just a different host URL. The comment length is an interesting edge case I hadn't considered, thanks for calling that out. We'll be using the original source image, not thumbnails.
    – Kyle Pollard StaffMod
    Nov 28, 2023 at 19:48
  • 1
    @KylePollard about the feature-requests, my question was what to do with the question posts- not whether the features they're asking for will get implemented as part of this transition. Ex. meta.stackexchange.com/q/101439/997587 which actually doesn't have that much to do with imgur (should we just remove the imgur tag?), and meta.stackexchange.com/q/92568/997587, which is still a valid request, but should we re-raise it for the new hosting platform when whatever that platform is has been decided? or just edit the tag in that existing one? Nov 28, 2023 at 20:14
  • 1
    @KylePollard "I really value the image ID stability too and plan to keep them in the same format" can you spell out whether the IDs will be stable or not? same format does not necessarily mean stable IDs. Nov 28, 2023 at 20:16
  • 6
    I plan on keeping the exact same IDs
    – Kyle Pollard StaffMod
    Nov 28, 2023 at 20:30
  • 10
    @KylePollard expanding on the thumbnails idea, will SE consider a way to implement something similar to the simple imgur resizing shortcuts? Without them, I foresee many very oversized images in our future and a lot of editing - and a lot more HTML in answers.
    – Catija
    Nov 28, 2023 at 21:51
  • 8
    @Catija good catch, we're going to try and cover the exact resizing shortcuts as well, barring any technical limitations
    – Kyle Pollard StaffMod
    Nov 28, 2023 at 22:07
  • 4
    @KylePollard awesome! If y'all do, consider throwing it over to Teams to save them needing to use HTML over there (which they currently have to do). 😜
    – Catija
    Nov 28, 2023 at 22:15
32

There were three major pain points with using Imgur as the hosting service. Please make sure these are resolved with the new service:

Networks where Imgur is blocked

Back in my early years of contributing to the SE network, much of it was from my school's network, which blocked Imgur, which meant that I could not view any images in posts from that network. The new image host should either be entirely internal, or on a service that most school or work networks don't block. This has been a pain point since 2011.

The built-in resizer stripping out transparency

There have been multiple complaints about users' images unexpectedly looking odd or incorrect when resized using Imgur's built-in resizer. This is because it strips out transparency, and sometimes decides to render black instead of transparent, resulting in blacked-out images. Please ensure that the new way both 1. has a built-in resizer, as it's a very useful feature, and 2. that it works with transparency. This will also fix this problem with avatar transparency.

The 2 MiB image size limit and unexpected file compression

This has been complained about for a very long time. The standard public Imgur service allows 5 MiB uploads for anonymous users and 10 MiB uploads for registered users, as opposed to SE's 2 MiB. Also, images over 1 MiB would be unexpectedly compressed to very, very small sizes. Please fix this limitation with your new service!

8
  • 9
    Hoping to host this on a subdomain of sstatic.net, so that shouldn't get blocked unless your network is blocking all the static resources we host. Good point on the resizer stripping transparency, I'll see what I can do on the new service. It's too early to say what the file size limit will be but I'll acknowledge that 2MiB is too small and would be painful to keep.
    – Kyle Pollard StaffMod
    Nov 28, 2023 at 21:01
  • "Networks where Imgur is blocked" This can be mitigated when there is a legitimate need by whitelisting the *stack.imgur.com subdomain or more specifically the i.stack.imgur.com sub-subdomain where imgur.com still remains blocked. +1 for the rest of it though.
    – TylerH
    Nov 29, 2023 at 19:29
  • @KylePollard I can point out that some orgs (including my own) block sstatic.net at times, or more specifically use automated tools/services that update block lists based on changing reports over time. See meta.stackexchange.com/questions/287602/… or meta.stackexchange.com/questions/110690/… for examples of others reporting on this actually happening in the past.
    – TylerH
    Nov 29, 2023 at 19:31
  • 2
    @TylerH I hear the feedback that it'll sometimes get blocked, but I don't think there's a great solution to avoid this. We prefer to keep the sstatic.net domain separate so it's easier to cache and isn't sending any cookies there.
    – Kyle Pollard StaffMod
    Dec 1, 2023 at 19:45
  • 1
    @KylePollard I agree w/ you on no good solutions--just wanted to make sure y'all were aware that that domain does sometimes get blocked. And yes, when it does get blocked, SO/SE starts to look very weird very quickly :-)
    – TylerH
    Dec 1, 2023 at 19:48
  • 2
    @TylerH Yeah, much appreciated 😁 I worked at a gig that blocked domains like that sometimes, I'm very familiar with that pain 🙃
    – Kyle Pollard StaffMod
    Dec 1, 2023 at 19:54
  • Image upload size or image hosting size? For most purposes 2 MB (or MiB) is good enough, if users know how to crop their images to whatever is relevant.
    – Joachim
    Dec 3, 2023 at 12:04
  • Self plug for compression: meta.stackexchange.com/questions/333607/…. Would love to see that become more gentle. Dec 5, 2023 at 8:18
25

I am honestly surprised this didn't happen years ago. Congratulations to whoever managed to keep it going this long (in both companies).

  • When choosing new URLs: be aware that a few multi-part Puzzling questions rely on the codes remaining the same, so it would be nice if you could preserve that.
    • Even better if imgur would commit to keeping the URIs cool – a blanket 301 should be much cheaper than the full hosting.
    • i.stack.imgur.com URLs were nice and short, and could easily be used in comments (unlike Stack Overflow for Teams image URLs). A hypothetical i.sstatic.net would be around the right length, if you were to do this in-house.
  • Also good would be if images ended up properly archived, like post text is in the database dumps. That was impractical when you were using imgur, but might be more viable with a new system.
    • And perhaps in a future implementation, way down the line, you could track "what references this" information better than the current "it's just a file store" approach can. But that's hard.
    • Many images on i.stack.imgur.com contain private information that wasn't supposed to be shared publicly. This complicates archiving somewhat – but since information usually becomes less sensitive over time, I would advise that you migrate all the images.
  • I'd also love to be able to upload SVGs – which, when appropriate, are smaller, and can have alt text bundled in the file.
    • So long as your new host doesn't re-encode everything (especially not to webp), I'd be satisfied with just the currently-supported file types.
7
  • what do you mean by "properly preserved"? does Imgur drop images under stack.imgur at all? Or do you mean releasing dumps of al the images? Nov 28, 2023 at 19:44
  • 3
    @starball I mean, answers that rely on the images for meaning are not currently preserved properly in the database dumps, because we've always just sorta assumed that the image host will last forever. Now that it's going away, it's a good opportunity to actually have a proper think about this problem.
    – wizzwizz4
    Nov 28, 2023 at 19:46
  • 9
    I'll ask Imgur about the redirect, but no promises there, they'll likely just be dead after our contract ends. I like the i.sstatic.net idea, I was already thinking about a subdomain there. I don't foresee us preserving images in a data dump. Tracking references would be interesting to tackle, but not something we're looking at now. Not sure if we'll support SVGs, but we will likely support whatever Imgur is supporting. I don't expect us to re-encode everything, I also find it frustrating when I get a .wepb image and can't use it like I expect.
    – Kyle Pollard StaffMod
    Nov 28, 2023 at 19:53
  • 3
    @KylePollard Imgur providing i.stack.imgur.com is the main reason I still have a positive opinion of Imgur, and I doubt I'm the only one. (It's also the main reason Imgur is allowed behind certain school / corporate firewalls.) If SE can afford a nominal fee for them keeping a really lightweight redirection service up, or leasing the domain name or something, that might be a really cheap PR move for Imgur (though, admittedly, perhaps not with Imgur's target demographic).
    – wizzwizz4
    Nov 28, 2023 at 19:57
  • 3
    @KylePollard SVG would be great, if it's an affordable option. I occasionally post SVG in my answers, hosted on a Github gist, but I don't like my answers to rely on an external site. OTOH, I guess there's not a huge demand for SVG, simply because the vast majority of users don't know about it. But its fans are pretty vocal. ;) meta.stackexchange.com/q/92568/334566
    – PM 2Ring
    Nov 29, 2023 at 14:12
  • 1
    "Congratulations to whoever managed to keep it going this long (in both companies)." It was a contract, so it probably is thanks to Joel and Jeff themselves, or one of the other top 5 employees at the time. It also probably would've continued in perpetuity if Imgur didn't sunset the offering, I am guessing.
    – TylerH
    Nov 29, 2023 at 19:28
  • 3
    @TylerH Perhaps before 2021, while it was independent – but the arrangement continued for a couple of years after the MediaLab AI acquisition. That, I find impressive.
    – wizzwizz4
    Nov 29, 2023 at 20:24
22

Regarding Sonic the Anonymous Hedgehog's answer

I'm not in favour of increasing the maximum upload size, unless some more automatic work can also go on behind the scenes.
I do see the benefit especially for a new user to be able to send something they just took on their phone - but they will be totally unaware of the extra load that causes for anyone viewing the page. As far as they can see it is the same size as everybody else's photos.

I can think of no instance when the inlined image needs to be full quality - apart from anything else it's only ever displayed at 650px on the main page.

If people less data-savvy post up four or five 5MB images of their garage door for such as diy.se, then everybody visiting it will get a huge data hit. It's rare on non-computer-tech sites like that for anyone to back-edit & inline the imgur m or l instead of the full image.

I'd very much like a future consideration for automatic inlining of a resized, lower-quality 650px wide image automatically linked on click-through to the original - in effect automatically inlining the l. This could be done silently as the post is saved, as currently happens with link renumbering, to save confusing the less-savvy user.
I spend a fair amount of my time doing this manually.

Inlining an l or m takes several steps -
Renumber the 2nd reference
Copy paste the original link
Renumber one reference in that link.
Add an 'l' to the other.

enter image description here

…that's a lot of faff to make the page look almost no different yet save several MB of page load.

It makes sense to keep the original, for times when detailed examination is required, but little sense to make everyone load an image larger than they're actually seeing & before they even know whether or not they're interested in the image.

Not everybody is on gigabit.


An additional thought on this 'automation'.

When a new user uploads an image it will not automatically inline for them. A more experienced user must do this - which on many sites gets done quite quickly; good.

However, the code they get when the new user uploads is only partial compared to an established user.

enter image description here

Then what happens is the established user just plonks an exclamation mark in front & hey presto, working image.

enter image description here

However - no-one ever thinks to add the necessary syntax to enable click through

enter image description here

…so perhaps some consideration needs to also be given to this issue. Perhaps setting the full syntax just without the exclamation mark -

enter image description here

though that makes this happen in the post

enter image description here

I don't have a solution for this, but it does perhaps need looking at.
I think this is going to be the same problem whether or not we incorporate the auto-resize, so I feel it needs considering at the same time.


One additional consideration for automatic resizing - the system needs to be aware of DPI settings.
Modern HiDPI/Retina systems often take screenshots at 144 DPI rather than the old 72 DPI standard. This means they arrive 'double size'.
Perhaps we also need a 'DPI halver' for these images.

11
  • 5
  • 4
    letting them upload but resizing automatically would be a good idea, then having some modifier for the original not optimised size Nov 29, 2023 at 12:05
  • @JourneymanGeek - I agree. I've added a bit more to emphasise why. I'm not against the idea per se, just it needs a background re-jig the non-technical user doesn't need to know about. It's like sending an iMessage or email with a photo. Rarely does the user need to know that it will be down-sized before sending, unless they tell it not to.
    – Tetsujin
    Nov 29, 2023 at 17:57
  • 2
    I think this is better served by SO instead using JS to dynamically load images once they scroll into view. Many sites do that, especially for mobile devices/devices on cellular data.
    – TylerH
    Nov 29, 2023 at 19:38
  • 1
    The 2 MiB file size limit might have been reasonable in the 2000s, but it’s been outdated for years now. It makes it hard for us to share clips (as animated GIFs since we still can’t upload videos—another outdated restriction) or high-resolution screencaps on sites where those types of media are useful, like Arcade, Movies & TV SE, and Sci-Fi & Fantasy SE. The solution here is to automate resizing while also giving a way for users to upload and view media 5 MiB (or more). Nov 29, 2023 at 20:49
  • 1
    @TylerH loading="lazy" if anything, and put those JS workarounds to the grave. Dec 1, 2023 at 15:11
  • 1
    @galacticninja - I'm tempted to post my own plea for them to increase the cap on animated gifs. Thinking about all the really crappy low-res gifs I've seen over the years is making me sad.
    – Richard
    Dec 1, 2023 at 18:54
  • 1
    @Richard - myself & galacticninja were part of the effort to 'rescue' potentially lost gifs a while ago - movies.meta.stackexchange.com/q/4918/25773 - [You need to look at the edits in the answer to see the initial list] and actually most of the ones I worked on weren't too hard to compress to the 2MB limit. The originals were just 'lazy' [probably lack of awareness rather than intent].
    – Tetsujin
    Dec 1, 2023 at 19:21
  • 8
    I agree with the concerns. There's conflicting priorities - askers don't want to resize images, but readers don't want large images to take forever to load. A good compromise would be to allow larger uploads, but serve resized images. As long as we're not horribly compressing things, this should work okay. I'll consider this possibility as I develop our new solution but I don't have anything to commit to yet.
    – Kyle Pollard StaffMod
    Dec 1, 2023 at 20:48
  • 2
    @KylePollard - thank you for offering to look into this. Assuming your average phone is 12Mpx, then an HEIC is about 2.3MB, a straight conversion to jpg becomes 3MB, at 50% quality [still good enough for most things] that's down to 1.2MB [which is what I do for my own uploads]. Dropping it to 50% at 650px [about imgur l quality] is right down at 70KB. That's a big saving, for no discernible difference visually at the presented in-lined size.
    – Tetsujin
    Dec 2, 2023 at 9:40
  • @KylePollard - I had another thought on how this would work for new users who cannot inline their own images & how editors usually handle it. I've added to this answer rather than separately because I feel it's a part of the same problem. …and also a last-minute HiDPI concern with 144 DPI screnshots
    – Tetsujin
    Dec 3, 2023 at 11:43
20

Make sure that avatar images that use gifs don't play their animations. Animated avatars are not allowed and the current solution to make them not play their animations is to use imgur-specific query parameters.

See also

1
  • 5
    I have a feeling they'll miss that part and we're going to have thousands of animated avatars for a long time until they notice and fix it, if at all. Dec 28, 2023 at 9:40
15

EXIF data is stripped for privacy reasons, but sometimes there's a genuine need for some specific attributes

Someone already posted about how Imgur strips EXIF data out of uploaded images, and that it's good to do so to prevent privacy leaks.

However, this does create two problems:

Some images require their EXIF data to be rendered correctly, and render incorrectly without it

This question reports a bug where an image renders incorrectly when uploaded to SE Imgur. The answers there contain a visual of how the image is supposed to look like and state that stripping out the EXIF data causes the image to render incorrectly.

Some sites, such as Photography, use the EXIF data to obtain crucial details about a photograph

As this post says, on Photography, having to constantly ask post authors for how they took the picture (e.g., ISO, aperture, shutter speed, etc.) and what camera make/model they used can be a big pain, and it's much easier to just look at the image itself for this information.

Honorable mention: past (now fixed) Imgur bug with images displaying incorrectly rotated

Essentially, some image editing tools, when a user issues a command to rotate an image, keep the image as is and simply modify an EXIF attribute to display the image rotated. This resulted in a past bug where stripping out the data caused the image to incorrectly display in its un-rotated form. This was fixed by Imgur, by it searching for this specific attribute and physically rotating the image server-side, then stripping out the EXIF data. At the very least this behavior needs to be copied over, but that won't address the above two issues.


Again, I understand that removing EXIF data can be important for privacy reasons. However, removing all of the data wholesale creates problems. In your new image server, please only strip out specific attributes (such as GPS location) while leaving ones necessary for the image to render properly (such as those in the first and last sections above), and those useful to sites like Photography (those in the second section above).

8
  • 2
    Ideally, when uploading there will be a checkbox, ticked by default, saying "remove EXIF data". Dec 4, 2023 at 10:25
  • 4
    @ShadowWizardIsSadAndAngry add a info button with a popup titled "what does this mean?" Dec 4, 2023 at 10:35
  • 2
    IMO, opposite sense: unchecked by default, "include EXIF data". Dec 4, 2023 at 13:31
  • 7
    Hmm, these are really good points. I expect that we'll do one option for all sites (strip EXIF for privacy) and don't expect to be building new UI for this, but I do wanna avoid the bugs you've pointed out. I don't have anything to commit to yet, but I do want to acknowledge that these are edge cases that I should consider.
    – Kyle Pollard StaffMod
    Dec 4, 2023 at 18:29
  • 2
    @KylePollard In my opinion, the best solution is the one in the final paragraph of this post: only strip out the specific EXIF attributes that would cause privacy issues while leaving necessary and useful ones in place. Dec 4, 2023 at 19:57
  • "This was fixed by Imgur, by it searching for this specific attribute and physically rotating the image server-side, then stripping out the EXIF data." — Toggling a value in the EXIF data is trivial. Reformatting the image can result in file that is many times larger than the original, making it a really bad "fix". Dec 29, 2023 at 0:23
  • 5
    @SonictheAnonymousHedgehog sasy "only strip out the specific EXIF attributes that would cause privacy issues". Doing it the other way around would be safer from a legal standpoint: have a list of known to be useful or safe attributes, and then add new ones as requested. Compare what happens when some manufacturer creates a new attribute that contains confidential data (e.g. Age of Photographer). Retaining it by default will not please SE's lawyers. Dec 29, 2023 at 0:32
  • Unfortunately, EXIF is not nearly as standardized as one would hope. I worry that either blacklist or whitelist is going to miss things, and either break images (at least for certain use-cases), or reveal private information. I hope SE takes a lot of care with this.
    – KRyan
    Mar 28 at 16:35
13

Chat uses Imgur for image uploads, so I assume that this will require changing it to use a different service?

Also, if old images aren't redirected somehow, every single image in chat will break once the service shuts down.

4
  • 19
    Migrating Chat images/messages is something we'll take care of, though it's too early for me to commit to any details yet.
    – Kyle Pollard StaffMod
    Nov 28, 2023 at 19:49
  • We would also need both versions of chat to have 'new' uploaders Nov 28, 2023 at 23:04
  • 3
    @JourneymanGeek Huzzah! Chat finally gets dev hours! Maybe this'll mean we can finally 'upload' images to chat without auto-submitting the message at the same time. Big pain point.
    – TylerH
    Nov 29, 2023 at 19:39
  • This is one of the things I would love but after years of ignored lobbying, I am not very optimistic of 😅 Nov 29, 2023 at 23:04
12

A long-standing privacy issue has existed with users being allowed to include images from arbitrary external domains in posts and chat. This can be used to track users, among other risks.

Additionally, off-site images can rot or have their contents changed. And while this is a more minor issue, my school district (and like others using the same software) cuts off internet access if banned applications/websites are detected, and off-site hosted images from Discord's CDN or NSFW websites can cause this to happen without ever leaving Stack Exchange.

If you'll already be needing to rehost a significant majority of images on the site, are there any plans to finally disallow off-site image hosting on untrusted sites?

9
  • 11
    On github you can link images from arbitrary websites but they are proxied via github's CDN. A solution like that might work, it allows dynamic images that change over time without compromising privacy.
    – mousetail
    Nov 28, 2023 at 21:14
  • 2
  • 2
    On the one hand, this is definitely a privacy issue that would be nice to fix; on the other hand, I once used it to play a game of Uno in chat with a specially crafted bot :p So my vote's on mousetail's suggestion
    – Ginger
    Nov 29, 2023 at 14:12
  • "users being allowed to include arbitrary images in posts and chat." Huh? All images are arbitrary. What does this mean?
    – TylerH
    Nov 29, 2023 at 19:32
  • 1
    @TylerH As in, images from arbitrary URLs. It's not restricted to trusted hosts, meaning you can control the host, and do things like collect IPs for tracking purposes or change the content at will. Nov 29, 2023 at 20:01
  • 2
    Clicking image links to unknown locations is risky and not really SE's responsibility, ultimately. That's likely more trouble than it's worth. Some content may be worth linking or embedding but legally can't be re-hosted. Some content technically may not be uploadable. Etc.
    – TylerH
    Nov 29, 2023 at 20:44
  • 1
    @TylerH I'm not talking at all about clicking links to images? Nov 30, 2023 at 0:23
  • 2
    Many users have been forced to use non-Imgur sites (eg Github) to host images that cannot be uploaded via the Stack Exchange Imgur interface, eg GIF anims that cannot be reduced to <2MB, and SVG files. Are you proposing to invalidate those images?
    – PM 2Ring
    Dec 1, 2023 at 19:12
  • 1
    @PM2Ring Yes. Those issues can be fixed if we're already moving away from Imgur, and even if they couldn't, privacy/security is a higher priority. Also, no reason a few other trusted sites (GitHub, Imgur, Google) couldn't be whitelisted still. Dec 1, 2023 at 19:14
10

This is a follow-up question to Starball's post:

  1. Please be careful not to unnecessarily use the thumbnail URLs instead of the original-size URLs when transferring. I.e. don't transfer http://i.stack.imgur.com/12345m.jpg. Transfer http://i.stack.imgur.com/12345.jpg.

We'll be using the original source image, not thumbnails – Kyle Pollard

What about posts that purposely include both thumbnails and the original image, or posts that include the thumbnails only? Will the images in these posts be transferred intact with no size changes? I often add thumbnails to my post (example) and link them to the original image if the original image is too large (in either resolution or file size) for the post, like this:

[![screenshot][1]][2]


  [1]: https://i.stack.imgur.com/12345m.jpg "thumbnail"
  [2]: https://i.stack.imgur.com/12345.jpg "original"
6
  • I was thinking of asking this, but was too lazy :P thanks hehe. I've done exactly this in some of my posts. I'm hoping and guessing that this comment by Kyle in reply to a question by Catija implies that the answer is yes, it'll be preserved properly Nov 29, 2023 at 6:27
  • 2
    On a related note, many images on some sites aren't just pictures, they are input or output data. Modifying the bytes of such images could invalidate them.
    – PM 2Ring
    Nov 29, 2023 at 13:44
  • 1
    I feel like the only real option is for Imgur to give Stack Exchange a complete copy of all images in the i.stack.imgur.com file store, complete with URLs, and for SE to host them byte-for-byte identically. I understand that's the current plan.
    – wizzwizz4
    Nov 29, 2023 at 17:33
  • 2
    @wizzwizz4 apparently they can download a backup mirror. see meta.stackexchange.com/a/291682/997587. Nov 29, 2023 at 18:43
  • Both starball's and your concern should be addressable by just mirroring the specific image that is listed, no?
    – TylerH
    Dec 1, 2023 at 20:00
  • 2
    I plan on still supporting the thumbnail functionality and want to have the same behavior as the current thumbnail generation. My gut instinct is to just regenerate thumbnails on the fly with our new image service instead of storing the thumbnail version separately. If you have specific behavior you'd like preserved, would you mind editing your post to describe this behavior? I can't commit to anything yet, but it'll help me a ton.
    – Kyle Pollard StaffMod
    Dec 1, 2023 at 20:51
10

As an alternative to Imgur doing redirections once the contract ends, can we ask them to just make that a CNAME to some SE server that can then do the redirections? Or even license the stack.imgur.com subdomain to SE so that SE can maybe even continue using it?

The former would be a trivial expense for them, the latter maybe even a microscopic revenue source.

1
  • 9
    This is exactly what they're going to do.
    – Kyle Pollard StaffMod
    Dec 1, 2023 at 19:38
9

Currently, I use url:imgur to search for posts that have images, which gets most but not all of them. (It really only works because the default image format is a linked image.) This can't possibly work after the migration, so it would be nice to have an alternative built into search that returns everything containing <img, and maybe also the opposite, something that finds posts without any images.

I guess this might count as a "wholly new site feature" and be out of scope but I'm asking anyway.

4
  • if there's a specific path under sstatic.net this is given, then you should still be able to use url: in search Jan 11 at 23:04
  • @starball Depends on how they do it. A significant number of posts may still have markdown with the old Imgur URLs, so it might require two searches. Plus, this doesn't find anything that uses Imgur.io or another third party host, in addition to the downside I already mentioned.
    – Laurel
    Jan 11 at 23:14
  • if you mean image URLs not in img or a tags, see meta.stackexchange.com/a/395044/997587. but since you're talking about any image URLs, I think this is the wrong place to put this request. if you want to find posts with images, I'd suggest this being left to users with SEDE. I'm not aware of a generalized, performant (enough for SE's search bar) way to know whether a link is to an image resource. Jan 11 at 23:36
  • Already requested, also see workaround using SEDE in the answer here. Jan 12 at 6:17
8

Expanding a comment - Imgur uploads, outside the occasional 'I need a quick and easy place to throw an image up' gets used in a few places outside the main site. While I guess it’s 'easier' on your end to find the images, with raw database access, I'm curious about the 2-4 (or more!) different image upload methods you have, and consideration for more unusual locations.

  1. At some point Imgur turned into the preferred avatar upload space over (legacy) Gravatar. This seems to use a slightly different uploader from the main site - do you have a plan to back up and make available noncurrent avatar images?

  2. In theory, moderator messages can, and sometimes do include images, and while they have limited utility in the long run, depending on 'how' you fix the images, these might be broken. Looking at the source of an email of a test moderator message I sent

<p>Testing to see if images on mod messages are mailed and how it’s handled<=
/p>
<p><a href=3D"https://sg-links.stackoverflow.email/ls/click?upn=REDACTED" rel=3D"nofollow noreferrer"><img src=3D"https://i.stack.imgur.com/zZsT=
u.jpg" alt=3D"enter image description here" /></a></p>
<p>Regards,</p>
<p>Super User Moderation Team</p>

You might break embedded images in emails - and I do recall some users use it for reference. There isn't anything you can do, but fixing broken ones on moderator messages too might be something to consider. If nothing else, give moderators something to point at if users complain ;)

  1. 'Regular' chat uses a really old uploader version with less functionality and images are essential on chat. The "new" mobile chat has none (which is annoying, but I understand out of the scope of this). While getting any attention to chat is like pulling teeth, breaking images and image upload on chat would be a very bad thing. It feels like maintaining a single universal upload system is a good idea and this is an opportunity to do it

  2. While scanning through Stack Overflow for Teams for Imgur links might be a no go, since Stack Overflow for Teams provides integration for third-party things, maybe having a tool to 'fix' these links based off the solution you pick might be good?

5
  • 3
    CM escalation messages may also contain image references, and probably do.
    – Shog9
    Nov 29, 2023 at 19:36
  • Erf. Which leads to some complexities for the other thing I am pondering - a data dump. Nov 29, 2023 at 23:11
  • 4
    I have to assume there's a LOT of PII in various images that aren't linked anywhere or at least not anywhere public. I mean... There's the TL... And other mod rooms... And years worth of images in employee chatrooms... Careful what you wish for
    – Shog9
    Nov 30, 2023 at 1:22
  • That's why its a comment and not a request. Well that and drama potential. Its not a great idea but some way of keeping a long term archive sounds good Nov 30, 2023 at 3:02
  • 4
    We have a list of the non-traditional places that the image uploader gets used and I'll make sure all the ones in this post are in-scope. If we miss any, we also plan on having a redirect in place. I don't have any plans right now to deprecate any current usages.
    – Kyle Pollard StaffMod
    Dec 1, 2023 at 20:53
7

An internal proof-of-concept will inform the image hosting provider we ultimately settle on.

Is self-hosting not a viable option?

Forgive me if I'm being daft here, but I can find very little about that possibility and eventual discussion here on Meta, with the first questions tagged with announcing this very cooperation with Imgur.

Here is an answer getting into the problems with external hosting.

Of course, self-hosting I assume opens up a different can of worms, but this network is based on smart people dealing with software, and I imagine self-hosting would make migration a lot easier, too.

1
  • 15
    We're exploring a few different options, but here "hosting provider" just means "cloud service" - could be something that looks like serving these through a CDN or just some blob storage somewhere, we haven't nailed the specifics yet. It'll be served from a domain we control and we'll have control of the images, but we're certainly not serving all images from our dozen webservers. We don't have the bandwidth to support that.
    – Kyle Pollard StaffMod
    Nov 28, 2023 at 20:44
7

In my SEDE querying of SO, there are a number of posts which link to i.stack.imgur.com images in code (code blocks and probably inline code as well) and not in actual images. Ex. as example images in Stack Snippets. I actually discovered this by accident when investigating what types of query parameters were being used in such URLs- they showed up in my SEDE query because of people using their avatar images as example images in Stack Snippets.

Will these URLs in code blocks be edited as well to their new locations?

4
  • 2
    I haven't spec'd out the migration plan yet, so nothing to commit to on my end yet. I expect we'll do a bulk replacement of the domain regardless of if it's a link, embed, or post content. I do see a problem if this foundationally changes the problem in the post though - for example, if you had a hashing function that depended on the domain name as part of the post. I'm hoping those are an extreme minority though. What do you think?
    – Kyle Pollard StaffMod
    Dec 1, 2023 at 20:56
  • @KylePollard I initially thought it should be fine and probably desirable to replace whether it's a <img> src, <a> href, or in text/code. It didn't occur to me that it could be more complicated :P I'm gonna abstain from making a suggestion Dec 1, 2023 at 21:03
  • 3
    My vote, especially in things like stack snippets, that linking to the working image will overwhelmingly be the intent of the author rather than an exact text match to the old link. And we're definitely not in a position to make case-by-case decisions in the migration.
    – KyleMit StaffMod
    Feb 9 at 15:51
  • @KyleMit - importantly, if there is ever a case where a question relies on the exact text of the imgur URL, it will be trivial to reinstate it after the migration, as (I assume) the migration will add a revision entry, and thus the old url will be present in earlier revisions.
    – Robotnik
    Feb 16 at 5:01
7

Posts deleted as spam or abusive should continue to have their images automatically deleted, as they currently are with Imgur

There is currently a feature with the current Imgur uploader whereby if a post gets deleted as spam or rude or abusive (automatically in response to receiving the threshold number of flags from the community or a single one from a moderator), any images that are embedded in it and uploaded at about the same time as when it was posted will be deleted from Imgur's servers.

This is important because many of these posts use images - for instance, there was a past case of a troll filling a site with offensive images, and many spammers use images as part of their posts.

Please make sure that this feature is copied over to the new image host.

1
  • yeah, I've been trawling through images in the SE image space and the number of things™ that I should most definitely not be seeing in there is a bit unsettling. I mean, it's not that much, but even a little is too much, isn't it? Feb 11 at 22:07
6

I have an idea that can improve the migration process a bit.

Considering that Imgur tracks when an image that they host is being viewed, or at least the amount of times it was viewed, my suggestion is simple: do not migrate images that were never viewed, or with only the one view of the uploader after it was uploaded.

Advantages:

  • Saving resources. No need to store something that's not being in use.
  • Even more important: privacy. Personally I've uploaded images then on second thought didn't use it, and I'm certain others uploaded sensitive things by mistake, and corrected it without ever actually posting the image URL, hence adding images that were never viewed.
9
  • 2
    I'd expect everything to be viewed at least once. :D Dec 2, 2023 at 0:57
  • @JourneymanGeek I did mention this: "or with only the one view of the uploader after it was uploaded". Dec 2, 2023 at 7:40
  • 3
    SOOOO MANY UNEXPECTED SELFIES Dec 2, 2023 at 8:35
  • 1
    Very good idea! I have at times even uploaded images solely to see what they would look like, or to realize they contained something unnecessary. And those uploads actually made me feel somewhat self-conscious: somewhere on a server in the world is an image that won't be accessed by anyone and just sits there, all alone, part of a dark net that no one cares about.
    – Joachim
    Dec 3, 2023 at 12:12
  • 2
    It should be easy to remove images that are not referenced from any of the SE sites. Dec 5, 2023 at 15:25
  • 1
    @CrisLuengo the images I refer to are not even on any SE site, if image is posted it's counted as being in use and I don't want it removed or gone, even if there are only very few views. (I highly doubt SE keeps a list of all the uploaded images and amount of views/references, if that's what you meant.) Dec 5, 2023 at 20:14
  • 1
    @ShadowWizardIsSadAndAngry Why would SE need to keep any images not referenced on its own site? It’s not their problem if you were using their Imgur account to host your private images, or images for a different site. Maybe I’m misunderstanding your point though. Dec 5, 2023 at 21:02
  • 5
    Since the whole thing is not even 3TB, and trying to prune images will cost time to hopefully get it right, I don't see the benefit in terms of resources. I feel like the end result would most likely be that something gets overlooked and suddenly the images I had linked in mod-only annotations or something are just gone. That being said, it would be nice if there was a more transparent way to get your old, accidental images removed.
    – Laurel
    Dec 5, 2023 at 22:18
  • 1
    @CrisLuengo One example of legitimate off-site use that has been raised is emails sent via SE systems (eg, Mod/CM messages), which can contain images.
    – Robotnik
    Jan 7 at 23:30
6

It would be great if the images could be served with the proper Access-Control-Allow-Origin headers so that we can do some readbacks on it, e.g., call getImageData() or toDataURL() from a <canvas>.

It would definitely be useful for Stack Overflow, where for years we had to work around that issue by using other services, like Dropbox, or other images like the ones coming from Wikimedia, but I guess this could also be useful to a couple of other sites.

4
  • It will likely be declined, same reasoning as this one. Mar 10 at 15:29
  • 1
    @ShadowWizardLoveZelda I don't really follow. Is it planned that these images require an account to be accessed? Also, note that they could set it so that only stacksnippet's domain is allowed.
    – Kaiido
    Mar 10 at 15:31
  • Ah, not sure sorry, I didn't really dig into it. Just remembered such thing was asked before, looked for it, and found it. If your request is different enough then sure, it might be done, though doubt in response to the feedback here so after the change is done, get ready to post this as a new, full, feature request, explaining how it's different from the one I linked to. Mar 10 at 15:39
  • 4
    Ok, fair enough, but I don't think that applies here. They were asking about getting external access to some data only accessible from their account, i.e. requiring authentication. I am asking that public data can be read by a server controlled by the company.
    – Kaiido
    Mar 10 at 15:42
5

Depending on the method used, editing posts can count as a modification, allowing users to change formerly locked-in votes.

Are there plans regarding if votes will be unlocked as a consequence of this?

This might be out of scope, but for any SE Imgur images in SOfT, will those be fixed too? Or not?

8
  • 1
    Votes will be unlocked if Community makes an edit. I highly doubt Teams will be touched since that's supposed to be private; it also doesn't seem to use Imgur for uploaded images.
    – Laurel
    Nov 28, 2023 at 20:18
  • 1
    @Laurel - Although they are used sometimes. There are 67 posts on the Mod Team with Stack Imgur images.
    – Mithical
    Nov 28, 2023 at 20:28
  • Per one of my later posts, while the team does take action against serial unupvoters, they do not undo their actions and make the votes active again. Nov 28, 2023 at 20:29
  • 1
    I'll bring up vote locking as a nice-to-have. To my knowledge, our systems don't currently differentiate edits based on the source (including automated system edits), so this would probably necessitate custom work for this migration. Can't commit either way but if I had to guess I'd say it's likely retaining vote locks ends up low priority. I honestly hadn't thought of SOfT and it's a good one to track - I'll have to check on that one.
    – Slate StaffMod
    Nov 28, 2023 at 20:38
  • 5
    @Slate An alternative method would be to do what's currently done with older http://i.stack.imgur.com links. Those are silently re-rendered in posts as https://i.stack.imgur.com without needing to edit them. A similar silent re-rendering is done for http://meta.*.stackexchange.com and https://amazon.com links. Nov 28, 2023 at 21:14
  • 2
    @SonictheAnonymousHedgehog nice, good find. I'll look into it and consider this option, but no promises yet. Ideally we've updated the post content so the "source of truth" is updated and not just silently re-rendered.
    – Kyle Pollard StaffMod
    Nov 28, 2023 at 21:26
  • 6
    I very intentionally used public SE imgur uploads for any images with publicly-releasable information (or that would be released publicly eventually), so there are certainly public SE images that will cease to function in posts I've created/edited both on the Mod Team and SO Internal. @KylePollard (FYI)
    – Catija
    Nov 28, 2023 at 21:55
  • 1
    Further to cocomac's point about editing counting as a modification - the migration should not bump the CC-BY license revision of any affected post: a URL change (to point to the same resource) does not alter the post in a meaningful way and thus should not create a new licensed version of the post. CC @KylePollard
    – Robotnik
    Feb 16 at 5:13
4

Maybe this is a little bit lazy, but for years whenever I've wanted to host an image, I'd upload it via the Stack Exchange uploader and copy/paste the Imgur link to whatever site I was using (Reddit, some forum, etc.), without posting the image to Stack Exchange sites.

I didn't think much of it when Imgur was hosting the images (it seemed equivalent to uploading images to Imgur directly). But I'm now a bit worried that all those images used only at non-Stack Exchange sites will break. Is there anything I can/should do?


Edit: What happens now when I link to images outside of Stack Exchange (using a newly uploaded image):

Error 1101

3
  • 1
    Yeah, you're out of luck, as Kyle said in a comment: Image links will likely insta-rot, I don't expect we'll get redirects from Imgur. Apr 9 at 12:46
  • meta.stackexchange.com/a/395039/135565 vaguely covers the same ground, though I wasn't thinking external links rather than odder internal ones Apr 9 at 13:18
  • 7
    @ShadowWizardLoveZelda meta.stackexchange.com/a/395127/135565 is probably more up to date, and says "They plan to give us full control of the *.stack.imgur.com subdomain, which we plan to point at our own servers to take care of the redirection. We're hoping to redirect requests to a subdomain of sstatic.net or another domain we control. " etc etc, so on the short term, Those links should be fine. Apr 9 at 13:26
2

Some of the images used in the Help Center are also stored on Imgur. Will they be migrated without exception?

1
  • 2
    Yes. From the other answer: "[Imgur is] working on supplying us with a full list of the IDs in their database so we can ensure that we've moved everything over."
    – Laurel
    Mar 28 at 14:18
1

We used to have a bot on Super User's main chatroom, and there's a significant amount of nostalgia to some of the content there. It used to serve out images on request and I was (as time/spoons/attention span permitted) building up a list of commands and the associated images, reuploading any that weren't hosted on Imgur and so on. While there's time to the sunsetting.

  1. would there be an easy way to 'cut' over to the new host
  2. what would be the 'ideal' way to archive these things if I'm working on it before things are firmed up?
4
  • 2
    I'm not completely sure I understand - are the images in question hosted on Stack Imgur, or in another location? If it's on Stack Imgur they should be safe
    – Slate StaffMod
    Dec 8, 2023 at 15:29
  • Hm, mostly but not all. Essentially I have a dump of the commands of an old bot with a mix of stack Imgur and non stack Imgur hosted images. I have been slowly going through them and documenting each trigger, the image it triggers and then reuploading any non stack Imgur image to stack Imgur. If the domain changes in theory I would rather update the links to the 'new' domain. Dec 8, 2023 at 23:16
  • 1
    Probably the only thing to say at this point is "I'll keep it in mind." I hope (expect?) that the new URL will be easy to discover from the old one, and I think we're all hoping it's as easy as a simple substitution. But there'll be more details on it soon enough.
    – Slate StaffMod
    Dec 10, 2023 at 1:33
  • docs.google.com/spreadsheets/d/… is what I'm working with now, cross referencing it with search and a JSON dump of the bot. I guess the other part of this is its a very niche situation and I'm probably the only person who's particularly fussed with this, and I'm not entirely sure if I'll partially or completely move it over. Also debating making an archive.org backup once that's done, but I'll want to get a list of links first ;) Dec 10, 2023 at 1:38
0

Some technical questions coming in! Now I knew you said technical and implementation questions are limited to answer but these are very broad, I am sure you can answer these.

Will there be an API?

Could I create and delete images automatically? You could bulk-upload images which might be useful sometimes, and it will make it possible for moderation bots that automatically delete inappropriate images.

More advanced UI?

See the current image uploading UI is very basic, would there be no new UI or would you renovate it a little bit to make it feel more modern? Like I assume we'll be able to delete images so a button would be needed for that? Will you have different menus or just one pile of buttons?

Image support?

Will PNG, JPEG, GIF, and many more image formats be supported? Or will it only be PNG? Would more obscure formats like WebP be supported?

Statistics?

Will there be a page with "x images per day/week/month/year" or "PNG makes up x percentage of images"? Statistics could be used for a wide range of things and would be easy to implement, I know as a software developer, you would just need to look at your list of images, filter them, and count them.

Advanced URLs?

Would you be able to group two images so "newdomain.com/group/img1.png", "newdomain.com/group/img2.png" and so on because I could find some uses for that and again it would be fairly simple to implement as you would only need to really ask for an alternative path or perhaps use a group name and then have the modified URL go through all your normal functions and classes.

I am going to leave it off at there because I do not want to get too specific, hopefully your team have great success! I wish you good luck!

(Also for the image hosting provider, CubeUpload and ImgBB are two good options, each with their tradeoffs, the company behind ImgBB is unknown while CubeUpload is apparently maintained by three British developers, both of these options however might not be scalable enough for SE)

7
  • 2
    It's probably a bit too early in the process for most of these questions.
    – PM 2Ring
    Dec 1, 2023 at 19:00
  • @PM2Ring I think things like API, new UI, image support, these things can be answered and it is not too early in the process for those. It said it is in the research and discovery phase where these questions are important to be researched. At least good guesses could be given.
    – The_AH
    Dec 1, 2023 at 19:03
  • 1
    Kyle has already stated "we will likely support whatever Imgur is supporting". IMHO, questions about the UI or an API are premature.
    – PM 2Ring
    Dec 1, 2023 at 19:08
  • 8
    You've got some great ideas, but the scope of this project is just a replacement. Right now we're just focused on retaining the same functionality we already have. I don't forsee there being a new API or interface beyond what we already have in the editor. Image support is still to be determined, but it'll be at least what we have already. There won't be any ongoing public statistics page, but I can share some ad-hoc after we migrate. No grouping of images either.
    – Kyle Pollard StaffMod
    Dec 1, 2023 at 19:42
  • 6
    I feel pretty comfortable saying that while this is all good to consider, it will almost certainly be out of scope for this migration. The primary aim of the migration is to ensure ongoing service integrity. It may be possible that additional features and extensions could become more possible after the migration, and it is possible (but far from guaranteed) some existing features will see improvement along the way. But wholly new site features are unlikely to make it into the project.
    – Slate StaffMod
    Dec 1, 2023 at 19:43
  • @KylePollard Oh well I got too excited, I thought SE could add some like simple features like deleting images at least, will that be added?
    – The_AH
    Dec 2, 2023 at 7:39
  • 1
    "PNG makes up x percentage of images" You can view the current image extension stats here. PNG files represents 78% of all images (including .gif files). Jan 9 at 12:38

You must log in to answer this question.

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