Lower compression for sent pictures

[ghost]

It would be nice if pictures which are sent over the data channel aren't so highly compressed.

[dkasak]

I was under the impression (from reading this thread) that the compression was changed to cap the images at 1280x960, but I still see larger images downsized to 768xY when sent through TextSecure with the latest version on both phones. Why is this happening?

I would also appreciate a higher default and an option to send full (or nearly full) resolution images through TextSecure. My contacts and I are frequently on wifi and our data plans are not bad either. TextSecure would be a really convenient method of transferring images quickly and confidentially if it wasn't for this. This is a relatively high utility feature for this reason, IMO.

[mcginty]

If you're on a device with a limited amount of memory, images are sent with a max of 768 in either dimension. Otherwise, the max is 1280.

[dkasak]

Oh. What is considered a limited amount of memory?

[mcginty]

If you're on KitKat or higher, Android has a flag to alert us that the device we're running on is in a low memory class. Otherwise, we decide you're low memory if the "memory class" (read: the max heap size for our app) is <= 64. I'd love to change this, we were just having out of memory errors on send too often so had to do something about it.

[BlacklightShining]

@mcginty 64…what? 64 MiB? That sounds pretty low, even for a phone. Even so, normal stills captured from the camera shouldn't be more than, what, 4 or 5 MiB? And if there isn't a limited amount of memory, why have the cap at all?

[agrajaghh]

@BlacklightShining a single 24bit image with 8 megapixels has an uncompressed size of over 20MB...

64MB is not the device memory, its the maxmimum available memory for a single app (afaik)

[mcginty]

what @agrajaghh said

[BlacklightShining]

@agrajaghh When would you ever have to deal with an uncompressed image, though? Don't pretty much all devices immediately compress pictures with JPEG?

[mcginty]

@BlacklightShining images are uncompressed bitmaps when loaded into memory. read the android docs if you're interested in how image memory management works.

[BlacklightShining]

@mcginty Ahh.

[Dyras]

@mcginty So what exactly qualifies as "limited amount of memory"? I have a Galaxy Nexus with 1 gig memory and every time I receive a picture it's 1280x720. The picture is 119 kilobytes and that seems awfully low, and the picture itself is just really ugly. Any chance you could knock it up to 1920x1080?

However it's entirely possible that my eyes are broken. Or maybe I'm too spoiled by my full HD screen. Here's the picture I'm talking about.

[generalmanager]

This specific image looks shitty because of the low light conditions in combination with the tiny cellphone camera without quality optics.

In other words: even the raw picture will look shitty, because the physical conditions were too bad for the tiny sensor.

The resolution is always a choice between cost (real costs for server+bandwidth at OWS and usability costs like increased upload times and data usage) and reward.

At the current resolution a tightly printed piece of paper is still legible and good quality pictures look good on >=7 inch screens. The costs usability costs are currently low enough to provide low sent times even on slow 2G networks.

A simple calculation shows that your request would more than double all associated costs: (1920_1080)/(1280_720)=2.25

But the reward in terms of image quality is very low. That's because the root cause of bad picture quality is generally not low resolution but bad lighting, bad focus and other drawbacks of crappy smartphone cameras.

[Dyras]

Yeah I figured it was the lightning in that specific picture, but typically every picture I receive looks like crap, regardless of where I take it. But I can live with that I guess.

[eoguy2003]

Hello,

Has any one tried sending MMS attachment using default android messaging apps to Signal and ended up with blurry image / text totally not readable?

Below is my scenario between a LG G Pro 2 and LG G3 phone, screen shot done using the QuickMemo function.

A screen shot of the registration verification sms sent by Signal is originally a .png file 140KB size with resolution of 1080x1803.

Signal to Signal , this same attachment became a jpeg file 44.77KB in size and resolution 766x1280 - text in image is readable.

default Messaging MMS to defafult Messaging MMS, this same attachment became a jpeg file 70.53KB in size and resolution 647x1080 - text in image is readable.

Default messaging MMS to Signal, this same attachment received by Signal became a jpeg file 2.20KB size and resolution 77x128 - basically became a patch of blur, nothing readable.

Another friend who used iPhone 6s default messaging apps to send me a text screen shot also became just a patch of blur.

Any idea if this will be fix?

Thank you.

[agrajaghh]

@eoguy2003 this looks like a diferent issue. Please open a new issue including a debug log (after receiving a MMS with a tiny image like that)

[eoguy2003]

Hi agrajaghh,

From what I read in this thread, there are users encountered similar issue since 2014, and the new issue "Image quality #1629", which was redirected back to this thread.

I'm using Signal version 3.10.0 btw.

I suppose this is issue is not a priority then? It's coming to 2 years since this thread was first started and no 'Assignee' yet - I'm not sure if this means no one is looking into this issue literally?

Don't get me wrong, I greatly appreciate the efforts put in by the developers to come out this application for normal users like me.

Hopefully this will be fix in the next release then.

Regards.

[agrajaghh]

@eoguy2003 this issue is about image compression in data/push messages on the sending side (which got already improved some month ago)

your issue seems to be a display (?) problem of MMS on the receiving side (IF this is a Signal problem)... please open a new issue and stop posting here.

[tx3eh8IUD1]

I just wanted to inform everyone (except the maintainers :)) that you can circumvent the low photo quality:

if you use groups to send images (tested on Android to Android), the image is sent in full quality! This works if just two people are members of a group. That is currently my workaround whenever I try to make sure that the photo is being transmitted in acceptable quality.

(Honestly, I also rename files as .mp4 to send them through signal, such as .pdfs)

Edit: this is through push, not MMS.

[dkasak]

So I kind of forgot about this issue for a while and tolerated it since I don't send that many photos. However, someone just sent me an important photo of some text over Signal which was rendered illegible so the problem is still here. The original was a 3264x2448 image with a size of 1.88M which Signal (rather badly) downsized to a 432x576 image with a size of 28.68K. From what I've gathered by reading this bug report, this shouldn't be happening anymore. mcginty mentioned something about memory classes, but I'm on a device with ~1.3G RAM with 500+M free at the time I received the image. Regardless, is there some way I could check how much memory Signal is allowed to allocate on the heap (i.e. the "memory class")?

I should mention that using tx3eh8IUD1's workaround by transferring the image through a group with two members worked and the image was transferred unchanged. So why is it that images transfer through groups perfectly while getting so botched when sending them 1-on-1? It sounds like there's still a bug somewhere.

@mcginty, I saw you unassigned yourself from this bug so I apologise for bothering you, but do you have a clue as to what might be going on?

[fractalf]

i just downloaded this app, but low res images and error on sending video is a big show stopper. too bad cause i really dont wanna use whats app, but at least there these basic things work. in 2016 one should be allowed to send a message of a couple og mb if one wants to

[awnumar]

Agree with this. The level of compression is absolutely ridiculous.

[zoff99]

why not just send images as-is without preview. just send the file 1:1

[awnumar]

How do you do that?

On 17 Sep 2016 07:43, "Zoff" notifications@github.com wrote:

why not just send images as-is without preview. just send the file 1:1

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/WhisperSystems/Signal-Android/issues/672#issuecomment-247753397, or mute the thread https://github.com/notifications/unsubscribe-auth/AIhzn6KcrKB-LWIfJ0X_qfgP0bNR1qFTks5qq4wJgaJpZM4BkrZo .

[zoff99]

well, how do you send a normal file (video, pdf, whatever) ? send the image as-is

i mean the developers should make an option to do so

[awnumar]

Not possible in signal.

On 17 Sep 2016 12:21, "Zoff" notifications@github.com wrote:

well, how do you send a normal file (video, pdf, whatever) ? send the image as-is

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/WhisperSystems/Signal-Android/issues/672#issuecomment-247764004, or mute the thread https://github.com/notifications/unsubscribe-auth/AIhznzRCv8izJNVzYN-9sYi3qy15Au8mks5qq81KgaJpZM4BkrZo .

[zoff99]

what do you mean not possible? for 2 1/2 years this problem has been reported, and there is no possible solution or workaround?

just make an option to send images "as is" without the preview thumbnail

[awnumar]

You mean add it as a feature? Sorry, I thought you meant it's already possible.

On 1 Oct 2016 09:14, "Zoff" notifications@github.com wrote:

what do you mean not possble? for 2 1/2 years this problem has been reported, and there is no possible solution or workaround?

just make an option to send images "as is" without the preview thumbnail

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/WhisperSystems/Signal-Android/issues/672#issuecomment-250899864, or mute the thread https://github.com/notifications/unsubscribe-auth/AIhzn_4jA3gGwck3fwlGKYZxBC5tZC25ks5qvhZ8gaJpZM4BkrZo .

[impishj]

Paradoxically images can be increased in size and then jpeg compression can be ramped up to it's maximum compression ratio and you end up with a higher quality image that is about the same file size as a 30-40% compression.

This might be a good approach here to leave the image size relatively high but go crazy with the jpeg compression.

[zoff99]

why not just add the feature to send image file as-is (without preview) ?? i dont understand?

[fractalf]

Or any file type for that matter. If I wanted to send a coolproject.tar.gz file to my friend, I should be able to. It would make signal stand out among a sea of messengers

[zoff99]

i think a file size upper limit would be good. otherwise people could overload the signal servers

[ubergeek77]

If anyone remembers, the workaround for this used to be sending messages as a group. That way, we could send pictures through Signal, large enough to make text legible if you're sharing, for example, a whiteboard, or a page in a book. Unfortunately, that workaround has been recently "fixed" (read: patched), against the wishes of the outspoken few in that issue's thread: https://github.com/WhisperSystems/Signal-Android/issues/5461

So I wonder: would it be possible for someone to fork Signal and apply that "bug" (which, as I'm sure everyone agrees, is actually the preferred behavior over the current compression), to the 1-to-1 conversation attachment behavior? It would make a lot of people happy, I'm sure. At least in the interim until this issue gets fixed officially (2 more years at least, at this rate). If I need to send a picture to a Signal user, and I need them to actually be able to read it, now without the group workaround, I have two choices: send the image through MMS, or email it, both of which completely go against Signal's core philosophy of being encrypted and secure. In other words, as long as this issue remains an issue, Signal is indirectly encouraging the use of insecure means of communicating.

I know this is a messy solution, and it's not at all ideal, but after seeing this issue open for so long with little to no attention, I no longer see any "short term" solutions.

Here's to seeing a solution soon!

[zoff99]

moxie is stubborn like always. this probably wont get fixed. the thing with forking is, you still use the Signals server. moxie sure won't like that. also what's the use of forking when your chatpartner does use the "unforked" version? so either a offical soluton, or it's really no use :-(

whispersystems are always going on about, how many journalists are using signal all over the world. i wonder how these journalists think about sending important photos which get compressed so much?

[moxie0]

lol, another example of how working on an open source software project serves as my modern day zen practice: without fail, every day, it causes me to really consider what it is that I'm doing with my life.

Anyone is welcome to put together a PR, but it would have to account for all of the considerations already raised in this thread. It's not as easy as just sending full resolution images around and hoping for the best.

[ubergeek77]

Thanks for the input, moxie. It's great to hear from you about this, and I'm sure a lot of us appreciate the invite on moving forward with it.

But was being so snarky about it really necessary?

[zoff99]

@moxie0 "It's not as easy as just sending full resolution images around and hoping for the best."

it should be easy to send fotos as is, without preview (with an upper filesize limit). can you confirm that you would merge a feature like this?

it's the same with sending a video now. when i send a video from android to iphone i get this on the iphone:

so it seems half working stuff can be merged into Signal repo.

[moxie0]

But was being so snarky about it really necessary?

Only as necessary as the gratuitous insults.

it should be easy to send fotos as is, without preview

I don't know what this means. What is a preview, and why don't you want one?

it's the same with sending a video now

Videos are streaming resources, not something that you load into memory all at once. They also can't effectively be compressed, and are transmitted much less frequently than images. This is why we have different settings for what media types are auto-downloaded in different network environments.

Whatever we do with images needs to accommodate users in low bandwidth conditions or on low memory phones, perhaps adaptively.

I can't read german so I don't know what that screenshot says.

[Trolldemorted]

it says "unsupported attachment type received".

[moxie0]

it says "unsupported attachment type received".

Thanks, this seems unrelated then. To deal with these types of problems with video/audio we'd need to build a compatibility matrix of supported codec and container formats on android/ios/desktop and then do client-side transcoding when anything is outside of the intersection.

[zoff99]

"I don't know what this means. What is a preview, and why don't you want one?" i tought the preview of a foto is the reason why it needs to be loaded into memory. and thats part of the issue. so my reasoning was, no preview, no compression, no lowmem issue. maybe this is wrong then.

low bandwidth is a different thing.

so maybe the best solution would be to add a "send file" button. select a file to send and at the other end just to option "save file as". without preview or any other special thing. if the selected file is greater than some max_filesize then don't allow to send it.

would this be a possible direction to go?

[jeremymasters]

It'd probably also good to advertise the size to the recipient in the request to download before the download occurs.

[moxie0]

i tought the preview of a foto is the reason why it needs to be loaded into memory. and thats part of the issue. so my reasoning was, no preview, no compression, no lowmem issue. maybe this is wrong then.

When you want to display an image (either a thumbnail or otherwise), the full uncompressed bitmap needs to be loaded into memory.

so maybe the best solution would be to add a "send file" button. select a file to send and at the other end just to option "save file as". without preview or any other special thing.

If you want to add a mechanism to send arbitrary file types, that's fine, but it's not simple. It'd have to be a coordinated change across ios/android/desktop, and if you want to send images without being able to display them (?), you'd have to define a custom mime type that all clients understand which says "this is an image, but don't display it."

Ultimately I think we need someone who understands all the considerations in this issue to determine:

1) What it is that we're trying to accomplish. Do we want to enable the transmission of full unaltered images, or is the current scaling just too aggressive by some amount?

2) If the latter, what is that amount, why, how do we quantify that, and how can we justify or accommodate a change given typical network and device limitations? If the former, how would that be compatible with the same limitations?

[jeremymasters]

I think perhaps the most simple solution might be to not mess with the height x width dimensions, but to only scale jpeg compression/quality when resizing. Might be able to keep some of the same logic of file size checking that way.

[TimesEnemy]

With regard to the determination moxie0 listed above, is it difficult to give the user the choice of compression level? For instance, default to whatever is currently being done, but provide some type of sliding scale which would change the compression level? If this is within the realm of possible and acceptable, then just to add more creep, it would be good if the compression level default could be changed by the user.

With this type of option, if USER1 sends an image to USER2 with default compression, USER2 could respond and say, "cant see. u suq." Then USER1 could resend with smaller to zero compression.

Each user would have to find the sweet spot for the type of image(s) they are sending.

Yes, this could create more network traffic, as the same image is being sent more than once. But if someone is complaining about image quality they are most likely open to more network traffic to support a "better" image. Also, this seems to meet the requirements listed by those asking for this feature, and IF it is not a PITA to implement would provide the Devs with an opportunity to close this. :)

[moxie0]

With regard to the determination moxie0 listed above, is it difficult to give the user the choice of compression level?

The answer is not more options, and there are no power users: https://github.com/WhisperSystems/Signal-Android/blob/master/CONTRIBUTING.md#development-ideology

Additionally, this is a change that not only affects the sender, but also the recipient. The sender might have unlimited data and 4GB of ram, the receiver might have expensive edge service with a low memclass device.

[haffenloher]

Personally, I haven't really had problems with the compression, but maybe someone could provide a few test cases for which the current Signal Android code performs badly? (e.g. panoramic pictures?)

This way we could try to come up with something better within the current memory and file size constraints. I'll take a look if someone provides these test files (ideally: files before compression, files after compression, files after compression on a lowmem device).

[jeremymasters]

What I see in photos are lots of jpg artifacts like haloing when a jpg has had too much compression done to it or it's done repeatedly with not-so-good algorithm. This is especially exacerbated when you have something like a white sheet of paper with black text on it like a recipe. I'm far more familiar with Photoshop than whatever Android uses for jpg work. Right now, I have a phone that shoots 16MP pictures (5312x2988) and with a fair amount of detail, like leaves, it's ~8MB. I have a photo with apples and grass (some fine detail, some smooth) that at full resolution is 5.8MB. I don't know what the exact target would be for file size, maybe < 5MB? Moxie's servers, so Moxie's rules here :smile: I would think that part of this is that we should be able to expect non-rude senders too. If someone has a device that is on the lower end, the folks sending them images would have a good idea of this and not send stuff that is huge. Maybe if they were rude once, the receiver would let them know the error of their ways. Whatsapp is probably a good example of something that is used on lower-end phones quite a bit and it seems that it cuts things to about 75% of original size but the images are very good quality. No idea what they use and how hard it would be to reverse engineer it. It's amazing what using even 75% quality for a jpg setting does for reduction in size of the file yet leaves a pretty high quality photo. Sorry I don't have more concrete things like a PR. Just wanted to share my thoughts on this as a person who enjoys photos but understands some of the limitations here as well.

[moxie0]

@jeremymasters Right now we're scaling to a max edge of 1280 and a max size of 420KB. It sounds like you're saying that you might feel good about image quality at a max edge of 1700 and a max size of 5MB?

My concern isn't really server storage, it's more that right now images are transmitted quickly and that making them larger would change that. But if people don't want to send images because they don't look good, then it's no consolation that they're transmitted quickly and will load on low end devices.

[jeremymasters]

@moxie0 speed of transfer makes sense to me as well as not going hog wild on data. I would be ok with 3MB really. I think it's the jpg compression quality setting that might be getting us. I think whatsapp in app camera for me is around 3800px on the long side and was ~2MB

[moxie0]

I'm not sure, but on WA I don't think the sender's side is scaled. When you receive a WA photo there's a 3800px edge?

We use compression to meet our max size requirements. First we scale the photo down to below a max edge of 1280, then start at 80% quality and do iterative trial compression with decreasing quality until we've gotten below our max file size.