Hi all,
Hope you're well
Thanks for software
As title
Screen shot(s)/cast: https://mastodon.social/@ldexterldesign/99908794887475961
Original for comparison[n]
If anyone else reading this agrees please up-vote or reply "+1"
Let me know if you have any issues - happy to help
Hope this is clear/useful and to hear back
Yours faithfully
[n]
I think currently, images are downscaled if they are bigger than 8MB or bigger than 1024px. #7229 might have something to do with this? Also related to https://github.com/tootsuite/mastodon/issues/2252#issuecomment-379544259
Hey @trwnh,
Thanks for reply
That image is 717KB though?
Cheers
The image is scaled down to 1280 in the largest dimension which is prrrobably not the behavior we want...
Hey @nightpool,
Ha, just read around the issues @trwnh kindly supplied and yes, seems more to do with the dimensions rather than the file size
Cheers
@nightpool does that mean that the scale down we're providing right now is flawed? (am I understanding you correctly here)
The image is scaled down to 1280 in the largest dimension which is prrrobably not the behavior we want...
@nightpool Is it not? There's gotta be some maximum. An image that's at least 1280px in just one dimension can get very, very big. I am almost sure that tumblr uses the same rules (I took the number from them because it seemed like something users would be used to)
In that case, why not limit by filesize instead of by dimension? 1280px isn't enough for legible text. Images should be scrollable in the canvas. If a size limit is absolutely required, make it at least 2048?
Images are often uploaded larger than what is recommended for the web and our 8MB upload limit is for that. But displaying an 8MB picture in a browser window? That's not reasonable. Thinking in terms of dimensions is actually easier here than in terms of file size, because well, you can't tell imagemagick "reduce dimensions until the output fits in this file size limit", you can only tell it "change the dimensions"
I am almost sure that tumblr uses the same rules (I took the number from them because it seemed like something users would be used to)
@Gargron indeed, tumblr does that, but that doesn't mean that's what we should be doing. Tumblr users hate this platform for many reasons, and this is one of them. Up until recently, there was a trick to access the original ("raw") files by changing a few characters in the file URL, but this is not the case anymore since a few days ago. So users are looking for alternatives to tumblr, and Mastodon could be one of them if the original files where accessible somehow, even if that meant changing the URL "manually".
Image resizing has been improved.
Hi @gargron,
Hope you're well
Thanks for follow up
Although it's a resolution enhancement, for my use case I wouldn't say this is a fix
What's the problem with just showing the raw 717KB file?
The file size should take precedence over dimensions
If you have any issues (e.g. questions/queries) happy to help
Hope this is clear/useful and to hear back
Cheers
Thanks for taking the time to look into this, @Gargron , but this is clearly not enough.
I noticed that GNU Social also allows storage and access to the original files. I couldn't determine if this is a default setting, or a per-instance custom setting yet, but I have a feeling this is the default behavior.
Twitter also stores the original files, but serves a downscaled version by default, which is the sensible approach. Users can still access the original file by changing the URI slightly (file.png:large -> file.png:orig)
As of now, Pleroma, GNU Social and Twitter still have better media file support than Mastodon.
Sysadmins who would prefer not to serve the original files under any circumstance (for bandwidth reasons) can configure that on the server side, until Mastodon provides this restrictive feature natively.
I think the best compromise would be for proxies to serve the downscaled files, but users could still access the original (raw) file directly from the originating instance, perhaps by tweaking the URI slightly.
Replacing the "/original/" bit with "/raw/" perhaps? Although, it would make more sense to rename the current "/original/" to "/scaled/" instead, and /original/ should point to the raw file, but that might break previous versions.
BUMP
BUMP 2
Originals won't be kept unless a media quota system is implemented.
@Gargron Why not?
Consideration for admins for whom storage costs money.
Is there an issue for "a media quota system"?
If yes then would be useful to link this issue for context/visibility
If no then I'm happy to create one so we can continue this discussion there
I don't run an instance so don't know the config' granularity but it seems beneficial for admins to have full control of media quotas in case they're running media-centric (e.g. video, image) instances
Hope to hear back
Cheers
BUMP
OK, created #11808
Most helpful comment
The image is scaled down to 1280 in the largest dimension which is prrrobably not the behavior we want...