Signal-android: Lower compression for sent pictures

[ghost]

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

[m0jo]

Why? Compressing/Decompressing doesnt use that much CPU as it would make any significant difference.

[monreal]

Are we talking about lossy compression?

[zofrex]

Here's a photo I took earlier and this is what it looked like after sending it via TextSecure. I only realised something was up when the recipient asked me where the event was - the poster isn't even readable :(

[cgarrett]

I'm having this same issue. A friend sent an image with small text in it, readable on the original image, but completely obscured after he sent it to me.

[wx0b]

This has been an issue for quite a while for me. I use TextSecure for SMS, but have to disable it and use the stock app for MMS due to the heavy compression.

I sent a 1.3MB image to a friend, it gets compressed to 70kB when he receives it, unencrypted, encrypted, sent, received... all gets compressed

Here is an album with screenshots of closeups, original file, and version sent/received from textsecure

[ghost]

I meant the compression of the picture itself, not the client server compression (didn't know that tectsecure also compresses the transfer). As the others explained the pictures are pixelated once sent/received. People are used to get compressed pictures (WhatsApp), but the picture should be compressed in a moderate way.

[lapseofreason]

+1 for higher resolution images, although in my opinion it's not a high priority feature

[phime42]

currently experiencing the same problem, making sharing of text pages not enjoyable

[hunleyd]

+1

[mcginty]

Yeah, TextSecure does seem to do some excessive resizing/compression before sending. This is especially not required in the push case.

[tinloaf]

So @moxie0 what would the maximum size of pictures be that you would "allow" on the server? After all, you are currently providing the storage space for them...

[jeremymasters]

+1 on this as well for me. it's actually much worse than I thought after examining a photo last night. Wasn't there discussion on raising the limit of an attachment size if sent over push/data?

[moxie0]

There is a 'media' branch here that handles this correctly, we just need a few things from @mcginty on it.

[thenktor]

@shmartens : other messengers like WhatsApp also reduce the size of the picture. This actually is a good feature because mobile data plans are sometimes very limited. The problem with TextSecure (compared to WhatsApp) is that:

1. The image resolution is even lower. It seems to be just 360x480, which is very low for today's usual 4"-5" smartphone displays.
2. The used algorithm for resizing seems to be low end

[KayuHD]

What about an option to set the picture size, like Threema do this?
Not everyone has a very limited data plan (5GB per month).

[zofrex]

It's not unreasonable to resize the image, even though I have a large plan there's very little value in sending my photos at full resolution - it takes a lot longer as well as eating data, and in most cases the image will only be viewed on a phone screen so preserving the original res doesn't add anything.

The resizing algorithm does seem to be a bit worse than WhatsApp - their images are much higher quality but not much larger in bytes. Here's the results from my very unscientific testing with a sample size of one:

| Service | Resolution | File size | Subjective quality |
| --- | --- | --- | --- |
| Original | 2448 x 3264 | 2 253 kB | 5/5 |
| TextSecure | 360 x 480 | 88 kB | 1/5 |
| WhatsApp | 612 x 816 | 100 kB | 3/5 |
| MMS | 435 x 580 | 145 kB | 1/5 |

For what my $0.02 are worth, I don't think an option to change the size is that useful - as long as it doesn't use huge amounts of data and doesn't look terrible, I don't really care and don't think most people would.

[wx0b]

I prefer that my images are not manipulated. The stock MMS app does not resize my pics (that I am aware of.) Why would I want textsecure to do that? If I want them resized, I will resize them before sending them.

[KayuHD]

@zofrex With size I mean the resolution, because the current is too low. All pictures with text in it are waste. When the compression is good enough without artifacts, should it be all right for me.

[zofrex]

@wx0b MMS apps typically compress images very harshly (even my feature phones did this), I've updated my results with the stock Messaging app to my table.

[thenktor]

@wx0b Manual resizing of pictures before sending them is the most uncomfortable thing I can imagine in a mobile messenger app. It needs at least twice the time in a point, shoot and send situation. Also common users even have no idea how to do it. I'd rather add another option "Send picture (uncompressed)" to the attachment menu. But also on the receiver side I would not want my app to autmatically download uncompressed images and waste my limited data plan.

@KayuHD Currently pictures with text in it are not the only problem. A usual wide anglöe picture with some details looks horrible, too. IMHO a resolution of 1024x768 with a better resizing algorithm would be a good compromise :)

[generalmanager]

The only legitimate use for an "send uncompressed" option is something like Pixelknot: https://guardianproject.info/apps/pixelknot/
We could make this accessible by long-clicking an image before the message is sent.
This way it doesn't add clutter to the UI and the functionality is still there.

As newer phones have full HD screens we might consider something like 1280*x as the size of the compressed image. But I'm no expert in image compression, so I don't know where the sweet spot between file size and image quality is nowadays.

[thenktor]

I guess it's somewhere in between 1024_x and 1280_x ;)

[KayuHD]

My wish is at least 1024*x, but changable resolutions, like 640, 1024, 1600 or 2600 in the options would be very nice.

[generalmanager]

We should try to keep the UI clutter and number of settings as low as possible. Personally I would like to have this option too.
Bu in order to keep TS slim I vote for either 1024 or 1280 as default and if the user needs to send the original image without any changes, he can long click on the image to do so.

[KayuHD]

Yeah, better leave it simple. I vote also for at least 1024*x.

[thenktor]

:+1:

[jeremymasters]

Just make sure it's the long side of the pic that is 1024 or whatever. I've seen other software forget to look at longest side and the results for rotated pictures are disappointing.

[KayuHD]

@jeremymasters :+1:

[SlappyHours]

Since this is quality vs. traffic, I would vote for 1280 (longest side) which means HD 1280x720 for an 16:9 image.

[jbaker6953]

This bug is extra annoying because TextSecure even resizes and compresses incoming images. This is the single reason I have to disable TextSecure as the default messaging app, so it won't intercept and destroy my images.

[agrajaghh]

I got several complains from my friends as well, the image resolution is definitely too low. But the problem could be that bigger images take more space and need more traffic, so they cost money....

[jbaker6953]

There is no problem with bigger images. The stock Android messaging app does not alter images as TextSecure does. As it stands, TextSecure is fundamentally impaired in comparison. The pictures from TextSecure are so small on my screen that I often can't even see what it is the sender is trying to show me. As far as I know there is no workaround when receiving messages from other TextSecure users. There is no reason for TextSecure to do anything to MMS attachments other than send them as I attach them.

[agrajaghh]

@jbaker6953 I was talking about push messages. I'm not using MMS.

edit: btw this issue is about sent images over the data channel, perhaps you should open another issue if TextSecure compresses incoming MMS images in comparison to the standard MMS app.

[Bastelbursche]

There is a media branch with a commit to allow larger media transmissions since march. But it seems not finished.

https://github.com/WhisperSystems/TextSecure/commit/d3568cadff2a3827cd2fb63ae599674ae86ffc27

[thenktor]

Hopefully hihjer resolution pictures get in main branch soon. My few TextSecure contacts already are using Threema again for sending pictures because quality is so much better there :(

[piratenpanda]

Same here, would love to use TextSecure 100% but I'm currently using threema for sending pictures at the moment.

[Bastelbursche]

@piratenpanda Meanwhile TextSecure sends pictures with a resolution of 1280x960 and good quality.

[piratenpanda]

Still, why no preview and download in full resolution when the user wants it? That's the way threema does it and it seems fine to me.

[thenktor]

@Bastelbursche thanks for the info, I did not even notice because nobody has sent me a picture since this was changed :)

[bconway]

Has this bug been fixed? I don't remember pictures at 1280x960 the last time I used TextSecure.

[piratenpanda]

Yes, images are currently 1280xX

[thenktor]

Yes, probably you and your friends need to update to latest version.

[jeremymasters]

So should this bug be closed then?

[mcginty]

Some recent MMS fixes have us making better use of the tiny space available to us (300kb on most carriers), so yeah the 1280px max dimension increase and less compression has helped.

I'm going to keep this issue open though since I agree we should be sending full-sized images via push and that is not yet implemented, which is what the issue is originally referring to.

[thenktor]

@mcginty The original issue was: "It would be nice if pictures which are sent over the data channel aren't so highly compressed."
So there is nothing about full-sized pictures.
And I don't think full-sized photos should be send via push because with nowadays 13 MP cameras on smartphones sending can take ages and easily eat up the data plan.

[generalmanager]

@thenktor There's a difference between full size (=full resolution) and uncompressed. Obviously sending all pictures uncompressed at full resolution can eat up a lot of valuable mobile data. And only sending the uncompressed images if the device is on wifi doesn't help the receiving device(s) either.
Thus I think having the option to send images uncompressed at full resolution should not be the default behaviour either on wifi or mobile data. But there are cases in which maximum image quality is neccessary, which is why I'd like to see the long-press solution I mentioned earlier. Increasing the default resolution on wifi to maybe 1920*x when on wifi could be interesting, but I agree that a messaging app should not be optimized for high quality picture sharing, but lightweight and uncomplicated message transport and storage.

[jeremymasters]

I like the idea of long-press option for full-size but 1280x960 seems pretty good for regular mms pictures. The trick is, does the receiver want to potentially get data chewed up or take up space on their device if it has a small amount of storage.

[mcginty]

I misspoke. When I meant full-size, I mean more like a size that will actually occupy an entire modern cellphone display (>≈1920x1080), not necessarily sending raw 41MP shots or whatever.

Since we won't be constrained to 300kb in push messages, we can have much less aggressive compression, so this won't be a problem when we get the media changes in for push, which is in the works.

[BlacklightShining]

As a user, realizing the image I sent had been downsized was an unpleasant surprise. I would rather media not be lossly compressed at _all._ Just let the TS network reject it if it's too big (so we don't have to wait for specific client updates to raise the limit), and maybe provide a quick way to open it in an editor so I can resize it myself. (Generous limits on file size would also be nice.)

[its4everyone]

This is definitely an issue for me as well. Textra is currently my default texting application due to this setting alone. It renders any pictures I send/receive nearly useless, especially if there is some important/pertinent text contained within.

[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" [email protected] 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" [email protected] 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" [email protected] 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.

[billie80]

Scaling to a max edge of 1280 is probably the reason why panoramic images do not look good. Imagine an image with a resolution of 12800x1000. Scaling this leaves only 100 px in height. On my device I get approx. 7650x1150 px in portrait mode and 6000x500 px in landscape mode. So why not scaling to the min edge instead or only then if the aspect ratio reaches a certain value?

Edit: This does not make sense. A solution would be scaling to the min edge when the image reaches a certain aspect ratio but obviously then using a lower resolution than 1280, else the previous method would increase panoramic images in size.

Also 420 KB seems a little low for today's camera resolutions. If I am right about the memory restrictions the file size of the resulting image (due to compression) does not matter that much but the resolution, because it goes to memory uncompressed.

[moxie0]

@billie80 JPG compression is lossy, so there is a correlation between file size and memory consumption.

[billie80]

Hm, when I have an uncompressed bitmap file, disk size is equal to memory size. When I compress it as jpg disk size decreases while the memory size remains the same. So memory size only depends on the resolution (number of pixels) and color information, or am I wrong?

[jeremymasters]

@moxie0 So I had another look at my whatsapp scenario. If I take a picture with the normal phone's camera app, whatsapp sends it how it is. if i take a picture with Whatsapp's built-in photo capture, it does reduce the HxW to about 75% of normal camera dimensions but I don't know if that's an arbitrary integer value or a percentage under the hood.

What target value for filesize are you guys looking to hit, 1MB? Feel free to refer me to code, btw. I haven't programmed any Android but I do code so maybe I can sort through it a bit and not bother you so much with baby questions.

[UNIcodeX]

I did some testing last night between Signal and Textra. I had someone send me the exact same picture through both apps. The picture, as received in Textra from Textra (regular MMS) was 1121x1992 resolution and 555 KB in size. The picture, as received in Signal from Signal, was 405x720 resolution and 66.63 KB in size. The picture as received through Textra is roughly 2.7x better quality, and it's still just over half a MB. The original picture's resolution is 5312x2988, but even when compressed to 1121x1992 it was much better visual quality than the 405x720 from Signal.

Textra's settings have an option to limit MMS pictures for 1,000 KB. It states that this constraint is so that the provider does not reject the MMS message.

Digging around in the code, I traced a possible cause for this issue to the following file, which contains code for defining constraints on the images. Currently it is set to 1024x768, or even lower still if the device returns a state of being low on memory: /src/org/thoughtcrime/securesms/mms/MmsMediaConstraints.java

public class MmsMediaConstraints extends MediaConstraints {
  private static final int MAX_IMAGE_DIMEN_LOWMEM = 768;
  private static final int MAX_IMAGE_DIMEN        = 1024;
  public  static final int MAX_MESSAGE_SIZE       = 280 * 1024;

  @Override
  public int getImageMaxWidth(Context context) {
    return Util.isLowMemory(context) ? MAX_IMAGE_DIMEN_LOWMEM : MAX_IMAGE_DIMEN;
  }

Two possible avenues for improving the quality of images:
A) Increase the resolution of the constraint - This is the easiest and quickest to realize.
B) Modify the constraint to be calculated on file size, rather than resolution - Perhaps a long term goal after implementing option A.

[dkasak]

Currently it is set to 1024x768, or even lower still if the device returns a state of being low on memory: /src/org/thoughtcrime/securesms/mms/MmsMediaConstraints.java

I'd like to note that I encounter this case regularly with almost all the people I converse over Signal. I've seen it happen in conversations where both participants had relatively new phones (like Samsung Galaxy S5 or S6) which have plenty of RAM, so the "low on memory" state seems to either be triggered erroneously or it is a misnomer and the constraints are too stringent.

[UNIcodeX]

Good point dkasak. I failed to mention that the devices used in my testing were both LG G4 Android phones. At the time, free RAM would have been around 500 MB. I'd have to test again to get an accurate number for free RAM.

[jeremymasters]

I don't think it's free memory they are checking. It's what the device itself is classified as. Like if you hit the debug log in your android app, it should have a memclass. Not sure exactly what that's based on, but unless it's lowmem, I'd consider 3MB a good limit instead of the pixel count.

[UNIcodeX]

I agree. 3MB, with today's internet speeds, is fairly small. A user defined file size constraint for attachments could even be implemented in the settings. Not to exceed a hard coded ceiling value. The constraint could be (would have to be) smaller for an MMS, than it would for going through Signal servers, so as to keep from being rejected, but I think people are able to understand the limitations of SMS/MMS.

The question is... Will the developer make the change(s)?

[jeremymasters]

I think they are open for changes, but with the caveat of:

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

[UNIcodeX]

Fine with me. Just set more sane upper limits, with automatic fall back on different modes of communication.

[billie80]

I did some quick tests with panoramas.

Portrait example:
Original properties:
Resolution: 1168x7648
File size: 1926 KB
Orientation: 90°
Properties after sending with Signal:
Resolution: 195x29
File size: 2 KB
Orientation: 0°

Resolution and file size are way lower than the push constraints

Landscape example:
Original properties:
Resolution: 5904x480
File size: 572 KB
Orientation: 0°
Properties after sending with Signal:
Resolution: 1279x104
File size: 17 KB
Orientation: 0°

The resolution is slightly lower and the file size is way lower than the push constraints.

[UNIcodeX]

In a cursory look at the code last night, I'm not sure where it is determined that the picture actually NEEDS to be resized. I only saw references to a check on whether the image CAN be resized. But I didn't dig too terribly deep.

[haffenloher]

I opened two PRs trying to improve the situation within the current file size and memory restrictions: #5765 and #5772. Would be great if you could test these with different pictures in normal and low-mem configurations in order to determine
1) if the results are actually better
2) if the whole thing is still as robust as before, i.e. if it still manages to produce a result conforming to the restrictions every time, or if it has to give up on some images after 5 iterations.

[billie80]

@haffenloher thanks for working on this. Using pixel count is a great idea. This also means I got something right ;-)
I would gladly test this but this is only possible on a rooted phone if I am right. If this change would make it into a beta version I could apply for the beta channel to test your changes.
Is it also possible to increase the max. file size? However I guess this is up to @moxie. With this the initial compression value could probably be increased as well.

[UNIcodeX]

I've tried the latest beta and the picture quality is vastly improved. Excellent work!

May I ask, however , that the quality be increased to 2 or 3 Megapixels? Images sent via Textra over regular MMS are around 2 MP.

[Dyras]

@UNIcodeX It doesn't seem like the latest beta has anything affecting the picture quality though...

Personally I think the resolution should be increased to at least Full HD. Maybe even Quad HD to cover the high-end phones.

[billie80]

@UNIcodeX I think nothing has changed in the code which has to do with picture quality. Did you use the same pictures as input to test this?
A quick test with my two panoramas gave the same results with low resolution and quality.
@haffenloher just opened two pull requests. This does not mean it will get into Signal immediately, it first has to be accepted and then merged. To get it merged someone has to test the proposed changes and verify that they improve the situation.

[darmbrust]

Glad to see the resolution is improving, but what I'd really like to see (and what I had assumed this would do in the first place, since it sent over the data connection) is just give me an option to send the file exactly as it is. There is currently choices for Images, Audio, Video. Just give us an option for "Files". Add an option to the attachment area for "File". If we pick a picture via the file option, instead of the image option, we just send the image exactly as is with no processing / preview / etc. The bonus is it now works for any file type.... and I can finally send full resolution images without having to revert to e-mail or something like that. Probably should be written up as an enhancement request, if there is any chance something like this could be added.

Ideally, the send image option would just work like I had initially expected, and just send the images without mucking with them... but obviously that is complicated by all of the other things described above. Giving us the ability to push them through as files, however, bypasses a lot of those issues, and gives the user customizability over what is downloaded (and when) with the existing UI design.

[UNIcodeX]

@billie80 I am aware that it doesn't necessarily get pushed into the main branch immediately.... However, I am signed up for beta, and have tested with the exact same picture as was tested with before. This time yielded better image quality. I wouldn't report better quality unless I had actually tested it...

For your informational pleasure:
Before latest Beta update - 405x720 @ 0.292 MP

After latest Beta update - 720x1279 @ 0.920 MP

@darmbrust Excellent idea, which mirrors my own thoughts a bit. Improved resolution of in-line images as well as the option to send any file type. I could think of a few situations where someone may need to securely send documents, as well as full resolution images so as to capture every detail of the information being shared.

[billie80]

@UNIcodeX strange thing is that I am now registered for beta versions too. I did not receive an update so it seems latest beta is equal to latest official version. Using this version I don't see improvements for the pictures (panoramas) I tested.
The dimensions of your picture are just one pixel below the maximum allowed size of 1280 so maybe this is the result of random noise ;-)

[UNIcodeX]

@billie80 Negative, Ghost Rider; the original picture size is 5312x2988 @ 16MP

[haffenloher]

@UNIcodeX you maybe got a ROM update which changed ro.config.low_ram from true to false, so your phone no longer reports being a low-RAM device (giving you a max edge of 1280 instead of 768).
Whatever it is, there was no change in Signal.

[UNIcodeX]

I understand what you're saying. All I'm saying is that I was having the issue, I received an update for Signal beta, tested, quality was better.

I have received no known updates to my ROM. Nothing has advised me of an update, or even a compatability patch.

Maybe it's a fluke.. Just trying to help.

At any rate, I think we all agree that the image quality should be as high as possible and that an option should be added full for file transfer.

[UNIcodeX]

I just tested on another phone on my account. Same provider, same Model, same build, kernel numbers, etc.... The only difference is that this phone is not running the Signal beta. The image quality is still low, like the "Before latest Beta update" example above. 405x720 @ 0.292 MP

So, it seems something, somewhere, is different

[moxie0]

in 3.21.0

[ghost]

I get the 2048 limit but why we don't use a common size?

We used to 1280 that is realy nice on phones so why don't scale up to 1920?

High-definition television (HDTV):
HD (1280 × 720 progressive scan)
Full HD (1920 × 1080 progressive scan)
https://en.wikipedia.org/wiki/Display_resolution#Current_standards

[jeremymasters]

Because 2048 is higher resolution, resulting in pictures that are higher quality. Moxie is giving the best resolution possible. Not sure why you'd want to reduce that just to feel good about having a HD number. Many screens are higher resolution than 1920 now.

[ghost]

a standard is not an aesthetics thing or a feeling about numbers
i'd go with the common one since the other one is maked up and not usefull

• consistency with our first choice that was using a common phone resolution
• fit better in the world since a standard simplifies life
• no quality change on most screens
• no reason to use more space to store and transfer images if you don't get anything back

a random resolution is not bad itself but maybe a common one will work better

[Dyras]

I don't see what the big deal is. Most phones are low memory devices, so it's not like this change will actually start to matter until people start replacing their phones in 2-3 years. By that time higher resolutions will be more popular, which means 2048 instead of 1920 will actually make a difference.

Personally I wish the picture resolution was even higher, like Quad HD (2560x1440). However, there currently seems to be limitations in Android to prevent this. Is there a way around this? Probably, but I've never seen Signal as a WhatsApp competitor. I've always seen it as a testbed for the latest encryption technology, which is why we still don't have the new diversity emoji crap. I honestly wish they would add that so that my friends would stop bitching about it, but as long as I can send pictures of my cat to my mom without the pictures looking like crap, I'm happy. The larger the picture, the happier I get and since 2048 seems to be the maximum, I guess I'll have to settle for that.

[ghost]

_if using the standard is useless ignore my comments please_

speaking of quad hd while hd is not even there on common devices is a bit out of picture
if bigger is always better the same apply: go with nearest common size
i find that "bigger is always better" a bit missleading since we don't size the real world like that
it's about losing 6% of the new bigger picture in the far future to make sense in the close future
when that thing will happen we will need a lot more size to get the quality than 6%

_my points over. i stop to add noise_

[fractalf]

Thanks a lot to everyone involved in making this happen! 👍

[UNIcodeX]

looks like this issue is back again. I cleared out all running apps and took a picture and sent it through signal. The issue was fixed and pictures sent in this manner were at 2.4 MP, but now it's sending at 750 KP. What gives??

[carstn]

@UNIcodeX Diagnosing the issue will be most productive if you post

• the original size and compressed size (in megabytes or kilobytes)
• the width & height (in pixels) of the original and compressed images
• which device you're using (or at least how much memory your device has)

If possible, posting the actual files helps most. I'd suggest opening a new issue with this info.

[UNIcodeX]

@carstn looks like when using the camera icon in the text box, the resolution is capped at a little higher than 700 KP, but when you use a picture that was taken from another camera app, the resolution is better (2.4MP). Seems that the resolution is also better when using the paperclip icon to select an attachment type and then selecting camera.

[haffenloher]

@UNIcodeX if you're taking a landscape picture in portrait mode, you're only using a cropped portion of your camera's image. To use the full resolution, either expand the quick camera preview using the bottom right button or rotate your phone to landscape.

[FeuRenard]

https://github.com/WhisperSystems/Signal-Android/commit/d2be49af42eeebc888816904b1f765090be175ac brings further improvements, when you look at the file PushMediaConstraints.

private static final int MAX_IMAGE_DIMEN = 4096;

public int getImageMaxSize() { return 6 * MB; }

[moxie0]

Correct, the limits should now be such that images taken on the device using the camera app are not modified at all before transmission (no scaling, no compression). We have a subsampling image view so that when those images are viewed on lower end devices with a max texture size of 2048 or whatever, it's still rendered.

There might be a transition period where users running the new version of the app send images to users on old devices running an old version of the app, and they are too large to be viewed.

[jeremymasters]

Awesome-r.

[ka223]

@moxie0
But this is only by pictures taken with the build in signal camera?
I am using another camera app. :(

If we resize the images to 1000x750 with a jpeg quality "40", we have a much better quality by almost the same size (or lower).
For example the picture from zofrex.
https://www.dropbox.com/s/rt6jbzsb6wzbl54/60WWNVA_40.jpg?dl=0

[moxie0]

@ka223 the limits apply to all images, not just those taken within signal

[ka223]

@moxie0
hm, but the pictures I received over signal are not better.
They are more compressed and downscaled to 408x306 with ~31KB.
Original file 3264x2448 with 682KB !

If I look back to my chat history, pictures up to the 15.01.2017 are scaled with 576x768 size 71kb.

Something changed, but in the wrong direction. The pictures are sent from an android 4.1 device.

[UNIcodeX]

the pictures signal takes arent great quality compared to the default
camera app. i just use the default app and send that. they look much better
that way.

On Feb 2, 2017 5:45 PM, "Andre" [e-mail] wrote:

@moxie0 https://github.com/moxie0
hm, but the pictures I received over signal are not better.
They are more compressed and downscaled to 408x306 with ~31KB.

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

[ka223]

@moxie0
Can someone verify, that the pictures are currently so low by design?

Or is it a new bug to report?
For example the original picture and the arrived one:
https://www.dropbox.com/sh/ihl0xbc7qjiamn9/AAATpk5dlD3LcIKAsRVWwyUKa?dl=0

[Dyras]

@ka223 What device are you using since you're only on 4.1?

[moxie0]

@ka223 On devices that report themselves as "low memory" we still scale to a max edge of 768.

[ka223]

@Dyras: @moxie0 :
Thanks.
I am on CM13. The picture with 408x306 is send from an Alcatel 997d with Android 4.1.
Pictures in the log from last year are 768x576 ..., then it is a bug? :/

Pictures from another contact with an android 4.4 device are downscaled to 640x480, also not the "max edge of 768".

[moxie0]

@ka223 A debug log will show the memclass at the top. If it is indeed a low memclass device, then it's not a bug.

[Dyras]

@moxie0 @ka223 Alcatel 997d only has 1 gig RAM, which means this is not a bug
http://www.gsmarena.com/alcatel_ot_997d-5110.php

There's no way around this at the moment, at least not any obvious easy to implement way. I'd suggest you try to find someone on Reddit or something who is willing to find a way to compress/downsize a picture without making low memory devices crap themselves. There's an $87.76 bounty for pull requests so there's got to be someone out there willing to do it.

[ka223]

@Dyras @moxie0
Only ... 1GB is too low to send pictures downscaled to ~80kb?
Maybe I can compare this with a very low ram device. ;)

The CM 13 moto g2 device (memclass 96) has 1GB Ram and the send pictures are in the original size.

moto g2:
memclass 96
Ram 1GB
send pictures with 3264x2448 874kb (original size)

Alcatel 997d
memclass 64
Ram 1GB
send pictures with 408x306 ~31kb

Ace
memclass 32 (low-mem)
Ram 256 MB
send pictures with 640x480 ~71kb
receive pictures with 3264x2448

However this is calculated with the memclass, but both (g2 and the 997d) have 1gb ram and the 256mb ram device can send pictures in higher quality than the 1gb ram device, although the ace has a lower memclass.

[NeoFromMatrix]

I have a similar problem in #6262, 3264x2448px, 1.5MB to 408x306 px, 36.4KB

I'd prefer my images not being modified to the point where they are no longer usable.

[billie80]

You already have been told in #6262 that image compression depends on the memory class of your device. Unless you don't give this information (one of the first lines of the debug log will tell you) nobody will be able to help you. If you own a low memory device the maximum image width is 768 px. Maybe in your case when rescaling one step ended slightly above this value and with the next iteration it ended at 408 px.

[NeoFromMatrix]

Sorry for the inconvenience.
I'm a bit confused why this bug is closed, is there no other way to compress the images less on devices with lower memclass, or are you already hitting the border to being usable on those devices? Maybe introduce a finer granulation with memclasses, or increase the MAX_IMAGE_DIMEN_LOWMEM in the PushMediaConstraints file?
I'm sorry if this seems naive, I'm not an Android/Java developer and I don't have experience in this field. The way my data is handles in this case i just not usable for my daily use.

Sender:

Device  : samsung GT-I9300 (m0xx)
Android : 4.3 (I9300XXUGOL2, JSS15J.I9300XXUGOL2)
Memory  : 45M (35.55% free, 256M max)
Memclass: 64
OS Host : SWDB4709
App     : Signal 3.28.4

Recipient:

Device  : LGE Nexus 4 (occam)
Android : 6.0.1 (87a9c9942e, cm_mako-userdebug 6.0.1 MOB31K 87a9c9942e test-keys)
Memory  : 44M (34.38% free, 512M max)
Memclass: 192
OS Host : cyanogenmod
App     : Signal 3.29.6

[Dyras]

@NeoFromMatrix You are correct, what you are currently sending is the limit for low memory devices. Any higher and the app crashes during compression.

[dkasak]

Why does the Samsung GT-I9300 have such a low memory class, though? What is the 256M max referring to then?

[UNIcodeX]

Denis, are you able to send a higher quality photo with any other messaging
app, such as Facebook messenger or Textra?

On Feb 21, 2017 1:40 PM, "Denis Kasak" [e-mail] wrote:

Why does the Samsung GT-I9300 have such a low memory class, though? What
is the 256M max referring to then?

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

[dkasak]

@UNIcodeX I'm personally not affected since I don't own the phone in question, but the owner can indeed send much higher quality photos through WhatsApp at least.

[moxie0]

I'm willing to try eliminating the low memclass compression category

[UNIcodeX]

I wonder, then, how the other apps are handling low memory class devices.

Perhaps they aren't compressing at all, if compression is such an issue???

Or maybe they're compressing chunks of the file rather than loading it all into memory, and then appending to it.

read x bytes, compress, write x bytes, repeat until done... send.? I haven't looked at the code for how signal is doing this for a while, so maybe that's already being done.

[UNIcodeX]

@moxie0 , off topic, but... Is there anything in the works to allow straight file transfers as well? Maybe there's another issue open, i'll go look.

[ka223]

@billie80
I already told above.

A lower memclass device (Samsung Ace GT-S5830) is sending better images than a device with a higher memclass.
It can not only depend on the memclass.

[ghost]

I went looking for this issue because I noticed that even on my Moto X 2nd Gen, I'm sending pictures via the Signal protocol less than 100Kb in size. Given that RCS is about to become a thing with 10 Mb photo sending, Signal should at the very least compete with 1 Mb photo sending via the Signal protocol. Heck, even 300 Kb images would be an improvement.

We need to drop every factor leading to this overcompression and just have a simple hard limit of 1MB per picture.

[jeremymasters]

One of the things I wondered also was if Signal is using RGB_565 for just the thumbnail or using it in the conversion process. I'd submit we may want to go with ARGB_8888 instead, as the former produces banding in blue skies. Really, maybe we just shouldn't mess with a resize nor format change, at least for the actual photo.
@Cormak I wouldn't want a limit of 1MB per file. Not sure why you files are that small, but I like the current top-end where it is, 6MB.

[dkasak]

@moxie0 The current isLowMemory code also seems "wrong". Since Signal sets android:largeHeap, shouldn't it be checking against getLargeMemoryClass() instead? This might explain why some devices which can easily send higher resolution images over (e.g.) Whatsapp get a rather low memory class rating in Signal.

[neheb]

Recent Signal convert says images sent to other Signal users look fine but look terrible through MMS

[dkasak]

This is still a problem. Annoyingly, even the new file transfer functionality resizes images. I would do the change I proposed in my previous comment myself, but I don't have a convenient way of testing it since I don't have a spare phone. Is there a way to test the new build without unregistering/getting a new key?

EDIT: Actually, I think I'll try opening a new issue to get more traction.
EDIT (2017-08-12): My suggested change has been merged so this should work better. Waiting for the Play Store release to check.

[Sollybird]

The issue still persists, although images that I send are no longer compressed, and images received/sent between Signal users are fine. However, MMS messages that I receive are no longer legible in any sense of the word - they're just too compressed to read. I've tried other apps like Silence, and they don't appear to have this problem, but Signal is perfect for me in literally every other way.

[haffenloher]

@Sollybird MMS messages that you receive? Are you sure Signal is responsible for that? In any case, if you want the devs to investigate this, please open a new issue.

[Woodzrul]

Apologies for the noob question, but what is the answer to this (have read previous posts though got a little confused)? I own a high-end mobile phone so do I therefore need to amend some code to ensure when an MMS is sent that the quality is good? Thanks in advance.

[pkorba]

I can't complain about image quality of pictures sent as Signal messages over data - they look good. However, images sent over MMS are still overly compressed compared to stock SMS app. Here's my debug log:
https://debuglogs.org/a3d3d1b44425bfe13419e160045cd11a99d6d2363cb478af745a8f7ca24666e0

4608x3456 3,8MB image got compressed to 216x288 14,8 kB.

Another image:
original image size: 1920x2560 642,7 kB
sent using Signal over MMS: 240x320 23,8 kB
sent over MMS using stock SMS app: 1920x2560 286,3 kB
Carrier: Orange Polska

I have a friend who has the same complaint. His carrier is Play, P4.

[jschwender]

I can confirm that modifying image content is not a good idea: most of my contacts that i asked switching from whatapp to signal refused to use signal as soon as they noticed this specific behaviour. This is a blocker!