Extra compress kra files for archival

Background:

Currently, kra provides options to compress files the *.kra archives some more. It’s a very useful feature for archival but not so useful for general use because it makes krita much slower to save and load files while working on them.

Fulfillment:

Create API or GUI which allows mass-compression of krita files.

Possible easiest fulfillment:

One very valid way is through command line options.
For example, command line options to make use of the compression options that krita has for archival purposes at reasonably much smaller sizes than no compression.

API proposal:

With the suggestion of command line options into account, the API could be done as:

--kra <path> → Operation on kra file
--compress-more → Activate Compress .kra files more until program closes
--compress-zip64 → Activate Use Zlib64 until program closes
--compress-trim → Activate Trim files before saving until program closes

With these options, I think it’s enough to fulfill such objective.

Any opinions/suggestions for improvement of this suggestion?

1 Like

I think this is a good request, may be achieved with a plugin too

You could do this through the zip command line utility, I would think?

This is absolutely correct, but to be “artist-ready”, this should be done via a GUI based solution.
As we can currently see in this topic, “Is there something we can help with my knowledge? Proposal for the forum”, it seems very important to enable usability for all, and the command line discourages a large part of the users.
And a feature that can be helpful to all users should be usable by all without hurdles.
Otherwise, I can already see the questions from users here in the forum: “Which exact command line do I use to achieve which compression?”

Michelist

1 Like

I’m fine with that but I’m a complete disaster with UI. We’d need someone extra to define it and then someone else to implement it.
Wouldn’t that take a long time?
If so, then it could be as an improvement in the future…

I didn’t know plugins can add command line arguments.

I can’t find how to add command line options, though :slightly_frowning_face: :

I’m not a programmer, but if you know a bit about it, then in conjunction with @KnowZero’s “Python Plugin Developer Tools” you should be able to easily create such a plugin. GUI included.
It is presented here:

You can download it here:

Michelist

Edit/Add: And you can always ask here in the forum. There is also a Matrix-Chat and you can reach the developers via IRC if necessary.

However, it isn’t possible to add command line arguments to Krita via python plug-ins.

As I said, I’m not a programmer, but could it be possible, for example, to select the compression rates via a drop-down menu? Of course somehow this info has to be passed to the compressor as well, but I have something like a predefined rule set in mind, not a command line to be handed over.

Michelist

Hi, I have here a recompresskra.sh script; it is a bit complex, take a lot of time to run, but I batch it over large directory sometime at night. The main logic and commands are:

  • Copy the Krita file target to a temporary directory in tmp/
  • unzip the krita file (with unzip command line)
  • optipng the mergedimage, thumbnail
  • zip -9 -r back the full content
  • Move back and rename as the Krita files.

I get a very good compresion with that but very similar to what the checkbox in Krita option does. I made that because I could batch it over many files to reduce the weight of all the Krita files I have on my disk and can’t archive because they are ‘active’ (eg. all Pepper&Carrot pages, artworks, sketches; in sync with remote server).

3 Likes

I don’t know if i am understanding the point of the discussion. But if we are talking about batch operations for archival purposes wouldn’t using the krz ( the krita archival format, i never know how to write it) be useful for this case?

I believe you can run plugins through command line with the kritarunner though i have only heard about it in passing and the lack of documentation doesn’t help.

While commandline is very useful many are intimidated by using it so having a ui would be useful. One thing i would like to point out is that by making it a plugin that executes while running krita you might lock the user from doing anything else while the process is happening.

Which makes me think if a plugin that calls a external script to be run on a separate terminal could help. As you would have a parallel process running and krita would still be usable. The plugin would be just an interface to build the command line that calls the script.

But these are just ideas, i am not sure if they would work as i described them as i only know the basic of the krita plugin API but hopefully any of this can bring more ideas.

1 Like

Thank you @Deevad. That’s a decent workaround.
Did you try other more comprehensive compression algorithms? For example:

  1. lzma
  2. Deflate64
  3. Bzip

I don’t know if krita supports them.

If Krita can handle them, then probably we can have a much smaller footprint with higher compression

As for compressing the png images, even though it’s not open source, I’ve been using pingo. It has a good speed and compression for nowadays.

But if we are talking about batch operations for archival purposes wouldn’t using the krz ( the krita archival format, i never know how to write it) be useful for this case?

krz (at least, by default) deletes the mergedimage.png which is of interest to keep in my case.

While commandline is very useful many are intimidated by using it so having a ui would be useful

True… I’m fine with python but I’m terrible with making UI.

Which makes me think if a plugin that calls a external script […] command line that calls the script.

Yep. That’s a possibility.

Uhm imagine board already does batch processing with threading and I wanted it to help with saves, adding a extra entry would not be to hard.

But I don’t get what you guys are trying to do. Is not KRZ already a compressed format by zip? Would it not be preferable to just batch save into it?

Like brunoais said krz doesn keep the merged PNG image , and that seems important for them to keep in so krz is not an option in this case.

I think the idea is since it is not there the file becomes way smaller. If it is still KRA it is still not a archive. That image file seems to be only important when opening in other programs.

Why not just do the last save of the file with compression? Or just wait a moment as you save with compression?

If there wasn’t a need to navigate all the way to that menu it would be (possibly) acceptable…
However, I could win best to have it compressed the most during night time when I do the backups and such. I do that about once per week.
Given so, an automated way would be preferible

It’s not a workaround. It’s the recommended way of working. There is no need for Krita to add code to handle this.

Go to Documentation / Krita.org Documentation Website · GitLab, write the documentation you want and create a merge request. The --help argument to the kritarunner executable provides all the information you need for that.

1 Like

Oh! Ok. I’ll add that to the documentation after some testing, then!

Additionally, do you know what zip compressions krita supports for opening? Is it only Deflate and Deflate64? Does it support lzma, for example? knowing that would speed up my process by a lot!
Additionally, if you can tell what the trim process actually does, maybe I can automate it somehow.

Krita uses minizip internally, Minizip: Zip and UnZip additionnal library, through quazip. Krita itself only uses Z_DEFLATED. Trim removes layer content outside the image bounds. It’s the equivalent of Image->Trim to Image Size.

1 Like