https://bugs.kde.org/show_bug.cgi?id=504241
Bug ID: 504241
Summary: Uncontrolled .ora file growth: no options to disable
mergedimage, thumbnail, or automatic backups
Classification: Applications
Product: krita
Version: 5.2.9
Platform: Microsoft Windows
OS: All
Status: REPORTED
Severity: normal
Priority: NOR
Component: General
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
While testing Krita, I was very impressed by its use of the .ora (OpenRaster)
format. Itβs a strong and future-proof storage concept, based on open standards
like ZIP, XML, and PNG β which is highly appreciated. Well done!
However, there are some practical issues regarding how Krita handles .ora files
during saving and exporting. Specifically, several additional files are always
generated automatically, even if they are not required β and there is no way
for users to disable or configure this behavior.
This leads to unnecessarily high storage usage, especially in environments with
frequent saves and exports.
π Current behavior:
1. mergedimage.png:
This is a full rendered composite of all visible layers. It serves no visible
purpose inside the .ora archive, as Krita stores all layers individually. It is
rarely needed, but easily adds 1β―MB or more to every save.
2. thumbnail.png:
This file is used internally by Krita (e.g. the startup screen), but is ignored
by operating systems such as Windows Explorer. It is often unnecessarily large
β sometimes the same resolution as the project.
Suggestion: allow users to define a maximum size/resolution for the thumbnail
in the settings.
3. .ora~ and other backup files:
When saving, Krita does not overwrite the file directly. Instead, it creates a
complete backup (.ora~) in the same folder β without notice or option.
Even when exporting images (e.g. .webp, .png), if a file already exists, Krita
creates a backup with a ~ suffix. Again, this happens silently and cannot be
turned off.
π‘ Additional note:
Instead of scattering backup copies across working directories, it would make
more sense to offer a central backup folder with a maximum size limit β similar
to how video editors manage autosaves.
Alternatively, old versions could be moved to the system trash/recycle bin, if
desired.
π¨ Real-world impact:
In shared environments (network drives, cloud sync, multiple users), a simple
.ora file that originally used 1β―MB may easily grow to many times that size β
just by saving or exporting as usual.
With two additional automated IT backups running in the background (which is
standard in many environments), storage usage escalates drastically and
silently.
Kind regards,
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
