The new automatic compression for images is too high. I send a lot of text screen shots in Delta and the automatic image compression is making them difficult to read — fuzzying up small text. Can we get a setting for “Outgoing Media Quality” to only do lossless compression?
a global “Media Quality / Lossless”, would do more harm than help for overall UX if “just so enabled” as the receiver’s bandwidth the sender cannot know about would be wasted
Seems like the user ought to be trusted to know who they are communicating with, at least more so than the developers. A default “safe” setting seems fine, but not letting the user make a choice is extreme. Why even have a choice between “balanced” and “small size” if the user can’t be trusted to know who they are chatting with?
The client has the “Auto-Download Messages” setting that appears to let recipients control their own bandwidth usage. Isn’t that sufficient?
if you really want to bypass compression, you can already now send images as file.
Manually attaching screenshots doesn’t make sense in the context of saving bandwidth either. If the user can’t be trusted to know who they are communicating with, then taking away the convenience of cut-n-pasting clear images doesn’t change the impact on bandwidth, it just reduces usability. Painfully.
thanks a lot for moving the feature proposal here!
having few options is one of the central ideas, even if this cut some usecases
maybe a global “always lossless” would not be the end of the world, however, i outlined in the original post why i am pretty screptical, esp. if this is a minor usecase.
this is also what many other messengers are doing; there are ideas to improve that flow similar to what telegram or whatsapp introduce recently, eg. having an unobtrusive kebab-menu in the staging area that allows “send original file” - which then also makes visually clear the file is send as “original file”, including metadata etc.
but maybe we can also tweak the “Balanced” setting. however, some example screenshots we’re talking about in detail would be helpful. eg. sending this page as screenshot lgtm, also many screenshots i sent from android or ios are not overcompressed and still look good. i’ve seen overcompression mainly in huge PNG that have lots of details, diagrams or flowsheets or so - but not for the majority of things. (“Balanced” should be fine for the majority of images an average user will send around)
I took a cropped a section of the before and after and put them side-by-side to make the degradation in quality easier to see. Pixels are one-to-one from the files, the reduced size on the right is from delta’s processing. I saved this combined image as a jpeg with very low compression, with the hope that the forum software won’t recompress a jpeg.
I realized that the degradation was more apparent if made the images equal size, as that is how a recipient would read them. So this is the original on the left, and then the delta-compressed version on the right, but scaled up to be equal size.
indeed, in the examples, there is quite some (expected) worsening by the compression.
the solution in case of “lots of text in big screenshots” is the mentioned compression bypass by attaching the image as files:
as outlined above, there are ideas about how to improve the flow, but that is the current state. esp. on desktop, the flow is the same - you only need to select “File” instead of “Image”.
if this is still overcompresses or compresses at all, this is a bug that we need to fix.
for some reasonings why the compression was introduces at all, see eg. recode large PNG · Issue #3956 · deltachat/deltachat-core-rust · GitHub - tl;dr: without compression many images are ten times larger, wasting bandwidth and space. eg. PNG screenshots explode unexpectedly in size if there are photos in
there was also the idea to allow larger width/height for PNG, which was abandoned for simplicity then - we can think over reviving the idea, do you think, that would help on your issue as well? (you can try that out by eg. not scaling the screenshot but save it as JPG with eg. 90% compression) - but whatever we do here, there are always situations, where the compression is not great, this is expected and the tradeoff - where one should attach using “File”.
I don’t know how other people send screen-shots in delta, but the way I do it is:
right-click for context menu in firefox
Choose “take screen shot”
draw the rectangle to select the part of the screen
hit “copy to clipboard”
flip over to delta
hit paste and then send
Saving to a file; navigating to the directory where the file is saved; and selecting the file more than doubles the amount of effort. After three or four of those, the extra work really starts to add up.
I understand that this change is motivated by concern for people who are not provisioned to receive large messages. But using the given workaround puts the receivers at exactly the same risk as before, only now the sender is inconvenienced.
I suspect that simply allowing a “don’t compress” option for image quality would cover most use cases. As a safety feature, maybe also add an (optional) warning on send that the message is very large? That would be useful in all cases where attached files are very large, not just images.
thanks a lot for coming back! we’re getting closer to a shared view i’d say
as you’re using the clipboard for screenshots (others go over “files”, me as well), your workflow would benefit largely from the idea of having the option to switch between “image” and “file” also in the “staging area” (as done eg. in telegram)
But using the given workaround puts the receivers at exactly the same risk as before, only now the sender is inconvenienced.
this is not really the case, as the workaround does not happen “just so” when a user does not think about image size or has a wrong idea if suddenly a screenshot is 10x larger as there is a photo in.
we’re also hesitant against a global “don’t compress” as this would affect not only screenshots - it is not always easy to differ between image types (screenshots can have photos on etc.), and we do not want even more options to the user as “compress JPG like that and PNG like so”. having a global “don’t compress” would also weaken the UX element “image”, being always fast and efficient, not needing much space on disk but offering acceptable quality (not for everything - eg. also not for high-quality printouts)
it is all about having good defaults that cover most usecases - and even if you are not happy currently, i do not think, we have a totally wrong tradeoff atm (before, user got tons of screenshots from mobiles having 5mb or more eg …) - also, trying out the firefox thinge, i really have to select large portions to end up beyond 500k of text-only (below 500k, nothing is recoded - and if you have photos in addition, recoding to jpg seems very welcome)
but anyways, beside making switching to “file” also easy for clipboard, maybe we can also tweak the max. allowed size of screenshots as it was the idea already above - the 1280px come from “photos” mostly, indeed, for PNG we can get higher and maybe allow 1920px or so? maybe also allow more than 500k before starting recoding? i think, that would improve your usecase directly - and is also more foreseeable that updates to the staging area (also, all system would benefit directly from the change)
TBH I can still read the compressed example…
I think both the button to change to send as file and the larger image dimensions would be nice.
I already had some screenshots that were barely readable or not readable anymore, especially whole scrolled webpage screenshots like you can generate in Firefox and on iOS in safari and some os versions in android.
