In-file timelapse data

Fully integrating timelapses into the krita file itself would fix multiple issues and allow for easier development and control over the feature.

Here are several things which could be accomplished by saving timelapse data in the file itself:

  1. The ability to turn on or off timelapse recording per picture. The option is saved within the file itself, and if it is on, it will begin recording as usual when the file is being worked on. I’ve personally forgot to begin recording at times and this would prevent that.
  2. Easier management of the data itself. Right now, files are saved externally. If they are integrated into the kra file, it will take the burden off of the user to keep and manage those files by themselves.
  3. There are many options available for the data to take up less space on disk. For example, only saving the section of the image that changed along with the metadata of where that section belongs and the size of it. Or even something simpler like general compression.
  4. Making the creation of exported timelapse videos more succinct and user-friendly. Right now if I remember correctly, it’s just an ffmpeg gui. It’d still obviously use ffmpeg, but much more could be automated or hidden from artists when the file inherently knows about its own timelapse data.
  5. By saving data about which undo ID the user is currently on during any given frame save, frames which have been ‘undone’ can be deleted by the program automatically, as an option for users to check or uncheck if they’d rather have a smoother timelapse or a more accurate one
  6. By saving zoom and rotation data at the time of each change, the data that provides when finally exporting the video can be used to create a sort of hyperlapse, where the exported video smoothly attempts to follow the action of the changes.
  7. Exporting timelapse data to a series of images would be an option, where Krita can ‘decompress’ the data it has on the timelapse into individual frames for the user to use in other programs. It could also export any metadata it has in a popular format, for anyone that would need it.
  8. Krita can now know and save when the canvas size is modified, preventing the cropping problems that the current system has.

It may also come with some downsides:

  1. Krita will need to have a place to store this data externally, as it obviously shouldn’t be constantly ‘saving’ to the file. This could be in a defined memory buffer before being moved to a scratch disk or app folder after a certain size. Any scratch data older than the last autosave can be discarded because the autosave could include either a full version of the timelapse data or maybe just anything created since the last actual save.
  2. The Krita file sizes will increase dramatically for any files with enabled timelapses. This may not be the case if there are features to prevent that, such as ‘recording’ at a lower resolution, or good compression algorithms that focus on frame differences rather than the entire frame’s data. And it’s not like the filesize would necessarily be bad, because the current method creates equally large filesizes as well with all the exported images.
  3. Everything mentioned could also be accomplished just as well by creating a ‘Krita timelapse’ filetype, that is saved and loaded separately from the main Krita file. I’m not against that. It would also allow users to keep their timelapses on something like a spare hard drive rather than their main speedy drive.

Thank you.

1 Like

Alright this sounded better in my head, I just checked one of my recording folders for a single picture and realized it was 15GB. lol

Some sort of frame difference compression algorithm would definitely have to be implemented if this was done.


I agree some work should be done with the timelapse recorder though i really do not like the idea of storing the snapshots inside the kra file. As you pointed out it can bloat the file a lot. That’s one thing i already dislike in CSP timelapse implementation.

The settings for recording on/off being stored in the file however sounds completely reasonable and i think it would be a good improvement on the feature.

Improvements on the export would be a good addition, there are already known cases of adjustments that could be easily made into the options like “don’t stretch the image if the canvas size is changed” and pixel art recording.

The undo id would be a real improvement i like the idea. Though i really didn’t understand the zoom and rotation part.

Personally i like your idea of having it stored in a separate file, as it wouldn’t bloat the krita file. I remember someone made a thread of a image format that was very small but kept quality that could be useful for saving the timelapse.( Found the thread Any plans to support the .qoi image format?)

Right now the PNG format is unusable if you have a long timelapse unless you want to have a 90 gb folder. Which leaves us with jpeg and at 80% quality seems like a good compromise to me but would be nice to have more options that could reduce disk space usage.

Having its own file format i think it could bring improvements to link it to the kra file as right now the link between folder and kra file seem to be easily breakable.
One thing i would find interesting is that if you change the name of the kra file when you open it krita could check if there was a timelapse file for it and relink it if the original name of the file was kept somewhere in the kra file.
I honestly don’t know how this is handled now with the timelapse but i think it’s more fragile.

For the timelapse file itself i am unsure if a SQLite database could be useful as i think that’s how clip studio stores it or a zip file like kra could be used, the images would also need to be stored somewhere before being zipped.

Sometime ago on the discord server, I talked about having small portions of the recordings converted to webm on the go to save space. For example if you have 000.png to 010.png on the next screenshot 000.png to 008.png would be converted to a small webm clip (or any other video format) this way there is no need to store entire sequence in png or jpg which adds up space (unless of course the user specifically wants a sequence) In the end all those clips can be merged in to one single video.

1 Like

Would there still be an option to use the sequence of images? :open_mouth:

I’d imagine that if you wanted a series of images, Krita could have a function to export the highly-compressed timelapse file into png’s or jpg’s. It’s going to have to have that functionality for ffmpeg input anyway.

1 Like

Yes I wrote that if user wants it can be a sequence. This is just my suggestion/idea it is not going to be like that

1 Like

+1 for not storing in the kra, but the on/off feature could be useful for people.