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:
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
