The thumbnails are a separate feature, no matter what you post, lemmy servers will create a small thumbnail file that is able to load quickly, for all but text-only posts.
You can also define the thumbnail URL separately when creating your post, if you like, which can work around the current resolution issue.
You can also define the thumbnail URL separately when creating your post, if you like, which can work around the current resolution issue.
Really? Double-checking it, I’m seeing two related options here when creating / editing a post:
URL, in which you used to be able to direct link to an offsite image, now broken for Imgur
Image, in which case you upload to the native lemmy server and it will create said thumbnail and store the expandable version
But for example, I don’t believe I’m able to go back to the broken posts and use both options above to fix the issue. It’s either one or the other from my previous testing, as enforced by the Lemmy software.
Yes, lemm.ee (my host’s instance) is amazing at updating to the latest stable release in speedy fashion, but I see now that the new ‘thumbnail’ option only applies to new posts, not old ones. Aha.
I suppose this goes far to help explain why all the thumbnails of my old (Imgur-hosted) posts got broken the way they did. Also, “Lemmy” being the amateur project that it is, it seems like this whole thing kinda fits in to a pattern of bumpy updates which sometimes break something that was working earlier.
Not trying to rag on this issue too much, but as a long-time XenForo and Reddit-user, this lack of a smooth handoff between upgrades can be highly annoying / discouraging to me. Then again, the devs aren’t getting paid, so… shut my mouth.
Right so-- as for these new thumbnails, any idea what their limits might be in terms of physical size, data size, and file format? And coming back to the start of the conversation, are these very limits why some of your Moomin strips are hard to read…?
EDIT: Ach! Now, attempts to upload any image (in this case a 148k JPG) as part of a new post shows this error: https://i.imgur.com/olM3gU6.jpeg
That seems like a pict-rs issue, actually. I’ve seen it before, and your instance admin may need to fix it.
The thumbnail problem is somewhat self inflicted.
Before, instances would create thumbnails of such high quality so as to essentially re-host the relevant image. Client developers took advantage of this by using the thumbnail url instead of the full-quality url for faster loading and less bandwidth use, as the server-provided thumbnail was always a small file, and in webp format.
This isn’t what thumbnails are actually for, though… They’re supposed to be a quick-to-load preview, not a complete replacement for the actual file.
I’m using the photon web UI, and there is no way to even open a link to the full quality image in a new tab, here the moomin strips look very blurry. But the default webUI does load the full image when you click it, and so does the mobile client I use, Thunder. Reading them in either of these works fine.
The size limits are determined by server hosts.
The thumbnails are a separate feature, no matter what you post, lemmy servers will create a small thumbnail file that is able to load quickly, for all but text-only posts.
You can also define the thumbnail URL separately when creating your post, if you like, which can work around the current resolution issue.
Really? Double-checking it, I’m seeing two related options here when creating / editing a post:
URL, in which you used to be able to direct link to an offsite image, now broken for Imgur
Image, in which case you upload to the native lemmy server and it will create said thumbnail and store the expandable version
But for example, I don’t believe I’m able to go back to the broken posts and use both options above to fix the issue. It’s either one or the other from my previous testing, as enforced by the Lemmy software.
Most clients just haven’t implenented it. The thumbnail url field is there in the default web UI. (Provided your instance is up to date)
Thanks! I think that solves much of the mystery!
Yes, lemm.ee (my host’s instance) is amazing at updating to the latest stable release in speedy fashion, but I see now that the new ‘thumbnail’ option only applies to new posts, not old ones. Aha.
I suppose this goes far to help explain why all the thumbnails of my old (Imgur-hosted) posts got broken the way they did. Also, “Lemmy” being the amateur project that it is, it seems like this whole thing kinda fits in to a pattern of bumpy updates which sometimes break something that was working earlier.
Not trying to rag on this issue too much, but as a long-time XenForo and Reddit-user, this lack of a smooth handoff between upgrades can be highly annoying / discouraging to me. Then again, the devs aren’t getting paid, so… shut my mouth.
Right so-- as for these new thumbnails, any idea what their limits might be in terms of physical size, data size, and file format? And coming back to the start of the conversation, are these very limits why some of your Moomin strips are hard to read…?
EDIT: Ach! Now, attempts to upload any image (in this case a 148k JPG) as part of a new post shows this error: https://i.imgur.com/olM3gU6.jpeg
That seems like a pict-rs issue, actually. I’ve seen it before, and your instance admin may need to fix it.
The thumbnail problem is somewhat self inflicted.
Before, instances would create thumbnails of such high quality so as to essentially re-host the relevant image. Client developers took advantage of this by using the thumbnail url instead of the full-quality url for faster loading and less bandwidth use, as the server-provided thumbnail was always a small file, and in webp format.
This isn’t what thumbnails are actually for, though… They’re supposed to be a quick-to-load preview, not a complete replacement for the actual file.
I’m using the photon web UI, and there is no way to even open a link to the full quality image in a new tab, here the moomin strips look very blurry. But the default webUI does load the full image when you click it, and so does the mobile client I use, Thunder. Reading them in either of these works fine.