Option to not compress images

RobertSpencer

It would be most appreciated if there was an option to not compress images please.

I take a fair amount of screenshots and they get ruined once I save them to Diarium.

On a related note, do imported images get recompressed?

Diarium version: 2.7.10.0
Operating system: Windows 10

timo

I don't think I will add an option that disables compression altogether, but perhaps I add an option to control the level of compression, so that large pictures are less compressed (and limited to max 1600 px side-length) than currently

RobertSpencer

timo Can you please tell me what your reasoning is for not adding an option to disable compression?

You mentioned in a previous post that you are not worried about the database size, so I'm assuming there must be another reason I'm not aware of.

timo

RobertSpencer Can you please tell me what your reasoning is for not adding an option to disable compression?

Raw images are very big and the database size would explode if I would add them without compressing. Even with the compression I know of many multi-gigabyte large databases of users who add a lot of pictures.
Also syncing would be much much slower.

RobertSpencer

timo I'm assuming you are referring to the raw image files from digital cameras, then ouch! That makes sense.

Can I suggest then that you test to see if the file is already in a compressed format and then simply not compress it again?

timo

No I mean "Normal" .jpeg images. Those are usually between 3-5 MB large. Still WAY too large for the Diarium database in my opinion. After compressing the images are currently only 100-200KB max.
As I said, I am thinking of allowing less compression but I will not add an option to disable it completely.

TitanXD

I too would like the option to reduce compression. The loss in image quality is very annoying when I look at my pics and videos.

Bubu

One vote here.
Currently I just using .zip files to archive them

redeyeshev

I have over 3500 images in my Diarium and I've got to say I'm impressed how well they're handled. For regular daily phone snaps the image quality due to the heavy compression isn't a big deal, but I agree the option to reduce compression could be useful for certain images. Maybe a dialog box when adding photos asking to confirm regular or reduced compression would be useful?

StephenHughes

Browsing through questions, I thought this was a good place to ask. How big is TOO BIG for the database?

I have a little over a year journaled now with tons of videos and photos and my diary size when exported is 1.28 GBs. Sooo times that by 10, 20, 30+ years and more...

If the database size gets 100+ GBs (TBs?)... will the database break? Get corrupted? Stop working? App get sluggish?

Just curious because I spent a good amount of time window shopping various journaling apps with the intention of sticking with it for a very long time. I want to know long term if such a large amount of data is feasible.

timo

I am afraid I cannot give you any good numbers on that. I know of some users that had a database file size of over 4 GBs and they weren't complaining about any sluggishness. The feature you would most directly feel the app getting slower is probably the cloud sync.
You can also consider personal computing improving over time in almost every aspect: file storage (size + speed), CPU speed and network speed.
Currently I haven't heard from any users that the app was less usable because of a large database size.

Deeps

Any chance we can get the original request implemented? I exported my journals from Day One and it clocked in around 4GB, and yet I ended up with only 700MB on my WebDAV server after import and sync. A bunch of screenshots cease to be legible, despite “low” compression being enabled.

If there are concerns about sync speed, and users enabling things that they’re not going to understand, can we make this a hidden setting, e.g. “ENABLE ORIGINALMEDIA” (similar to what we do with E2EE)?

timo Currently I haven't heard from any users that the app was less usable because of a large database size

This seems like a strong argument for disregarding the previous concerns about database size ballooning, and giving “power users” enough rope to hang themselves with 😇

EDIT: Actually looking at the file structure that exists on my server, it appears we have a database (I presume sqlite) file, which is small and presumably contains only text, and a separate media store, which stores all the binary data. It’d be super super nice if we could let that explode as big as we would like, since it doesn’t actually impact DB size.

timo

Next app update will bring an option for "low compression" which still compresses the media files, but not as much. Using that option, file sizes will approx. double.
I also fine-tuned the default compression, resulting in slightly better image quality on Android and better video quality on Android and Windows

Deeps

Unsure if the silence is because:

the idea remains in consideration
the request is marked as complete, and is being ignored, and instead should be opened as a new feature request / posted on one of the other threads
the request is completed as far as is willing to be considered, and will be given no further consideration
you’re just too busy right now

Eitherway, thank you for your time and efforts with this app!

timo

There is silence because I cannot respond to every single post (sorry!) and because I currently don't plan to add a "no compression" option.
Uncompressed images are really, really very large and it simply would make the database size explode. It would increase sync times, potentially app memory usage and just take away storage space. People could add it unknowingly ("no compression sounds great!") without understanding the consequences (I know that some users already add an absurd amount of images to their entries and I don't want to limit that). Yes, I could always install warning texts, but that's additional effort and then still some people might ignore them.
I don't want to add "hidden" niche features or options for power users because I still have to maintain and fix bugs for them even though they are used by only a minority of the users.
Also, the separation between text & binary media files is only done on the cloud storage for sync purposes, but locally all data (incl. the media files) is in the SQLite file

Deeps

Understood, thank you for your time and efforts! It’s appreciated!

Coop

Sadly, this is the reason I will continue my search for another diary app or go back to previous. I really like your app, and was so excited about it that I went all in as soon as I came across it a few days ago. Unfortunately, I can't adequately enjoy my memories when looking at low quality photos. 1.18 MB to 213 KB is a drastic change. I don't know how people are doing it. Maybe some one will reply with insight.

I should have did the trial version before buying both platforms. Lesson learned. Thankfully, I am only a few days in.

Thank you for your work. I wish your app continued success.