FreeDATA icon indicating copy to clipboard operation
FreeDATA copied to clipboard

[Feature Request]: compressing and resizing images

Open LA3QMA opened this issue 1 year ago • 1 comments

Problem Description

reminder to do research and later implement automatic resize/compression when sending images.

Proposed Solution

Maybe a option that ask if FD should resize/compress or send "as is".

Alternatives Considered

Option in the configuration that globally enable/disable automatic resize/compression.

Additional Information

No response

LA3QMA avatar Aug 23 '24 17:08 LA3QMA

@LA3QMA ready for testing

DJ2LS avatar Sep 17 '24 09:09 DJ2LS

@LA3QMA hows the image size? Should it be smaller in size? 500x500px seems to be too much while 250x250px seems to be too small

DJ2LS avatar Sep 18 '24 13:09 DJ2LS

Okay, I increased this to 750px, less doesn't make that much sense as the images become too small. However, we have good compression results. But it should be clear, that sending images requires a good channel and lot of data needs to move over the ether.

DJ2LS avatar Sep 18 '24 18:09 DJ2LS

heise 3percent_20240906_140344

I encountered some strange behaviour while using latest FD version and fiddling around with image compression:

  1. The attached file 3percent_20240906_140344.jp is 121 x 68 px in size and results in: image

  2. The attached file heise.png is 16 x 16 px (336 bytes!) and results in: image

The former can perhaps be explained with overhead, but the latter is weird....

dk5sm avatar Sep 19 '24 11:09 dk5sm

pushed a commit, please do a git pull and npm run build should be fixed now

DJ2LS avatar Sep 19 '24 11:09 DJ2LS

Looks good now! The 226 bytes pic expands to 458 bytes, which is probably due to the normal overhead. The other one shrinks from 6915 to 2179 bytes.

dk5sm avatar Sep 19 '24 11:09 dk5sm