I only just noticed this after using the transform tool ‘improperly’ for a couple years.
I use a keypad with hotkeys exclusively to navigate Krita, so I have limited space for keybindings. To optimize the workflow, I use ctrl+t bound to a button to move sketches around the canvas, as well as do more advanced distortions. I thought nothing of this, until one day I noticed that this actually blurred my sketches if done too much. I noticed that sketches I had moved around the page a lot had ended up almost looking like they went through a blur filter and looked terrible.
It wasn’t until I looked further into it that I realize that the transform tool, unlike the move tool, resamples the entire image even if you’re just moving it from one spot to another.
My feature request is to have the transform tool not resample images on simple translations.
If this is absolutely necessary to someone’s workflow where they truly need to move the image sub-pixel, then I guess a button on the tool to enable/disable subpixel transform would be the answer to that.
On top of this, layer->rotate 90 shouldn’t resample and blur the image either, it’s a little disconcerting that the only way to losslessly rotate a layer 90 or 180 degrees is either in another program or to rotate the entire canvas, copy the result of the layer, then undo and paste.
I’m not suggesting to merge the tools. If someone gets caught up on the part about the ‘move tool’ then forget I mentioned it, my suggestion is to have translation not resample the layer unnecessarily.
I know what you mean, but I first thought the concept mechanism might be similar when move,90 or 180 degrees, so I just put the link here
Though it may be a total different story
I’m not sure how relvant or valid this is but I did the following:
On one layer, I placed a photograph. On the layer above it I made a duplicate.
On the lower layer, I did a mirror horizontally followed by a mirror vertically to give the equivalent of a 180 degree rotation.
On the upper layer, I did two Transform (Nearest Neighbour) rotations of 90 degrees with a freehand brush paint operation between them, on a ‘spare’ layer, to fully flush the transform operation.
The end result was identical to the lower layer as tested by setting the upper layer to Subtract blending mode.
Repeating that process but using four 45 degree rotations showed that there were slight differences.
So, it seems that a 90 degree Transform rotation is fully accurate with Nearest Neighbour filtering.
I haven’t tried other filtering options.
I’m somewhat fairly sure that moving actually doesn’t degrade images, as long as you only move. I think it even sticks to pixels, which means subpixels can’t be at fault. That’s of course if you don’t do any other transformation at the same time like scale etc.
I’m not sure about rotation. 90 degrees could also have a special non-degrading case. 45 degrees for sure doesn’t have it. But if you don’t go out of the Transform Tool and first rotate by 45 and then again by 45 degrees, it would have the same effect as rotating 90 degrees.
If you notice significant issues, first, make sure you use “Bicubic” option (there might be others better like Lanczos but it’s not guaranteed, and it depends on the image; Bicubic is better than Bilinear in nearly all cases though, and it’s fairly good overall) and that your image has good resolution.
Also you can use Transformation Mask. Then it will kind of always transform from your original image, instead of using the result of previous transformation for the next transformation. It usually means much better results when you transform one image multiple times.
AhabGreybeard is right about nearest neighbor not doing this, because it appears that it only allows you to move the layer at a pixel level. If this same restriction could be applied to the other types, I think it would prevent this blurring entirely.
Can you please check on Krita 4.x? It might be a regression caused by the fact that Krita 5 has some changes in the transform tool. (it might be worth checking the settings in Configure Krita about that tool, too. I think the category is called “Instant Preview”).
Yep, seems like 4.x works fine. Seems to be related to the preview modes. ‘Fast’ is the only one which works like the previous version, while the other two allow subpixel transformation. (it doesn’t resample until the transform is flushed though, chaining multiple transforms doesn’t compound)
Edit: Nevermind, it happens on all preview options
Transform tool changes pixels on a layer. Move tool moves layers on a canvas (including non-pixel layers). For an artist, there is little to no difference and only really causes confusion in my opinion. But they are, technically doing two different things. You’d have to convince the devs to make the merge.
While this sounds plausible, it’s not exactly what happens. If you only move the layer (or the selection, i.e. the “pixels”, in fact), there’s no resampling. My guess is the degradation only happened in older Krita versions.
The main reason for the tool separation is the UX (user experience).
If you use the Transform tool, dragging the mouse outside of the control box defaults to rotation. You need to click inside the box to move.
If you use the Move tool, dragging anywhere can only move the layer/selection. So this is more robust and quicker to use (if all you want is to move stuff).
I use both tools all the time. Another special property of the Transform tool, is that it can move inside multiple selected layers without grouping.
I fixed this in merge request 2137 and just forgot to close this thread.
I highly suggest holding some sort of poll for this, I’m almost completely certain the amount of people who would like a unified transform tool outweighs those who have gotten used to the vestigial limb of the move tool. For example:
I suggest holding ctrl and dragging defaults the transform tool to only move instead of rotate. Since shift rotates bounding box and alt rotates in perspective. Sometimes I want to move a very thin strip, and clicking inside the box is impossible on 4k screens. This would let me do so with the transform tool and officially make the move tool entirely obsolete.
This is not true anymore, as the transform tool can move multiple layers simultaneously with or without a group.
Which means the only reason the move tool exists right now is:
It has a slightly faster algorithm for translating large amounts of data
It only translates pixels.
If we only had the transform tool right now and no move tool, and I suggested a new tool called ‘move tool’ and told the forum its only feature would be ‘slightly faster and only move stuff instead of transform’ I’d be laughed out the room.
Another difference is the Move Tool can handle Wrap Around Mode, the Transform Tool cannot. Their code is completely different, because the Move Tool is simpler and can be more optimized. And thus faster. I wouldn’t say “slightly” faster, on complex things it’s noticeably faster, unless you’re using Transform Tool on Fast, but unlike that the preview’s still accurate.
So you’d have to either make the Move Tool some kind of sub-tool of the Transform Tool, or get the Transform Tool to feature parity, before you could remove the Move Tool. And then users would be very confused by its removal regardless.
So it pretty much circles back around to “improve the Transform Tool”, I think.
I went ahead and set the MR comment as the solution so it will be closed automatically.
Oh I don’t doubt the tools are written very differently and it’s nontrivial to merge them. But I do think getting the transform tool to feature parity so the move tool can be deleted is something worth putting on the radar in terms of suggestions, but that’s for the other recently revived thread.
