moderated JPEG image file size mismatch in emails and online #misc


 

Hi Mark,

I don't know if this is by design or a bug.

This happens only for included JPEGs (either embedded or attached) in either emailed or online messages, not in Files or Photos.  It doesn't do it for BMP, PNG, TIFF or PDF but it does for JPEG, the file gets somehow either resampled or compressed more from the original sent-in, resulting in a smaller file size, and which is what gets saved on AWS, so when viewed online it downloads the compressed version, not the original sent in.  Similarly it is also emailed out as the compressed one, not the original sent in.  The physical original JPEG as sent-in is not stored anywhere from what I can tell.

If only compressed, it looks like it's getting compressed in the 12%-15% range.  Here's one example, in my recent thread with an attached JPEG (I use 5% compression), the 401 KB as sent-in attached (not the embedded) JPEG was saved with the higher compression so it was reduced to 258 KB and stored & emailed-out as such.  On a separate test where I embedded the same 401 KB JPEG it also stored online and went out compressed except it was 262 KB.

So I'm curious is it supposed to happen like this, i.e. one doesn't receive the same exact physical file as was mailed-in if a JPEG but they do if some other format.

Could that be a potential problem in some way?  I can sort-of see that one cannot use JPEGs in messages if the group users depend on mailing & receiving archival quality JPEGs, they'll have to use some other format.

Cheers,
Christos


 

On Wed, Jul 6, 2022 at 1:47 PM Christos Psarras <christos@...> wrote:

I don't know if this is by design or a bug.

This happens only for included JPEGs (either embedded or attached) in either emailed or online messages, not in Files or Photos.  It doesn't do it for BMP, PNG, TIFF or PDF but it does for JPEG, the file gets somehow either resampled or compressed more from the original sent-in, resulting in a smaller file size, and which is what gets saved on AWS, so when viewed online it downloads the compressed version, not the original sent in.  Similarly it is also emailed out as the compressed one, not the original sent in.  The physical original JPEG as sent-in is not stored anywhere from what I can tell.

Assuming the `Max Photo Size in Email` setting is set to `No resizing`... We downsample images if they are greater than 10,000 pixels on a side, to prevent us killing people's inboxes with massive emails. Also, regardless of the group setting, we resize inline images to a max of 640x640. Could that be what you're seeing?

Thanks,
Mark 


 

On Wed, Jul 6, 2022 at 05:29 PM, Mark Fletcher wrote:
Assuming the `Max Photo Size in Email` setting is set to `No resizing`... We downsample images if they are greater than 10,000 pixels on a side, to prevent us killing people's inboxes with massive emails. Also, regardless of the group setting, we resize inline images to a max of 640x640. Could that be what you're seeing?
No, neither of those exceptions, and group & sub setting is No resizing.  It's just any regular run of the mill JPEG.

I just did some testing and here, I'll show you in this reply, done online. (the results are the same if done through email)

My control set is a 1276 x 1024 JPEG, and a 640 x 514 version of it, 498 and 194 KB respectively per Windows:



I click on Attach and drag-drop those two files and the file info presented by the uploader code agrees with Windows on those file sizes:




But after clicking Add, something happens because by the time the NewTopic screen refreshes and the attachments are displayed, i.e. stored on AWS, the file sizes have shrunk:




These down-filesized versions are also what gets emailed out, not the original file sizes (i.e. the physical original files).  If you download either one of the two attached files on this message online or save the same two files from the email, the big one will save (per Windows) at 337 KB and the small at 160 KB, i.e. what got stored on AWS.  The dimensions stay the same, is just the file size that decreases which leads me to believe they are saved with a higher compression.

Here I'll also embed the 640x514 version.  In the Insert Image dialog, the file size shown agrees with me, 194 KB



>>>

<<<

But after this message posts, if you right-click and save this embedded image above (online or email) it will also save as the shrunk 160 KB version, not the original.

Cheers,
Christos


 

Make that 337 or 339 KB, and 160 KB.

On 2022-07-06 19:59, Christos Psarras via groups.io wrote:
the big one will save (per Windows) at 337 KB and the small at 160 KB


 

Refreshing my memory with the code, we always want to orient the image upright, if it is not already. To do that, we run it through a converter, which I suppose could re-compress it. But if the image is already upright, that shouldn't trigger and we shouldn't touch the image at all. Can you directly email me the image? I'll check to see what orientation the code thinks the image is in.

Thanks,
Mark


Bruce Bowman
 

JPEG images in digests are changed to a quality factor of 75. Ref: https://beta.groups.io/g/main/message/25250

I think that's only if they're being resized, though.

Could that be it?

Bruce

P.S. Love the Salvador Dali.


 


Refreshing my memory with the code, we always want to orient the image upright, if it is not already. To do that, we run it through a converter, which I suppose could re-compress it. But if the image is already upright, that shouldn't trigger and we shouldn't touch the image at all. Can you directly email me the image? I'll check to see what orientation the code thinks the image is in.

Ahh, it may be that then, the converter is re-saving the file regardless using its default JPEG compression of around 15% compression.  I just did another test which points to something doing that.  This time I did the opposite, I took the above big file which is at 5% compression and its filesize gets shrunk down, changed it to 30% compression factor which resulted in a smaller original file size, and attached it, and this time the stored filesize increased, consistent with the high compression file being re-saved using smaller compression:




I'll email the test files directly.

Cheers,
Christos


 

Hi All,

I've fixed the bug and images that don't need to be processed should no longer be re-compressed. Also, I changed the Attachments: display in the New Post and Reply pages so that it shows file sizes in kB.

There's still a discrepancy between the file size displayed in the upload window and the actual file size, but we are definitely saving the original file.

Thanks,
Mark


 

Thanks!

>>> There's still a discrepancy between the file size displayed in the upload window and the actual file size...

That should be easy to fix, if the Attachments: display original value in bytes gets divided by 1024 instead of 1000, and additionally formatted/displayed with two decimal points, it'll show the same value as in the upload window.

Cheers,
Christos





 


On 2022-07-06 21:37, Bruce Bowman via groups.io wrote:
P.S. Love the Salvador Dali.


Thanks, yes, I do too, but I should rethink my strategy, was hoping it would result in more Likes on my post but so far it has gathered only one Like!