pegon's blog
https://blogs.kde.org/blog/7783
KDE Development in action.enHaving some fun with old maps
https://blogs.kde.org/2010/09/10/having-some-fun-old-maps
<div class="field field-name-taxonomy-vocabulary-2 field-type-taxonomy-term-reference field-label-above clearfix"><h3 class="field-label">KDE Project: </h3><ul class="links"><li class="taxonomy-term-reference-0"><a href="/kde-project/kde-general">KDE General</a></li></ul></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>While relaxing after the hard-working period that was the GSoC, I came across a comment left by Torsten Rahn of the marble team. He wondered whether it would be possible to adapt image warping functionality so that it can be used to morph some old maps.</p>
<p>Apparently, they would like to add historical maps to Marble. Unfortunately, these maps are most of the time not "plate carrée projections" of the globe, which is a requirement for Marble. Hence they use xmorph to convert those maps "by hand" into plate carrée projections.</p>
<p>Of course, it would be too long and too hard for me to do something like xmorph. Though, after taking a look at some of these old maps and searching on wikipedia, I became pretty sure these were some kind of stereographic projections (actually two stereographic projections : each one representing a half of the globe).<br />
So, I did the maths and wrote a simple command-line program to convert automatically stereographic projections to plate carrée projections.</p>
<p>I was quite convinced the result would be bad, but actually it turned out quite well :). My program takes a .ppm square image of a semi stereographic projection (rightly centered, etc..) and converts it to a .ppm square image of a semi plate carree projection (the plate carree projection of the corresponding half of the globe).</p>
<p>I tried it with a map that had already been converted by the marble team, in order to see if I obtained the right result.<br />
Here is the original map :<br /><a href="http://lh5.ggpht.com/_KZOijM4jJGU/TIqSYGdewUI/AAAAAAAAAI8/FYB4G4GblQY/World_Map_1689_orig.jpg"><img src="http://lh5.ggpht.com/_KZOijM4jJGU/TIqULdMZDnI/AAAAAAAAAJM/4T0KRd6hSxI/World_Map_1689_orig_thumb.png" width="400" height="345" /></a></p>
<p>And the expected result :<br /><a href="http://lh3.ggpht.com/_KZOijM4jJGU/TIqPCVOHrEI/AAAAAAAAAI0/QzOOFYwYqtM/World_Map_1689.jpg"><img src="http://lh6.ggpht.com/_KZOijM4jJGU/TIqULrBB0VI/AAAAAAAAAJQ/3S8cbbYxG04/World_Map_1689_thumb.png" width="500" height="250" /></a></p>
<p>Here is what I gave to my program (the stereographic projection of one half of the globe, cut from the original map, and scale a bit to make it a perfect circle) :<br /><a href="http://lh3.ggpht.com/_KZOijM4jJGU/TIqU19MV0mI/AAAAAAAAAJU/ehKlRILwnU0/input.png"><img src="http://lh4.ggpht.com/_KZOijM4jJGU/TIqU4FOBhZI/AAAAAAAAAJY/5ARYApscj80/input_thumb.png" width="400" height="400" /></a></p>
<p>And here is what I obtained (the operation took about 2 seconds) :<br /><a href="http://lh4.ggpht.com/_KZOijM4jJGU/TIqWJ5qiFwI/AAAAAAAAAJg/BJq4_Zffyv4/output.png"><img src="http://lh4.ggpht.com/_KZOijM4jJGU/TIqWLgCToII/AAAAAAAAAJk/7lEOr69yJY0/output_thumb.png" width="400" height="400" /></a></p>
<p>Torsten Rahn told me the result looks very similar to what they obtain with xmorph :). They also had distortions appearing on the edges, which needed to be fixed by hand.</p>
<p>For fun, I wanted to try it with a map that hadn't been converted yet :<br /><a href="http://lh6.ggpht.com/_KZOijM4jJGU/TIqWkyXcrDI/AAAAAAAAAJs/CQRASGLnWrw/Nova_totius_Terrarum_Orbis_geographica_ac_hydrographica_tabula_(Hendrik_Hondius)_balanced_orig.jpg"><img src="http://lh3.ggpht.com/_KZOijM4jJGU/TIqaQQ0HqwI/AAAAAAAAAKI/NMeu-UZ3KqI/Nova_totius_Terrarum_Orbis_geographica_ac_hydrographica_tabula_(Hendrik_Hondius)_balanced_orig_thumb.png" width="500" height="351" /></a></p>
<p>Here is what I obtained quickly (just the time to cut the two halves of the globe, give them to my program, and merge them properly) :<br /><a href="http://lh4.ggpht.com/_KZOijM4jJGU/TIqXijBP2xI/AAAAAAAAAJ4/SreMfhX3ARk/Nova_totius_Terrarum_Orbis_geographica_ac_hydrographica_tabula_(Hendrik_Hondius)_balanced.png"><img src="http://lh6.ggpht.com/_KZOijM4jJGU/TIqXlR6C49I/AAAAAAAAAJ8/NnuWWZrcnsM/Nova_totius_Terrarum_Orbis_geographica_ac_hydrographica_tabula_(Hendrik_Hondius)_balanced_thumb.png" width="500" height="250" /></a></p>
<p>For those who are interested, here are the <a href="http://dl.free.fr/rBEbEXyal">sources</a>. It's written in pure C99, and under LGPL.</p>
<p>Now, back to Krita. I was a bit lazy the past few weeks, since I merely fixed 2 or 3 bugs related the transform worker. And now that I am back to school, I will have even less time to work on Krita. Anyway, even if it is at a lower pace, I will still find time to contribute, and maybe even blog ;).</p>
</div></div></div>Fri, 10 Sep 2010 21:10:16 +0000pegon4322 at https://blogs.kde.orghttps://blogs.kde.org/2010/09/10/having-some-fun-old-maps#commentsGSoC: Conclusion - Screencasts
https://blogs.kde.org/2010/08/18/gsoc-conclusion-screencasts
<div class="field field-name-taxonomy-vocabulary-2 field-type-taxonomy-term-reference field-label-above clearfix"><h3 class="field-label">KDE Project: </h3><ul class="links"><li class="taxonomy-term-reference-0"><a href="/kde-project/krita">Krita</a></li></ul></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>Though this entry will be the last one about my GSoC, it certainly won't be the last one about my work on Krita or even on its new Transformation Tool. It was a great summer, I had a lot of fun working on this project. It was all the more stimulating so as I could follow the progress of the other GSoC students working for Krita. Everyone did such an incredible job, it gave me the envy and the energy to complete my project and make it as it is.</p>
<p>I'll be brief about what I did the past two weeks, as I prepared 3 small screencasts which will show you what the new tool looks like and how to use it.<br />
Two weeks ago, I had just implemented warp functionality, so I still had some work to do on the UI.<br />
First I changed the way to switch between Free Transform and Warp mode, so that the Tool Options Widget changes depending on the mode.<br />
In warp mode, the user can either use default control points placed like a grid whose density can be changed, or place the control points by himself/herself.<br />
In the paper I used as reference for the maths, 3 deformation functions were described, and I had only implemented one (affine). Thus I then added similitude and as-rigid-as-possible deformation functions.</p>
<p>Here is a picture I produced with the tool, which illustrates the difference between those functions. From left to right : original image (sorry if it's not very nice, I made it myself), warped using affine function, similitude function, and rigid-as-possible function.</p>
<p><img src="http://lh6.ggpht.com/_KZOijM4jJGU/TGxTdA6dJTI/AAAAAAAAADQ/3xF1ep1AIw8/warp_functions.jpg" /></p>
<p>Last week I essentially cleaned the code, fixed some bugs/weird behaviours, and changed some icons.</p>
<p>To close this entry, I wanted to show the results of my hard work, so here are some screencasts of the tool in action :</p>
<ul><li>Using <a href="http://www.youtube.com/watch?v=n0iy9vJ5H14">Free Transform mode</a>.
</li><li>Using <a href="http://www.youtube.com/watch?v=ytJZ9R1e6iI">Warp mode</a>.
</li><li>And a last one using Warp mode to show the difference between <a href="http://www.youtube.com/watch?v=kWuwBwRW5OA">warp functions</a>.
</li></ul></div></div></div>Wed, 18 Aug 2010 22:04:03 +0000pegon4314 at https://blogs.kde.orghttps://blogs.kde.org/2010/08/18/gsoc-conclusion-screencasts#commentsGSoC: At last, image warping !
https://blogs.kde.org/2010/08/01/gsoc-last-image-warping
<div class="field field-name-taxonomy-vocabulary-2 field-type-taxonomy-term-reference field-label-above clearfix"><h3 class="field-label">KDE Project: </h3><ul class="links"><li class="taxonomy-term-reference-0"><a href="/kde-project/krita">Krita</a></li></ul></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>I spent the past 10 days working on image warping. It wasn't easy, but I think most of the work is done !</p>
<p><img src="http://lh4.ggpht.com/_KZOijM4jJGU/TFaqpGdVV8I/AAAAAAAAABE/G-GnDCT6l6A/s800/warp2.jpg" /></p>
<p>Since I had absolutely no idea concerning the algorithm, and wasn't even sure what I wanted to do - I only knew I wanted to add an "image deformation" functionality to the tool -, I began searching randomly on the web. I eventually came across a nice paper entitled <a href="http://faculty.cs.tamu.edu/schaefer/research/mls.pdf">Image Deformation Using Moving Least Square</a>.<br />
Apart from the snappy pictures at the top of the front page, what I liked was that it gave implementation details and put the emphasis on the speed of this method.<br />
Basically, it describes 3 different math functions (affine, similitude, and moving least squares) which distort an image according to the modifications made on a set of points.</p>
<p>I thought I could give it a try and began the implementation of the first one, i.e. affine deformation. It essentially consisted in some operations on 2D vectors and 2x2 matrices. Applying it roughly on a QImage produced something so horrible that I decided to take a closer look at the paper : there was actually a small mistake in the paper (a coefficient disappearing between 2 lines, nothing serious). Here is the kind of things I obtained after fixing the calculation :</p>
<p><img src="http://lh4.ggpht.com/_KZOijM4jJGU/TFaqp12ScVI/AAAAAAAAABI/KBtZLYemSEM/s512/warp_try_0.jpg" /></p>
<p>I expected something like this : those "artefacts" you can see are actually pixels which have not been given a color. The thing is, the fact that you iterate over every pixel of the source image doesn't mean that you will "light up" every pixel of the destination image. It is actually quite a classic problem.<br />
Most of the time, the simplest solution is to iterate over every pixel of the destination image (instead of those of the source), and light them up with the correct color ; that is, provided that you can invert the function ("what pixel (x,y) of the source will go to pixel (x',y') of the destination ?"). Unfortunately, it's not the case here : that is problem #1.<br />
Problem #2 is the speed. Applying the transformation function to every point of the source is too slow to compute a preview in real-time : it took about 2 seconds to compute the image.</p>
<p>Turns out both problems could be solved simultaneously if I found a way to fill the blanks left when applying the function on the pixels of the source. In fact, the image can be seen as a set of quads which are transformed into other quads by the function, so filling the blanks boils down to interpolating the inside of these quads. To speed up the process, I could apply the deformation function to only some points of the source (like 1 over 5 or even less), and interpolate the inside of bigger quads, based on the hypothesis that interpolating quads is faster than applying the transformation function. It doesn't really matter if the preview is not 100% accurate (that's the a point of using a preview).</p>
<p>The first step was to be able to do something similar to filling a quad (or more generally a polygon), given its vertices. While Qt can fill a polygon, there is no way to customize the operation applied on each pixel of the polygon (as far as I know). I came to the conclusion I had to write my own method to fill a polygon, and it had to be fast. Fortunately, I wrote something like that this year for a project for my school of engineering (it was in Ada though) - a scanline fill polygon procedure with Sutherland-Hodgman algorithm for clipping -, and I was quite proud of its speed. I translated it in C and tried to fill the quads with the color of their top left vertices (for starters).</p>
<p>Here is an example before quad filling, with the transformation function applied to 1 pixel over 3 :<br /><img src="http://lh6.ggpht.com/_KZOijM4jJGU/TFaqqvbtIXI/AAAAAAAAABU/TtR1NUItvrc/warp_try_0_bis.jpg" /></p>
<p>Here is one image I obtained after quad filling :<br /><img src="http://lh4.ggpht.com/_KZOijM4jJGU/TFaqqFj1EzI/AAAAAAAAABM/I9t9oNxkGNw/warp_try_1.jpgR" /></p>
<p>You can see that even if it's pretty ugly - there is no interpolation yet -, it's working ! The positive aspect is that filling the blanks is indeed faster than applying the transformation function to every pixel. The negative one is that it isn't fast enough : I have to go up to 1 pixel over 10 to have something relatively smooth (and of course it's even more inaccurate and ugly). My function seems however as fast as Qt's (though I didn't benchmark anything).</p>
<p>I hoped that maybe it would be more decent if I applied a bilinear interpolation to fill the quads, based on the color of their 4 vertices. Here is what I got, with only a minor decrease of the speed :<br /><img src="http://lh4.ggpht.com/_KZOijM4jJGU/TFaqqZUk6jI/AAAAAAAAABQ/3Kto-wTUyaw/warp_try_2.jpg" /></p>
<p>The result was clearly not good enough, so I gave it a little more thinking.<br />
Eventually, I realized it wasn't quite logical that I used only the colors of the 4 vertices of a quad to fill it : I mean, there must be a way to establish that pixel (x',y') of the destination quad should be of the same color as pixel (x,y) of the source quad.</p>
<p>Actually, Qt is able to transform a quad into another quad (using the QTransform class), which means it can associate each point of the destination quad to the corresponding point of the source quad. I was a bit concerned about the speed, as for each quad, I would have to make Qt compute the QTransform object (the object that describes the inverted transformation : from destination to source), and then apply it to every pixel of the destination quad, but it turned out the result was so much better than expected that I could increase the sizes of the quads a LOT and still have an accurate preview. In fact, I can apply the transformation function to only 1 pixel over 20 ! And here is how the preview looks like :</p>
<p><img src="http://lh5.ggpht.com/_KZOijM4jJGU/TFaqovf4xGI/AAAAAAAAAA8/JROVRGgosZc/s800/warp1.jpg" /></p>
<p>On my computer it IS fast and smooth :). The result you can see on the first screenshot of this post is obtained (after the user clicks "Apply") simply by applying the transformation function to every pixel, and filling the quads with the same method.</p>
<p>Now I still have to improve the UI and add the two remaining transformation functions (I only implemented affine transformation, there is still similitude and moving least squares).</p>
</div></div></div>Sun, 01 Aug 2010 23:30:24 +0000pegon4296 at https://blogs.kde.orghttps://blogs.kde.org/2010/08/01/gsoc-last-image-warping#commentsGSoC: Transformation Tool for Krita
https://blogs.kde.org/2010/07/20/gsoc-transformation-tool-krita
<div class="field field-name-taxonomy-vocabulary-2 field-type-taxonomy-term-reference field-label-above clearfix"><h3 class="field-label">KDE Project: </h3><ul class="links"><li class="taxonomy-term-reference-0"><a href="/kde-project/krita">Krita</a></li></ul></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>It's been two weeks since my last blog entry, so I thought it was time I gave an update about my work.</p>
<p>The next step was to add perspective transformation to the tool, and the least I can say is it wasn't easy.<br />
First thing is it took me some time to find the formulas and good values to create a good perspective effect, and then to obtain the same one with Qt.<br />
There are different reasons why I had to know the formulas and couldn't just rely on Qt, one of them is that the perspective transformation is not invertible, unless you know the equation of the plane in which were all the points before the perspective projection.</p>
<p>For those interested, here is the formula I used for the perspective projection :</p>
<p><img src="http://lh3.ggpht.com/_KZOijM4jJGU/TFbC04OhriI/AAAAAAAAACY/DWkRoSFA8nI/formula_1.png" /></p>
<p>where (cx, cy, cz) is the position of the camera and (ex, ey, ez) is the eye position. I took respectively (0, 0, 1024) for the camera and (0, 0, -1024) for the eye.</p>
<p>To invert the perspective transformation, I had to solve the following 3x3 system of equations :</p>
<p><img src="http://lh4.ggpht.com/_KZOijM4jJGU/TFbC0_tODUI/AAAAAAAAACc/4cLLnWUFGuA/formula_2.png" /></p>
<p>The last equation is the equation of the plane your points were before perspective projection. The parameters (a, b, c) can be found by calculating the cross product of two (non colinear) vectors of the plane.</p>
<p>For those who are interested, here is the solution :</p>
<p><img src="http://lh3.ggpht.com/_KZOijM4jJGU/TFbC0ygVQTI/AAAAAAAAACg/Ux56VDxf1R8/formula_3.png" /></p>
<p>But don't think that the work is done once I have the formulas !<br />
The thing is each time I implement a new transformation, I have to take it into account when the user manipulates the selected pixels. Let's take an example, it will be easier : when the user grabs a handle at the middle of a side of the selection, and moves the cursor, he or she expects the middle of this side to match the mouse position. That means I have to find the scale factor value for which after applying all the transformations (scaling, shearing, rotations and perspective projection), the middle of this side matches the mouse position.<br />
While the task was quite easy before, it has become much harder now that there is perspective (to keep it simple, it is because it breaks the symetry of the selection).</p>
<p>I managed to make translation, rotations, shearing and rotation center movement work correctly with perspective, but not scaling.<br />
When scaling from a side of the selection, there is only one scale factor to adjust (horizontal or vertical), so I could make it work using a dichotomic search, but when there is two scale factors to adjust (when scaling from a corner), I cannot use dichotomy anymore.<br />
I imagined different methods to tend to or approximate the two desired scale factors, but none was successful.</p>
<p>I even tried to find the exact solution with Maple, but as I expected, it couldn't solve a 4-4 nonlinear system of equations (the unknowns are the two scale factors, and the translation along X and Y axis, because the opposite corner of the one grabbed must stay at its position at click)..<br />
I think I could come up with new ideas and I would eventually find a solution, but time flies, so I decided it wasn't that bad if the corners didn't follow the mouse position, and I would go back to it later if I had some time.</p>
<p>After that, I still had to make the tool able to apply perspective transformations to the paint device. I just added a new constructor to the already existing perspective transform worker.<br />
I also added a checkbox to hide the tool decoration, a progress bar, and corrected some bugs.</p>
<p>I have already begun investigating warp transformation methods, but I am not yet ready to begin implementation. This is certainly the most exciting part of my project, but also the scariest ! ;)<br />
I'll try to give updates more often.</p>
</div></div></div>Tue, 20 Jul 2010 21:31:20 +0000pegon4288 at https://blogs.kde.orghttps://blogs.kde.org/2010/07/20/gsoc-transformation-tool-krita#commentsGSoC: Transformation Tool for Krita (screencast)
https://blogs.kde.org/2010/07/08/gsoc-transformation-tool-krita-screencast
<div class="field field-name-taxonomy-vocabulary-2 field-type-taxonomy-term-reference field-label-above clearfix"><h3 class="field-label">KDE Project: </h3><ul class="links"><li class="taxonomy-term-reference-0"><a href="/kde-project/krita">Krita</a></li></ul></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>Hello everyone !</p>
<p>Last week I finally decided to spend some time on the UI of the tool, and you will see on this <a href="http://dl.free.fr/p7Qmo5Ydt">screencast</a> that there has been some changes !</p>
<p>After correcting a small bug I introduced in the transform worker when adding shearing, I designed the Tool Options widget. I decided not to keep the mockup I made for my GSoC application, because I realized something vertical was more appropriate for Krita.<br />
In short, I added little buttons to set the rotation center to the 4 corners, the middle of the sides, and the center, and also spinboxes to display and change the current arguments of the transformation.</p>
<p>After that, I thought it was time to change the behaviour like it was discussed with the team : basically, we wanted the tool to show a low quality preview of the transformed pixels in real time, and let the user click on an "apply" button when he's satisfied with the current transformation, in order to transform eventually the selected pixels.<br />
I used QImage and QTransform classes to do that, as Boudewijn suggested. I was a bit worried that even Qt transform methods should be too slow to have something smooth, but actually, it worked just fine (as you can see on the video). That was really a relief.<br />
In the process, I broke the undo/redo actions, but I restored them just after I was finished, so everything is fine.</p>
<p>Finally, I added some useful constraints to the tool :</p>
<ul><li>Hold shift while rotating to rotate by steps of 15°.</li>
<li>Hold shift while scaling to keep aspect ratio.</li>
<li>Hold shift while moving selection to move along X or Y "global" axis only. Hold shift+ctrl to move along X or Y "object" axis only.</li>
<li>Hold shift while moving rotation center to move it along X or Y "local" axis only. Hold shift+ctrl to move it along X or Y "global" axis only.</li>
</ul><p>I made the handles a little bit bigger because they weren't easy to catch.<br />
I decided to make a <a href="http://dl.free.fr/p7Qmo5Ydt">screencast</a> because people on the team had some trouble finding where to click to do this or that with the tool.</p>
<p><img src="http://lh5.ggpht.com/_KZOijM4jJGU/TFbC1BhWaeI/AAAAAAAAACk/Lgi3ivBn2GQ/s640/krita_screenshot.png" align="middle" /></p>
</div></div></div>Thu, 08 Jul 2010 02:55:10 +0000pegon4271 at https://blogs.kde.orghttps://blogs.kde.org/2010/07/08/gsoc-transformation-tool-krita-screencast#commentsGSoC: Transformation Tool for Krita
https://blogs.kde.org/2010/06/30/gsoc-transformation-tool-krita
<div class="field field-name-taxonomy-vocabulary-2 field-type-taxonomy-term-reference field-label-above clearfix"><h3 class="field-label">KDE Project: </h3><ul class="links"><li class="taxonomy-term-reference-0"><a href="/kde-project/krita">Krita</a></li></ul></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>Hi guys,</p>
<p>Maybe it's a bit late to talk about what I did last week, but anyway : </p>
<p>After fixing some bugs in the transformation tool, I decided to add the possibility for the user to change the center of rotation.<br />
It was a bit tricky, because I wanted to express this rotation (around the current center) as a composition of a rotation around the original center of the selection and a translation (which is possible). Consequently, a succession of rotations around different center can be reduced to only 1 rotation around the original center and 1 translation.<br />
I used complex numbers for the calculation (quite convenient for 2D transformations), and I was pleased to see that complex numbers were standard C++ objects.</p>
<p>After that, I decided to implement horizontal and vertical shearing. When doing some researches, I found out that such transformations weren't commutative, so I had to make a choice : horizontal shearing is applied before vertical shearing. Thus, even though it may appear a little bit strange, shearing vertically when there is already a horizontal shearing changes the angle of the left/right sides of the parallelogram.<br />
I compared it to gimp, and I noticed that it refuses to compose horizontal and vertical shearing : if you want to do both, you have to shear horizontally using the shear Tool, then close it, reopen it, and shear vertically (which produces the same result as our transform tool). That means what I do is normal.<br />
I also found out that in the Transform Worker (the class which applies the transformation to the selected pixels), shearing wasn't implemented ! It wasn't expected, because it takes shear factors in argument, and there is no mention of it in the code.<br />
Fortunately, the worker was essentially capable of shearing with just a few modifications, because it used shearing to perform rotations (rotations can be done efficiently with 3 particular shearings).</p>
<p>Then I did some code cleaning / restructurations.<br />
I also prepared everything for perspective transformation (added a 3rd coordinate, 3D rotations, perspective projection calculation), which will be added later. In fact, while there is no ambiguity on how to perform 3D rotations, there are different ways to do perspective projections, and I want to see how Qt does it first (with QMatrix4x4), because the idea is eventually to use QImage and Qt transformations to display a preview of the transformed selection.</p>
<p>That's it for last week !</p>
</div></div></div>Wed, 30 Jun 2010 10:23:55 +0000pegon4263 at https://blogs.kde.orghttps://blogs.kde.org/2010/06/30/gsoc-transformation-tool-krita#commentsGSoC: Transformation Tool for Krita
https://blogs.kde.org/2010/06/21/gsoc-transformation-tool-krita
<div class="field field-name-taxonomy-vocabulary-2 field-type-taxonomy-term-reference field-label-above clearfix"><h3 class="field-label">KDE Project: </h3><ul class="links"><li class="taxonomy-term-reference-0"><a href="/kde-project/krita">Krita</a></li></ul></div><div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>This is my first blog entry about my <a href="http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/kde/t127230762010">GSoC project</a> for Krita. <br /></p>
<p>Because i was busy doing a school project until June 11, i actually began working on the transformation tool last week. <br /><br />
The aim was to rewrite most parts of the old transformation tools, in order to continue the project on a solid base, and with my own code, to make the job easier. I also wanted to make the tool perform transformations in real time, not just when the user releases the mouse button. <br /></p>
<p>What has been done :</p>
<ul><li>The computation of the scale factors/rotation angle/translation vector from the mouse movement has been rewritten.
</li><li>The tool now updates the canvas properly after each transformations, so there are no more artefacts visible.
</li><li>I added a temporary workaround to move the selection, because the move method for KisPaintDevice is apparently deprecated.
</li><li>The undo/redo commands have been fixed, using the new system written by dmitryK last week (though it isn't working completely, because of a reported bug in KisDoc2 + QUndoStack)
</li></ul><p>I spent a few days trying to perform the transformations in real time. I wanted to see if indirect painting could help me do that, but i couldn't even manage to move a selection without blitting a rectangles, so I decided i'd better go on with the project for now and give it another try later.</p>
<p>That's it for now ! I hope to be more productive this week, with real new features implemented.</p>
</div></div></div>Mon, 21 Jun 2010 12:50:04 +0000pegon4248 at https://blogs.kde.orghttps://blogs.kde.org/2010/06/21/gsoc-transformation-tool-krita#comments