The screenshot Gimp vs Krita is in attachment. This result is generated with rotating a fully opaque image to 89deg. You see that Krita has some artifacts on the border of the image. This happens due to the following: We use multipass image transformation, but: 1) We always repeat the last pixel on the border of the image, so the first pass has no way to antialias the border 2) The next passes antialias the border, but this is done totally due to new transparent pixels generated by the first pass. Actually, these pixels shouldn't have been used at all. 3) Because of these facts the antialiasing of the border is incomplete, that's why it looks like that.
Created attachment 67043 [details] Screenshot: Gimp vs Krita
Created attachment 67060 [details] Patch for hardcoded antialiased edges Well, this is really a weird bug. I don't know how to fix it yet. The only thing I managed to do is the attached patch. It uses a parameter to the worker, which shows whether to use one more pixel for mixing or not. It is a hack, but probably will help someone while investigating this bug further.
I'm investigating this bug further. Why you call your patch hack?
Because: 1) It makes pure scaling of the image wrong (1px width border appears) 2) While shear one edge has smoothing, but the other doesn't. What my patch does is basically reverts Boemann's commit [1] As far as I understand it, when doing scale, the full opacity of the border pixels should be produced purely by integer arithmetic. Just the border pixels should have "center" variable aligned perfectly onto the imaginary grid. Currently, this is not so, that's why we have these pixels transparent. I have such a feeling that there is a problem in maths. Adding some arbitrary pixels on the border of image may lead to really confusing results, because the transformation is done in several passes, so after the first pass, the boundary pixels are already not "boundary" actually. [1] - http://quickgit.kde.org/?p=calligra.git&a=commit&=f3ec1515819470c15d1c0bec32e8e25af8560cf7
Git commit 95e686eb0fb97a6b9a2a7644a819660bafba4f96 by Dmitry Kazakov. Committed on 12/12/2012 at 08:03. Pushed by dkazakov into branch 'krita-fixed-transform-kazakov'. Added two classes for the new version of KisTransformWorker KisFixedPoint now represents the .8 fixed point arithmetics. Current hardcoded fp.8 implementation in the KisTransformWorker has various flaws like rounding and dealing with negative values. KisFilterWeightsBuffer represents a part of KisTransformWorker that generates weights for the pixel blending. Being able to add it to the unittest I could catch many mathematical problems in it. Now these is one more class to be written (that will do the actual blending) and then it all will have to be merged into KisTransformWorker. A +213 -0 krita/image/kis_filter_weights_buffer.h [License: GPL (v2+)] A +128 -0 krita/image/kis_fixed_point_maths.h [License: GPL (v2+)] M +12 -0 krita/image/tests/CMakeLists.txt A +140 -0 krita/image/tests/kis_filter_weights_buffer_test.cpp [License: GPL (v2+)] A +38 -0 krita/image/tests/kis_filter_weights_buffer_test.h [License: GPL (v2+)] A +108 -0 krita/image/tests/kis_fixed_point_maths_test.cpp [License: GPL (v2+)] A +34 -0 krita/image/tests/kis_fixed_point_maths_test.h [License: GPL (v2+)] http://commits.kde.org/calligra/95e686eb0fb97a6b9a2a7644a819660bafba4f96
The krita-fixed-transform-kazakov branch with the fix for this bug has just been merged to master.