Bug 289645 - Krita has wrong sampling of edges on transformations
Summary: Krita has wrong sampling of edges on transformations
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tools/Transform (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-23 08:16 UTC by Dmitry Kazakov
Modified: 2013-01-05 16:18 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot: Gimp vs Krita (95.03 KB, image/png)
2011-12-23 08:16 UTC, Dmitry Kazakov
Details
Patch for hardcoded antialiased edges (8.34 KB, patch)
2011-12-23 13:29 UTC, Dmitry Kazakov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Kazakov 2011-12-23 08:16:04 UTC
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.
Comment 1 Dmitry Kazakov 2011-12-23 08:16:37 UTC
Created attachment 67043 [details]
Screenshot: Gimp vs Krita
Comment 2 Dmitry Kazakov 2011-12-23 13:29:01 UTC
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.
Comment 3 LukasT 2011-12-31 14:33:21 UTC
I'm investigating this bug further.

Why you call your patch hack?
Comment 4 Dmitry Kazakov 2011-12-31 14:57:18 UTC
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
Comment 5 Dmitry Kazakov 2012-12-12 07:04:26 UTC
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
Comment 6 Dmitry Kazakov 2013-01-05 16:18:17 UTC
The krita-fixed-transform-kazakov branch with the fix for this bug has just been merged to master.