You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
it may happen, that an incoming image is huge in pixelsize (not necessary in bytesize).
eg. recently a 20000 x 10000 pixel image was sent accidentally to a community chat. for comparison: this image has 200+ times more pixels than an image usually sent with deltachat
depending on the used operating system, such huge images may need more than 1 gigabyte of ram to be displayed, this takes a looooong time, if it succeeds at all - the app may just crash because of exhaustive memory usage.
possible fixes:
there are ways to process images with less memory, eg. https://github.com/libvips/libvips - but that is a huge C dependency, with many sub-dependencies. that will introduce other issues. also, we're talking about a cornercase here.
peek at the image size, and mark incoming messages with huge images as "file", and not as "image". the user can still "save as" the file or open it with an external viewer
i think, 1 is not reasonable, while 2. seems to be an easy fix.
in general, we should consider to not create "image messages" in case we cannot find out the image size (eg. for exotic formats the system may try to display - that may result in the same issue, incl crashes)
moreover, it'd be fine to not allow send such huge images, but that can be another issue then
it may happen, that an incoming image is huge in pixelsize (not necessary in bytesize).
eg. recently a 20000 x 10000 pixel image was sent accidentally to a community chat. for comparison: this image has 200+ times more pixels than an image usually sent with deltachat
depending on the used operating system, such huge images may need more than 1 gigabyte of ram to be displayed, this takes a looooong time, if it succeeds at all - the app may just crash because of exhaustive memory usage.
possible fixes:
there are ways to process images with less memory, eg. https://github.com/libvips/libvips - but that is a huge C dependency, with many sub-dependencies. that will introduce other issues. also, we're talking about a cornercase here.
peek at the image size, and mark incoming messages with huge images as "file", and not as "image". the user can still "save as" the file or open it with an external viewer
i think, 1 is not reasonable, while 2. seems to be an easy fix.
in general, we should consider to not create "image messages" in case we cannot find out the image size (eg. for exotic formats the system may try to display - that may result in the same issue, incl crashes)
moreover, it'd be fine to not allow send such huge images, but that can be another issue then
cmp. https://support.delta.chat/t/image-optimization/3749 and "DC Community" chat
The text was updated successfully, but these errors were encountered: