# Allow the Recorder docker to capture the canvas instead of the entire image **URL:** \ **Category:** Feature Requests\ **Tags:** for-ui-ux\ **Created:** [August 3, 2026, 5:48pm UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140 "2026-08-03T17:48:33Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![tysontan](https://krita-artists.org/user_avatar/krita-artists.org/tysontan/32/103945_2.png) [@tysontan](https://krita-artists.org/u/tysontan)\ **Post date:** [August 3, 2026, 5:48pm UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/1 "2026-08-03T17:48:33Z")
Krita’s Recorder docker currently captures only the **entire image** , which often lacks focus – especially for multi-day artworks where most time is spent refining small details. When zoomed out, viewers struggle to follow the artist’s active area, particularly in later stages. This is why I haven’t shared any timelapses: e.g., my latest Krita splash timelapse runs over 30 minutes, yet I – its creator – can’t track what’s happening in ~27 minutes of it. 😂 Adding a “ **canvas-only** ” capture option would help: it reflects exactly what the artist sees while working, making the process intuitive for viewers. It’s also less resource-intensive, as the canvas is typically much smaller than the full image. Additionally, letting users set a **custom W/H ratio** (centered on the canvas) would simplify post-recording editing – only overlays and audio need adding. The result would be far more usable, encouraging broader adoption of the Recorder docker. ---
**Author:** ![Takiro](https://krita-artists.org/user_avatar/krita-artists.org/takiro/32/209381_2.png) [@Takiro](https://krita-artists.org/u/Takiro)\ **Post date:** [August 3, 2026, 6:00pm UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/2 "2026-08-03T18:00:15Z")
I did some recordings like that with OBS and especially at high speed (don’t forget it’s not realtime but a time lapse) they are a very unpleasant to watch. There’s just so much flicking around, especially when you rotate and zoom a lot. Here’s an example of what I mean. [https://youtu.be/1add1PDIQR0](https://youtu.be/1add1PDIQR0) I understand your argument, it’s why I did it like that, but honestly, it’s really hard to actually see what’s going on. Only in real time it’s actually nice to watch but no one really wants to watch a ten hour painting video. > [@tysontan](#): > > It’s also less resource-intensive, as the canvas is typically much smaller than the full image. No. The current recording can be just as efficient, you only have to set the size of the snapshots to be smaller. ---
**Author:** ![tysontan](https://krita-artists.org/user_avatar/krita-artists.org/tysontan/32/103945_2.png) [@tysontan](https://krita-artists.org/u/tysontan)\ **Post date:** [August 3, 2026, 6:18pm UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/3 "2026-08-03T18:18:31Z")
Yeah, I think you are right about the canvas dodging at high speed, unless the artist consciously keeps the canvas stationary for a long time. I wonder if there is some kind of video editing magic to track hotspot area. I just watched some timelapses from other artists and their canvas is always focused at where they work, but the recorded area is also very stable. The recordings is faster than 4x, but they didn’t dodge around. Added: So I found out that Kdenlive has a stablizer and tracker: > **[Motion Tracker — Kdenlive 26.04 Manual 26.04 documentation](https://docs.kdenlive.org/en/effects_and_filters/video_effects/alpha_mask_keying/motion_tracker.html)** > > Kdenlive Video Effects - Motion Tracker I wonder if that’s what I was looking for… ---
**Author:** ![EyeOdin](https://krita-artists.org/user_avatar/krita-artists.org/eyeodin/32/2662_2.png) [@EyeOdin](https://krita-artists.org/u/EyeOdin)\ **Post date:** [August 4, 2026, 5:45am UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/4 "2026-08-04T05:45:32Z")
Cant you just zoom with the video editor ? ---
**Author:** ![tysontan](https://krita-artists.org/user_avatar/krita-artists.org/tysontan/32/103945_2.png) [@tysontan](https://krita-artists.org/u/tysontan)\ **Post date:** [August 4, 2026, 6:11am UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/5 "2026-08-04T06:11:41Z")
Editing takes time and effort, and manually tracking the active area past rough shading stage is difficult. Imagine editing the 30-minute Kiki splash video I mentioned in the first post. The timelapse is just a byproduct of drawing – if preparing it becomes burdensome, it becomes impractical. Its only real use would be verifying the artist drew the piece – not for viewer enjoyment or study. But I understand this is not Krita’s core responsibility. I will try to do this in Kdenlive for now. Not everyone knows how to edit timelapse videos, including me. Since Krita already uses the MLT framework for animation, integrating Kdenlive’s motion tracker would make life easier for us. ---
**Author:** ![Ciubix](https://krita-artists.org/user_avatar/krita-artists.org/ciubix/32/202546_2.png) [@Ciubix](https://krita-artists.org/u/Ciubix)\ **Post date:** [August 4, 2026, 11:44am UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/6 "2026-08-04T11:44:31Z")
I have made a rough implementation, that doesn’t have any extra ui and just replaces the current behavior, to test the concept. Here’s the resulting timelapse that i get: I am not really an artist, so i don’t know how it will behave in when actually working on something If you want to test it yourself, you can get a build from here [Pipeline #1311108 · Luna Lovecraft / Krita · GitLab](https://invent.kde.org/ciubix/krita/-/pipelines/1311108) ---
**Author:** ![tysontan](https://krita-artists.org/user_avatar/krita-artists.org/tysontan/32/103945_2.png) [@tysontan](https://krita-artists.org/u/tysontan)\ **Post date:** [August 4, 2026, 1:21pm UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/7 "2026-08-04T13:21:03Z")
Thank you, Luna – the video you posted is exactly what I envisioned. There’s some minor jumping, but far less noticeable than in OBS recordings. My guess is Krita’s recorder isn’t real-time; it captures the canvas only after each action – so if the artist keeps the canvas stable, the recording stays stable too. This approach is far more usable and viewer-friendly than full-screen capture. Unfortunately, the build failed, so I couldn’t test it. ---
**Author:** ![Takiro](https://krita-artists.org/user_avatar/krita-artists.org/takiro/32/209381_2.png) [@Takiro](https://krita-artists.org/u/Takiro)\ **Post date:** [August 4, 2026, 1:30pm UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/8 "2026-08-04T13:30:31Z")
Doesn’t look as unpleasant as I thought. However when there are sudden cuts, like extreme zoom-in or being on the other side of the canvas it is very disorienting and I imagine it will be hard to follow for the viewer to which part of the image the view suddenly jumped. If there were a way to have a smother transition, then I could imagine this being actually good. However, that would mean having to record extra frames for that, to have a visual zoom/pan. ---
**Author:** ![tysontan](https://krita-artists.org/user_avatar/krita-artists.org/tysontan/32/103945_2.png) [@tysontan](https://krita-artists.org/u/tysontan)\ **Post date:** [August 4, 2026, 2:10pm UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/9 "2026-08-04T14:10:38Z")
I don’t think it’s that hard to follow – most images feature just one character, and viewers can usually identify the body part from anatomy alone. Artists can trigger capturing manually by occasionally zooming out and adding temporary dots on a separate layer, then erasing them. This is a very dumb but low-cost and intuitive solution for the artist to control when to show their viewers an overview. Smooth transitions would be nice but are far more complex than simple canvas capture. The current recorder is simple and clean – it only grabs still frames; transitions are EFFECTS that would add complexity and hurt long-term code maintainability. Since canvas recording already works well, for a feature only useful for some, I’m happy with it – we can save dev time for higher-priority tasks. ---
**Author:** ![Ciubix](https://krita-artists.org/user_avatar/krita-artists.org/ciubix/32/202546_2.png) [@Ciubix](https://krita-artists.org/u/Ciubix)\ **Post date:** [August 4, 2026, 2:26pm UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/10 "2026-08-04T14:26:02Z")
I think it may be relatively simple to capture frames when moving/zooming in the canvas. I should look into the code for that. ---
**Author:** ![tysontan](https://krita-artists.org/user_avatar/krita-artists.org/tysontan/32/103945_2.png) [@tysontan](https://krita-artists.org/u/tysontan)\ **Post date:** [August 4, 2026, 2:29pm UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/11 "2026-08-04T14:29:01Z")
I think the risk of capturing view change without action is less artist control of what to show and more jumping – it’s basically the OBS situation. You’ll need some kind of algorithm to choose the right key frames. And it will also bloat up the capture data. Speaking of which, I think it’s useful to have a button/action to trigger “Manually capture X still frames”. ---
**Author:** ![Ciubix](https://krita-artists.org/user_avatar/krita-artists.org/ciubix/32/202546_2.png) [@Ciubix](https://krita-artists.org/u/Ciubix)\ **Post date:** [August 4, 2026, 5:33pm UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/12 "2026-08-04T17:33:25Z")
> [@tysontan](#): > > Unfortunately, the build failed, so I couldn’t test it. I’m finally home, so was able to restart the build, i hope it won’t time out this time ---
**Author:** ![Ciubix](https://krita-artists.org/user_avatar/krita-artists.org/ciubix/32/202546_2.png) [@Ciubix](https://krita-artists.org/u/Ciubix)\ **Post date:** [August 4, 2026, 7:17pm UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/13 "2026-08-04T19:17:50Z")
Apparently job timeout is shorter in a fork.. Which is why it failed again, hopefuly this time it will actually build: [Draft: Record only a section of the canvas (!2893) · Merge requests · Graphics / Krita · GitLab](https://invent.kde.org/graphics/krita/-/merge_requests/2893) ---
**Author:** ![tysontan](https://krita-artists.org/user_avatar/krita-artists.org/tysontan/32/103945_2.png) [@tysontan](https://krita-artists.org/u/tysontan)\ **Post date:** [August 9, 2026, 10:03am UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/14 "2026-08-09T10:03:01Z")
![electric_20260806A_kiki_newrecorder_test](https://krita-artists.org/uploads/default/original/3X/e/1/e12e1aae8c457b6394cf4487f1527bc04c07ef6b.jpeg) This is the timelapse I did with the canvas only recorder: [https://tysontan.com/temp/electric\_20260806A\_kiki\_newrecorder\_test.mp4](https://tysontan.com/temp/electric_20260806A_kiki_newrecorder_test.mp4) The planning stage was done zoomed-out, which ends at 00:30. After that the canvas starts to move and zoom. The recording feels shakier than I expected, perhaps partly due to the picture was a very quick sketch, so the viewport doesn’t stay in one place for very long. Or, the jumping happened because it recorded my view movements (temporary zooming out for overview). I spent more time zoomed-in when I was cleaning up Kiki’s hand at 02:10, so that section is closer to my expectation. I think the recording can be more presentable if I control the canvas more deliberately in the future. I have a relatively large pen display (19 inch 4K), so I don’t need to zoom in and move a lot with this one, as I didn’t draw much detail. I can test this again with a more common size display (16 inch 2.5K). Despite looking shakier than I hoped, I still think it looks promising. Maybe we can get it to work better with a bit more tweaks (both from the app side and the artist side). Please let me know if there is anything I can do to help. ---
**Author:** ![Ciubix](https://krita-artists.org/user_avatar/krita-artists.org/ciubix/32/202546_2.png) [@Ciubix](https://krita-artists.org/u/Ciubix)\ **Post date:** [August 9, 2026, 10:33am UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/15 "2026-08-09T10:33:17Z")
The time lapse is annoyingly shaky in places, yea, especially when zooming out. i think tracking the movement of the canvas will help to smooth it out. but i am worried it will bloat it both with in terms of file size and wasted time. But it’s probably worth testing, my latest build has that implemented. Also yes, using a smaller monitor may be more interesting for testing this feature. ---
**Author:** ![raghukamath](https://krita-artists.org/user_avatar/krita-artists.org/raghukamath/32/59144_2.png) [@raghukamath](https://krita-artists.org/u/raghukamath)\ **Post date:** [August 9, 2026, 10:38am UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/16 "2026-08-09T10:38:21Z")
I think the black background for areas beyond the canvas makes it worse. Would it be possible to have a background of a neutral color derived from the average of colors on the canvas. I think that will make it less glaring. ---
**Author:** ![tysontan](https://krita-artists.org/user_avatar/krita-artists.org/tysontan/32/103945_2.png) [@tysontan](https://krita-artists.org/u/tysontan)\ **Post date:** [August 9, 2026, 10:49am UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/17 "2026-08-09T10:49:47Z")
I already recorded the section past 00:30 using the build you messaged me. I’m not sure whether recording the canvas movement actually helped or only caused jumping when I occasionally zoom out for overview. What’s your observation? ---
**Author:** ![tysontan](https://krita-artists.org/user_avatar/krita-artists.org/tysontan/32/103945_2.png) [@tysontan](https://krita-artists.org/u/tysontan)\ **Post date:** [August 9, 2026, 10:51am UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/18 "2026-08-09T10:51:16Z")
Yeah, that will make it less stimulating, but still the content itself is causing the major shaking. ---
**Author:** ![Ciubix](https://krita-artists.org/user_avatar/krita-artists.org/ciubix/32/202546_2.png) [@Ciubix](https://krita-artists.org/u/Ciubix)\ **Post date:** [August 9, 2026, 11:16am UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/19 "2026-08-09T11:16:06Z")
Oh, okay, that explains the zooming out jumps. I assumed you were doing actions there so it recorded zoomed out frames. I think what i can do is instead of actively tracking the canvas movement and directly recording it into frames. I can compare the locations of the canvas between frames, and if it changes generate a few frames of it moving between the 2 locations. This should remove the very annoying jumps when zooming out to view everything. ---
**Author:** ![Ciubix](https://krita-artists.org/user_avatar/krita-artists.org/ciubix/32/202546_2.png) [@Ciubix](https://krita-artists.org/u/Ciubix)\ **Post date:** [August 9, 2026, 11:17am UTC](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140/20 "2026-08-09T11:17:30Z")
Yea, that should be a relatively easy improvement [Next page](https://krita-artists.org/t/allow-the-recorder-docker-to-capture-the-canvas-instead-of-the-entire-image/188140.md?page=2)