Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.software.thunderbird > #21667 > unrolled thread

Thunderbird 153.0.2 (64-bit) and large images

Back to article view | Back to alt.comp.software.thunderbird

Contents

  Thunderbird 153.0.2 (64-bit) and large images knuttle <keith_nuttle@yahoo.com> - 2026-08-05 13:07 -0400
    Re: Thunderbird 153.0.2 (64-bit) and large images Paul <nospam@needed.invalid> - 2026-08-05 14:28 -0400
    Re: Thunderbird 153.0.2 (64-bit) and large images Nobody <jock@soccer.com> - 2026-08-05 13:00 -0700
      Re: Thunderbird 153.0.2 (64-bit) and large images knuttle <keith_nuttle@yahoo.com> - 2026-08-05 17:57 -0400
        Re: Thunderbird 153.0.2 (64-bit) and large images Nobody <jock@soccer.com> - 2026-08-05 17:27 -0700
          Re: Thunderbird 153.0.2 (64-bit) and large images knuttle <keith_nuttle@yahoo.com> - 2026-08-05 21:55 -0400
            Re: Thunderbird 153.0.2 (64-bit) and large images dillinger <dillinger@not.invalid> - 2026-08-06 05:00 +0200
            Re: Thunderbird 153.0.2 (64-bit) and large images Paul <nospam@needed.invalid> - 2026-08-06 04:59 -0400
              Re: Thunderbird 153.0.2 (64-bit) and large images dillinger <dillinger@not.invalid> - 2026-08-06 13:58 +0200
    Re: Thunderbird 153.0.2 (64-bit) and large images "David E. Ross" <nobody@nowhere.invalid> - 2026-08-05 13:23 -0700
      Re: Thunderbird 153.0.2 (64-bit) and large images Jack <invalid@invalid.invalid> - 2026-08-05 23:15 +0100
        Re: Thunderbird 153.0.2 (64-bit) and large images "Alan K." <alan@invalid.com> - 2026-08-05 18:26 -0400
          Re: Thunderbird 153.0.2 (64-bit) and large images Paul <nospam@needed.invalid> - 2026-08-06 05:58 -0400
            Re: Thunderbird 153.0.2 (64-bit) and large images knuttle <keith_nuttle@yahoo.com> - 2026-08-06 07:11 -0400
              Re: Thunderbird 153.0.2 (64-bit) and large images Paul <nospam@needed.invalid> - 2026-08-06 14:46 -0400
            Re: Thunderbird 153.0.2 (64-bit) and large images "J. P. Gilliver" <G6JPG@255soft.uk> - 2026-08-06 13:16 +0100
              Re: Thunderbird 153.0.2 (64-bit) and large images knuttle <keith_nuttle@yahoo.com> - 2026-08-06 16:20 -0400
                Re: Thunderbird 153.0.2 (64-bit) and large images Paul <nospam@needed.invalid> - 2026-08-06 18:35 -0400
                  Re: Thunderbird 153.0.2 (64-bit) and large images "J. P. Gilliver" <G6JPG@255soft.uk> - 2026-08-07 02:36 +0100
    Re: Thunderbird 153.0.2 (64-bit) and large images dillinger <dillinger@not.invalid> - 2026-08-05 22:34 +0200

#21667 — Thunderbird 153.0.2 (64-bit) and large images

Ever since I updated to 153.0.2 (64-bit) I have been having trouble 
sending images that I routinely sent in the past.

When I send a 1MB file 1760 x 2644 image, the file is cut off and only 
part of the image shows.  (full picture frame only there is no image on 
the lower part)

What is interesting is that when I send the same image from Yahoo.com 
from the browser window that same file comes through correctly.

While I have used an image-resizer in the past and it was active when 
the problem occurred, it was still present with that addon was deactivated.

Any suggestions?

[toc] | [next] | [standalone]

#21668

On Wed, 8/5/2026 1:07 PM, knuttle wrote:
> Ever since I updated to 153.0.2 (64-bit) I have been having trouble sending images that I routinely sent in the past.
> 
> When I send a 1MB file 1760 x 2644 image, the file is cut off and only part of the image shows.  (full picture frame only there is no image on the lower part)
> 
> What is interesting is that when I send the same image from Yahoo.com from the browser window that same file comes through correctly.
> 
> While I have used an image-resizer in the past and it was active when the problem occurred, it was still present with that addon was deactivated.
> 
> Any suggestions?

mail.compose.big_attachment.notify         true
mail.compose.big_attachment.threshold_kb   5120

( My server has a 20MB max message size limit... )

Using TB 153.0.2 (notESR) and attaching a 2.7MB JPG,
no anomalies were noted.

Using an even larger picture (11MB), when the content in the
message exceeded the mailserver max size of 20MB, the
inline picture appeared as a blank, and the message did not
seem to save as a draft. Removing half of the burdensome
media content, and ducking under the limit, allowed
the message to be saved/sent, and the large inline picture
could be viewed in the Inbox OK.

Nothing "edited" the picture in my case.

   Paul

[toc] | [prev] | [next] | [standalone]

#21669

On Wed, 5 Aug 2026 13:07:34 -0400, knuttle <keith_nuttle@yahoo.com>
wrote:

>Ever since I updated to 153.0.2 (64-bit) I have been having trouble 
>sending images that I routinely sent in the past.
>
>When I send a 1MB file 1760 x 2644 image, the file is cut off and only 
>part of the image shows.  (full picture frame only there is no image on 
>the lower part)
>
>What is interesting is that when I send the same image from Yahoo.com 
>from the browser window that same file comes through correctly.
>
>While I have used an image-resizer in the past and it was active when 
>the problem occurred, it was still present with that addon was deactivated.
>
>Any suggestions?

TB 153.0.2 with settings the same as Paul previously posted, a 2.3MB
.jpg arrived as sent.

Tested both as plain text w/attachment... and .html as an insert
(though I doubt that would've made any difference).  And Attachment
Displayed Inline for viewing.

[toc] | [prev] | [next] | [standalone]

#21672

On 08/05/2026 4:00 PM, Nobody wrote:
> On Wed, 5 Aug 2026 13:07:34 -0400, knuttle <keith_nuttle@yahoo.com>
> wrote:
> 
>> Ever since I updated to 153.0.2 (64-bit) I have been having trouble
>> sending images that I routinely sent in the past.
>>
>> When I send a 1MB file 1760 x 2644 image, the file is cut off and only
>> part of the image shows.  (full picture frame only there is no image on
>> the lower part)
>>
>> What is interesting is that when I send the same image from Yahoo.com
>>from the browser window that same file comes through correctly.
>>
>> While I have used an image-resizer in the past and it was active when
>> the problem occurred, it was still present with that addon was deactivated.
>>
>> Any suggestions?
> 
> TB 153.0.2 with settings the same as Paul previously posted, a 2.3MB
> .jpg arrived as sent.
> 
> Tested both as plain text w/attachment... and .html as an insert
> (though I doubt that would've made any difference).  And Attachment
> Displayed Inline for viewing.
> 
> 
I check the setting as suggested and changed them as Paul showed them. 
There was one exception.  On the second parameter rather than being able 
  to set a number, it went to True.

I have successfully sent the picture that I was having problems with but 
   will keep and eye on it. I also pdf Paul's message and will make the 
change on my other computer.

Thanks for the help

[toc] | [prev] | [next] | [standalone]

#21677

On Wed, 5 Aug 2026 17:57:10 -0400, knuttle <keith_nuttle@yahoo.com>
wrote:

>On 08/05/2026 4:00 PM, Nobody wrote:
>> On Wed, 5 Aug 2026 13:07:34 -0400, knuttle <keith_nuttle@yahoo.com>
>> wrote:
>> 
>>> Ever since I updated to 153.0.2 (64-bit) I have been having trouble
>>> sending images that I routinely sent in the past.
>>>
>>> When I send a 1MB file 1760 x 2644 image, the file is cut off and only
>>> part of the image shows.  (full picture frame only there is no image on
>>> the lower part)
>>>
>>> What is interesting is that when I send the same image from Yahoo.com
>>>from the browser window that same file comes through correctly.
>>>
>>> While I have used an image-resizer in the past and it was active when
>>> the problem occurred, it was still present with that addon was deactivated.
>>>
>>> Any suggestions?
>> 
>> TB 153.0.2 with settings the same as Paul previously posted, a 2.3MB
>> .jpg arrived as sent.
>> 
>> Tested both as plain text w/attachment... and .html as an insert
>> (though I doubt that would've made any difference).  And Attachment
>> Displayed Inline for viewing.
>> 
>> 
>I check the setting as suggested and changed them as Paul showed them. 
>There was one exception.  On the second parameter rather than being able 
>  to set a number, it went to True.
>
Really?  But the 'threshold_kb' entry requires a value, not 'true' or
'false', which should be user variable.

[toc] | [prev] | [next] | [standalone]

#21679

On 08/05/2026 8:27 PM, Nobody wrote:
> On Wed, 5 Aug 2026 17:57:10 -0400, knuttle <keith_nuttle@yahoo.com>
> wrote:
> 
>> On 08/05/2026 4:00 PM, Nobody wrote:
>>> On Wed, 5 Aug 2026 13:07:34 -0400, knuttle <keith_nuttle@yahoo.com>
>>> wrote:
>>>
>>>> Ever since I updated to 153.0.2 (64-bit) I have been having trouble
>>>> sending images that I routinely sent in the past.
>>>>
>>>> When I send a 1MB file 1760 x 2644 image, the file is cut off and only
>>>> part of the image shows.  (full picture frame only there is no image on
>>>> the lower part)
>>>>
>>>> What is interesting is that when I send the same image from Yahoo.com
>>> >from the browser window that same file comes through correctly.
>>>>
>>>> While I have used an image-resizer in the past and it was active when
>>>> the problem occurred, it was still present with that addon was deactivated.
>>>>
>>>> Any suggestions?
>>>
>>> TB 153.0.2 with settings the same as Paul previously posted, a 2.3MB
>>> .jpg arrived as sent.
>>>
>>> Tested both as plain text w/attachment... and .html as an insert
>>> (though I doubt that would've made any difference).  And Attachment
>>> Displayed Inline for viewing.
>>>
>>>
>> I check the setting as suggested and changed them as Paul showed them.
>> There was one exception.  On the second parameter rather than being able
>>   to set a number, it went to True.
>>
> Really?  But the 'threshold_kb' entry requires a value, not 'true' or
> 'false', which should be user variable.
I accessed the config file and copied and then pastedd that line from 
his message in Search.   It found the line but offer three options.  The 
one I selected gave me the False variable and when I clicked it it 
turned to True.   When I read your message I went back and did the same 
thing this time it brought up that variable with:

mail.compose.big_attachment.threshold_kb 5120

I poked around and there are two parameters for: 
mail.compose.big_attachment.threshold_kb

One is marked True and the other 5120

[toc] | [prev] | [next] | [standalone]

#21680

On 06/08/2026 03:55, knuttle wrote:
> On 08/05/2026 8:27 PM, Nobody wrote:
>> On Wed, 5 Aug 2026 17:57:10 -0400, knuttle <keith_nuttle@yahoo.com>
>> wrote:
>>
>>> On 08/05/2026 4:00 PM, Nobody wrote:
>>>> On Wed, 5 Aug 2026 13:07:34 -0400, knuttle <keith_nuttle@yahoo.com>
>>>> wrote:
>>>>
>>>>> Ever since I updated to 153.0.2 (64-bit) I have been having trouble
>>>>> sending images that I routinely sent in the past.
>>>>>
>>>>> When I send a 1MB file 1760 x 2644 image, the file is cut off and only
>>>>> part of the image shows.  (full picture frame only there is no 
>>>>> image on
>>>>> the lower part)
>>>>>
>>>>> What is interesting is that when I send the same image from Yahoo.com
>>>> >from the browser window that same file comes through correctly.
>>>>>
>>>>> While I have used an image-resizer in the past and it was active when
>>>>> the problem occurred, it was still present with that addon was 
>>>>> deactivated.
>>>>>
>>>>> Any suggestions?
>>>>
>>>> TB 153.0.2 with settings the same as Paul previously posted, a 2.3MB
>>>> .jpg arrived as sent.
>>>>
>>>> Tested both as plain text w/attachment... and .html as an insert
>>>> (though I doubt that would've made any difference).  And Attachment
>>>> Displayed Inline for viewing.
>>>>
>>>>
>>> I check the setting as suggested and changed them as Paul showed them.
>>> There was one exception.  On the second parameter rather than being able
>>>   to set a number, it went to True.
>>>
>> Really?  But the 'threshold_kb' entry requires a value, not 'true' or
>> 'false', which should be user variable.
> I accessed the config file and copied and then pastedd that line from 
> his message in Search.   It found the line but offer three options.  The 
> one I selected gave me the False variable and when I clicked it it 
> turned to True.   When I read your message I went back and did the same 
> thing this time it brought up that variable with:
> 
> mail.compose.big_attachment.threshold_kb 5120
> 
> I poked around and there are two parameters for: 
> mail.compose.big_attachment.threshold_kb
> 
> One is marked True and the other 5120
There are 3 "big_attachment" prefs, you've likely now set them all to 
defaults.

But all three are for the "Filelink" function; they do not delete parts 
of your attached images.

https://searchfox.org/comm-central/search?q=big_attachment

So, you've also changed something else, the question then remains: what?

[toc] | [prev] | [next] | [standalone]

#21685

On Wed, 8/5/2026 9:55 PM, knuttle wrote:
> On 08/05/2026 8:27 PM, Nobody wrote:
>> On Wed, 5 Aug 2026 17:57:10 -0400, knuttle <keith_nuttle@yahoo.com>
>> wrote:
>>
>>> On 08/05/2026 4:00 PM, Nobody wrote:
>>>> On Wed, 5 Aug 2026 13:07:34 -0400, knuttle <keith_nuttle@yahoo.com>
>>>> wrote:
>>>>
>>>>> Ever since I updated to 153.0.2 (64-bit) I have been having trouble
>>>>> sending images that I routinely sent in the past.
>>>>>
>>>>> When I send a 1MB file 1760 x 2644 image, the file is cut off and only
>>>>> part of the image shows.  (full picture frame only there is no image on
>>>>> the lower part)
>>>>>
>>>>> What is interesting is that when I send the same image from Yahoo.com
>>>> >from the browser window that same file comes through correctly.
>>>>>
>>>>> While I have used an image-resizer in the past and it was active when
>>>>> the problem occurred, it was still present with that addon was deactivated.
>>>>>
>>>>> Any suggestions?
>>>>
>>>> TB 153.0.2 with settings the same as Paul previously posted, a 2.3MB
>>>> .jpg arrived as sent.
>>>>
>>>> Tested both as plain text w/attachment... and .html as an insert
>>>> (though I doubt that would've made any difference).  And Attachment
>>>> Displayed Inline for viewing.
>>>>
>>>>
>>> I check the setting as suggested and changed them as Paul showed them.
>>> There was one exception.  On the second parameter rather than being able
>>>   to set a number, it went to True.
>>>
>> Really?  But the 'threshold_kb' entry requires a value, not 'true' or
>> 'false', which should be user variable.
> I accessed the config file and copied and then pastedd that line from his message in Search.   It found the line but offer three options.  The one I selected gave me the False variable and when I clicked it it turned to True.   When I read your message I went back and did the same thing this time it brought up that variable with:
> 
> mail.compose.big_attachment.threshold_kb 5120
> 
> I poked around and there are two parameters for: mail.compose.big_attachment.threshold_kb
> 
> One is marked True and the other 5120

I was looking for anything associated with attachments.

And those are associated with a warning dialog, rather
than an actual function (such as editing the thing).

The settings are highlighted in bold, if you take them
off their default value. If they aren't highlighted,
then the settings are at their default value.

   Paul

[toc] | [prev] | [next] | [standalone]

#21688

Op 6-8-2026 om 10:59 schreef Paul:
> On Wed, 8/5/2026 9:55 PM, knuttle wrote:
>> On 08/05/2026 8:27 PM, Nobody wrote:
>>> On Wed, 5 Aug 2026 17:57:10 -0400, knuttle <keith_nuttle@yahoo.com>
>>> wrote:
>>>
>>>> On 08/05/2026 4:00 PM, Nobody wrote:
>>>>> On Wed, 5 Aug 2026 13:07:34 -0400, knuttle <keith_nuttle@yahoo.com>
>>>>> wrote:
>>>>>
>>>>>> Ever since I updated to 153.0.2 (64-bit) I have been having trouble
>>>>>> sending images that I routinely sent in the past.
>>>>>>
>>>>>> When I send a 1MB file 1760 x 2644 image, the file is cut off and only
>>>>>> part of the image shows.  (full picture frame only there is no image on
>>>>>> the lower part)
>>>>>>
>>>>>> What is interesting is that when I send the same image from Yahoo.com
>>>>> >from the browser window that same file comes through correctly.
>>>>>>
>>>>>> While I have used an image-resizer in the past and it was active when
>>>>>> the problem occurred, it was still present with that addon was deactivated.
>>>>>>
>>>>>> Any suggestions?
>>>>>
>>>>> TB 153.0.2 with settings the same as Paul previously posted, a 2.3MB
>>>>> .jpg arrived as sent.
>>>>>
>>>>> Tested both as plain text w/attachment... and .html as an insert
>>>>> (though I doubt that would've made any difference).  And Attachment
>>>>> Displayed Inline for viewing.
>>>>>
>>>>>
>>>> I check the setting as suggested and changed them as Paul showed them.
>>>> There was one exception.  On the second parameter rather than being able
>>>>    to set a number, it went to True.
>>>>
>>> Really?  But the 'threshold_kb' entry requires a value, not 'true' or
>>> 'false', which should be user variable.
>> I accessed the config file and copied and then pastedd that line from his message in Search.   It found the line but offer three options.  The one I selected gave me the False variable and when I clicked it it turned to True.   When I read your message I went back and did the same thing this time it brought up that variable with:
>>
>> mail.compose.big_attachment.threshold_kb 5120
>>
>> I poked around and there are two parameters for: mail.compose.big_attachment.threshold_kb
>>
>> One is marked True and the other 5120
> 
> I was looking for anything associated with attachments.
> 
> And those are associated with a warning dialog, rather
> than an actual function (such as editing the thing).
> 
> The settings are highlighted in bold, if you take them
> off their default value. If they aren't highlighted,
> then the settings are at their default value.
> 
>     Paul

But these prefs have little or nothing to do with the problem at hand.

Actually the OP may just have been (un)lucky, try this in Google:
https://www.google.com/search?q=thunderbird+partially+rendered+images

> Partial image rendering in Thunderbird—where an image loads halfway, shows gray blocks, or displays split/corrupted files—is usually caused by incomplete IMAP message downloads, a bloated local cache, or slow inline rendering of large files.

Plus some suggestions for fixes and troubleshooting.

[toc] | [prev] | [next] | [standalone]

#21670

On 8/5/2026 10:07 AM, knuttle wrote:
> Ever since I updated to 153.0.2 (64-bit) I have been having trouble 
> sending images that I routinely sent in the past.
> 
> When I send a 1MB file 1760 x 2644 image, the file is cut off and only 
> part of the image shows.  (full picture frame only there is no image on 
> the lower part)
> 
> What is interesting is that when I send the same image from Yahoo.com 
> from the browser window that same file comes through correctly.
> 
> While I have used an image-resizer in the past and it was active when 
> the problem occurred, it was still present with that addon was deactivated.
> 
> Any suggestions?
> 

I upload large files (including images) to the test folder on my Web
site.  I then send a brief message with a link to a recipient along with
a request to let me know when the recipient has downloaded it.  I then
delete it from my Web site.

-- 

David E. Ross
<http://www.rossde.com>

NO, not everyone has a smart phone.  My wife and I have
"dumb cell phones" and a land-line.  Neither of us can
handle QR codes, reply to text messages, or have any
kind of phone-based Internet connections.  We have no APS
on any phone.  We can send and receive photos only
through our desktop PCs.

[toc] | [prev] | [next] | [standalone]

#21673

On 05/08/2026 21:23, David E. Ross wrote:
> I upload large files (including images) to the test folder on my Web
> site.  I then send a brief message with a link to a recipient along with
> a request to let me know when the recipient has downloaded it.  I then
> delete it from my Web site.


I agree. There's no point sending large files by email. Not only do they 
use up internet bandwidth, they also increase the size of the inboxes of 
both the sender and the recipient. While these files can be deleted, 
it's better to avoid the hassle of deleting them and losing track of 
what was sent and when by doing things properly in the first place.

[toc] | [prev] | [next] | [standalone]

#21674

On 8/5/26 6:15 PM, Jack wrote:
> On 05/08/2026 21:23, David E. Ross wrote:
>> I upload large files (including images) to the test folder on my Web
>> site.  I then send a brief message with a link to a recipient along with
>> a request to let me know when the recipient has downloaded it.  I then
>> delete it from my Web site.
> 
> 
> I agree. There's no point sending large files by email. Not only do they
> use up internet bandwidth, they also increase the size of the inboxes of
> both the sender and the recipient. While these files can be deleted,
> it's better to avoid the hassle of deleting them and losing track of
> what was sent and when by doing things properly in the first place.
> 
> 
And how many people track stuff like that and then years later why google or yahoo are 
telling them their storage allotment has been hit.

-- 
Mint 22.3,  Thunderbird 153.0esr,  Firefox 153.0.1
     Alan K.

[toc] | [prev] | [next] | [standalone]

#21686

On Wed, 8/5/2026 6:26 PM, Alan K. wrote:
> On 8/5/26 6:15 PM, Jack wrote:
>> On 05/08/2026 21:23, David E. Ross wrote:
>>> I upload large files (including images) to the test folder on my Web
>>> site.  I then send a brief message with a link to a recipient along with
>>> a request to let me know when the recipient has downloaded it.  I then
>>> delete it from my Web site.
>>
>>
>> I agree. There's no point sending large files by email. Not only do they
>> use up internet bandwidth, they also increase the size of the inboxes of
>> both the sender and the recipient. While these files can be deleted,
>> it's better to avoid the hassle of deleting them and losing track of
>> what was sent and when by doing things properly in the first place.
>>
>>
> And how many people track stuff like that and then years later why google 
> or yahoo are telling them their storage allotment has been hit.

If your email does not stay on the server, the
situation isn't as dire.

The max message size on an email server, allows
a decent-sized photo to be sent. 20MB * 3/4 = 15MB image,
which could be 9000x6000. There's probably some
sensor on your phone that can make one of those.

And then you only have to clean up your main drive,
when it gets full.

   Paul

[toc] | [prev] | [next] | [standalone]

#21687

On 08/06/2026 5:58 AM, Paul wrote:
>   There's probably some
> sensor on your phone that can make one of those
These problems all involved computer to computer transfers by email. 
There were no phones involved.

[toc] | [prev] | [next] | [standalone]

#21695

On Thu, 8/6/2026 7:11 AM, knuttle wrote:
> On 08/06/2026 5:58 AM, Paul wrote:
>>   There's probably some
>> sensor on your phone that can make one of those
> These problems all involved computer to computer transfers by email. There were no phones involved.

Today, for many people, the phone is their digital camera.

The disposal of the images, they can end up anywhere after
that, including transferred to a desktop for storage. I can make
cheaper storage on a desktop, than on a phone, comparatively
speaking.

My point-and-shoot digital camera, is 12 MPixel. SmartPhones
easily outclass the thing. Since I don't own a SmartPhone,
my digital camera is all I've got.

   Paul

[toc] | [prev] | [next] | [standalone]

#21690

On 2026/8/6 10:58:50, Paul wrote:
> On Wed, 8/5/2026 6:26 PM, Alan K. wrote:
>> On 8/5/26 6:15 PM, Jack wrote:
>>> On 05/08/2026 21:23, David E. Ross wrote:
>>>> I upload large files (including images) to the test folder on my Web
>>>> site.  I then send a brief message with a link to a recipient along with
>>>> a request to let me know when the recipient has downloaded it.  I then
>>>> delete it from my Web site.
>>>
Same here (except my folder is called !temp, and I tend _not_ to delete
- I use far less than my allocated. I do if I remember). I certainly
don't inflict any of the common file-sharing sites on my recipients -
lots of scripts, ad.s, or "not available in your area".>>>
>>> I agree. There's no point sending large files by email. Not only do they
>>> use up internet bandwidth, they also increase the size of the inboxes of
>>> both the sender and the recipient. While these files can be deleted,
>>> it's better to avoid the hassle of deleting them and losing track of
>>> what was sent and when by doing things properly in the first place.
>>>
I _sometimes_ do - and I don't know about the recipients, but I wouldn't
keep any important attachment in an email anyway: one too many layers of
wrapping. If something is important, I'll save it as a file outside the
email client.>>>
>> And how many people track stuff like that and then years later why google 
>> or yahoo are telling them their storage allotment has been hit.
> 
> If your email does not stay on the server, the
> situation isn't as dire.

Mine doesn't.>
> The max message size on an email server, allows
> a decent-sized photo to be sent. 20MB * 3/4 = 15MB image,
> which could be 9000x6000. There's probably some
> sensor on your phone that can make one of those.

54 megapixels, really? I knew 'phone cameras were getting ridiculous,
but even so ... :-)>
> And then you only have to clean up your main drive,
> when it gets full.

Indeed.>
>    Paul
-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

Abandon hope, all ye who <ENTER> here.

[toc] | [prev] | [next] | [standalone]

#21697

On 08/06/2026 8:16 AM, J. P. Gilliver wrote:
> 54 megapixels, really? I knew 'phone cameras were getting ridiculous,
> but even so ... 🙂>

I was always amused by this.  I have friends who do not have a computer 
and only view their pictures on the cellphone screen.  Then they make 
sure you are aware on their phone with the best camera available.....to 
provide picture for the 3" screen on their cellphones.

[toc] | [prev] | [next] | [standalone]

#21698

On Thu, 8/6/2026 4:20 PM, knuttle wrote:
> On 08/06/2026 8:16 AM, J. P. Gilliver wrote:
>> 54 megapixels, really? I knew 'phone cameras were getting ridiculous,
>> but even so ... 🙂>
> 
> I was always amused by this.  I have friends who do not have a computer and only view their pictures on the cellphone screen.  Then they make sure you are aware on their phone with the best camera available.....to provide picture for the 3" screen on their cellphones.

Well, think of the digital zoom you can do.
Maybe not.

https://www.reddit.com/r/Cameras/comments/1fkl654/how_phone_cameras_pack_100mp_in_such_ridiculously/

   Paul

[toc] | [prev] | [next] | [standalone]

#21701

On 2026/8/6 23:35:22, Paul wrote:
> On Thu, 8/6/2026 4:20 PM, knuttle wrote:
>> On 08/06/2026 8:16 AM, J. P. Gilliver wrote:
>>> 54 megapixels, really? I knew 'phone cameras were getting ridiculous,
>>> but even so ... 🙂>
>>
>> I was always amused by this.  I have friends who do not have a computer and only view their pictures on the cellphone screen.  Then they make sure you are aware on their phone with the best camera available.....to provide picture for the 3" screen on their cellphones.
> 
> Well, think of the digital zoom you can do.
> Maybe not.
> 
> https://www.reddit.com/r/Cameras/comments/1fkl654/how_phone_cameras_pack_100mp_in_such_ridiculously/
> 
>    Paul

Then there was that one a few years ago that were caught out "improving"
your pictures - if it detected you were photographing the moon, it
substituted an excellent picture of the moon. IIRR, it was caught out by
not inverting it if it was a reflection in a lake, or something like that.
-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

[toc] | [prev] | [next] | [standalone]

#21671

Op 5-8-2026 om 19:07 schreef knuttle:
> Ever since I updated to 153.0.2 (64-bit) I have been having trouble 
> sending images that I routinely sent in the past.
> 
> When I send a 1MB file 1760 x 2644 image, the file is cut off and only 
> part of the image shows.  (full picture frame only there is no image on 
> the lower part)
> 
> What is interesting is that when I send the same image from Yahoo.com 
> from the browser window that same file comes through correctly.
> 
> While I have used an image-resizer in the past and it was active when 
> the problem occurred, it was still present with that addon was deactivated.
> 
> Any suggestions?
What image-resizer did you use?

Not all add-ons remove everything they changed in Thunderbird when you 
disable or even remove them.

You can try to clear the startup cache and check if it works after that:
Help > Troubleshooting Information > Clear startup cache... > Restart

FWIW, Thunderbird automatically resizes images in displayed messages. 
Resizing images is only useful when you want to save bandwidth and/or 
disk space.

[toc] | [prev] | [standalone]

Back to top | Article view | alt.comp.software.thunderbird

csiph-web