Krita 4.1’s comic project management tools now support 90% of all ACBF features.
Missing are still: Transparent(text-area), Text-rotation, Jump, and Anchor.
Best of all, I managed to get most of the values understood semi automatically.
Krita 4.1’s comic project management tools now support 90% of all ACBF features.
Missing are still: Transparent(text-area), Text-rotation, Jump, and Anchor.
Best of all, I managed to get most of the values understood semi automatically.
Those who know me, or at the least know my history with Krita is that one of the prime things I personally want to use Krita for is making comics. So back in the day one of the things I did was make a big forum post discussing the different parts of making a comic and how different software solves it.
One of the things about making a comic is that is a project. Meaning, it is big and unwieldy, with multiple files and multiple disciplines. You need to be able to write, to draw, to ink, to color. And you need to be able to do this consistently.
The big thing I was missing in Krita was the ability to quickly get to my selection of pages. In real life, I can lay down pages next to one another, and always have them in my minds eye. In Krita, getting the next or previous page is always a matter of digging through folders and finding the correct page number.
Adding to this, I am also a bit of a perfectionist, so I have been training myself to start drawing scenes or writing as soon as I have an idea, because any idea is way more useful when you’ve got it down on page. You can append it to an existing story, or just work it in and reuse the drawings and compositions. And this was also a bit difficult to do, because how does one organise and tag those ideas?
So hence I spend the last few weeks on writing a comics manager for Krita.
So, while the 2016 Google Summer of Code hasn’t officially started yet, and Krita’s master is in feature freeze till the release at the end of the month, it’s a good moment to start preparing.
My area of specialisation within Krita is Colour Management, and my project is focusing on softproofing. This area is one that isn’t difficult in regards mastering intricate c++ methods, but rather an area that focuses on research. In other words, figuring out what is actually true.
It’s not quite certain why there is so much misinformation out there, a simple suggestion would be to say that perhaps a lot of colour management UI is just too byzantine to understand. But on the other hand, Western Society in general has had no single Colour Theory survive longer than a century until a new one showed up. So perhaps there’s just something about colour, and especially about how relative human vision is, that makes it difficult to capture in a single coherent theory, and most artists just develop a sense for color than a cohesive method.
My focus is on the softproofing, a sort of on-the-fly filter to emulate how an image will look when being printed(and more importantly, which details could get lost). I already researched this back in February, LCMS’s API will allow for it easily, and I now mostly need to sit down with Boudewijn to stare at Krita’s architecture to decide what is possible before deciding upon a UI and implementation.
However, in a discussion on IRC it was mentioned that it’d be nice if we could emulate not just cmyk profiles, but also things like colour blindess.
So, after the Tangent Normal Brush was merged, Krita didn’t have any new releases because it was decided to do some major bugfixing. Which in turn means I haven’t had any bugreports yet.
That meant that for the rest of my GSoC, I instead worked on a secondary project: An improved GUI/Widget for picking profiles in Krita, which I merged today.
So, as the saying goes finishing something up to 90% takes as much time as the last 10%.
Anyway, important things first:
(embed to https://www.youtube.com/embed/qiX60EWyMF8)
So, I actually was supossed to start blogging on the first day of gsoc, but I was in the middle of exams and when doing exams adding your blog to kde planet’s blogfeed seems a task akin to reinstalling your computer.
Anyway, I am here now, let’s talk my GSoC.
Basically, it’s a brush that allows you to draw so-called ‘normal maps’, which are colourful looking maps that are actually encoding 3d vectors in the r, g and b channels of an rgb image. These 3d vectors are then used by a 3d program to pretend there’s little variations in the surface.
Thing is, because it’s encoded into the rgb values we can edit it in a image editing program like Krita. And advanced tablets have tilt-sensors, which means you can make a stylus tilt resemble a normal vector, and thus output the right colours. Hence, the tangent normal brush engine.
So how far am I? Feature wise, almost done.
Above you can see the normal map that is drawn with the tangent normal brush. You can tell it to use your tilt, rotation, or even drawing angle to determine the direction the output vector is in. Then, you can choose the type of encoding that is used for the normal map. This means whether you put the Y value of the vector in the green channel or red channel, whether it’s positive or negative, etc, and you can modify the strength of the stylus elevation on the resulting values, so you can choose to more easily have the neutral vector value.
I made a tilt cursor which can give feedback on stylus tilt, because that’s rather hard to determine for the user when they use a tablet, and wanted to make a color cursor, but this latter was recommended by boud to be put on hold indefinitely, because the code involved is rather complex.
Finally, I made the phong bumpmap filter that already existed, accept normalmaps. This filter then can convert the normal map to lighting information the way a 3d program would. Such as the image on the lower-left. This can be done via a filter layer or mask in Krita, so that the user can paint the normal map and get real-time lighting feedback.
The image on the lower-right is said layer set to overlay over the original texture, allowing me to match the shading. Then, the final image on the upper-right is the two textures on a plane in blender, assigned as diffuse for the regular texture, and ‘tangent’ normal for the normal map.
There’s still plenty of niggles left to be done:
The reason I am this far already is due to me starting once I heard I was accepted, partially because this period is exam and resit week, and I wanted to have a buffer if this period turned out to be too time-consuming for me.
If I properly finish this project, I’ll be working on bugs, colour management and the painting assistants of Krita, which were subjects I did before GSoC as well.
Scott Petrovic | very nice progress so far Wolthera! You never cease to impress me. |
Wolthera | Thanks! |
Ryan Leach | I’d love to see this being edited live on a VR headset. |
Wolthera | Normal maps aren’t really 3d themselves though, so it would be just as boring 🙂 |
Bartosz Styperek | Could you add feature to convert normal map to cavity map? Here in example in PS http://www.bs3d.com/index.php?page=7 . It is great in overlay mode on diffuse texture. Also I supose people may want to overlay details on normal map. Here it is explained http://gamebanana.com/tuts/10595 how to do it in ok way. No perfect but ok. Maybe you could add something like overlayNormal blending mode? And last thing – when people overlay normals (with overlay blending mode) on top of each other result is not normalized. So my final request would be addition on ‘normalize normals’ function. |
Wolthera | I have no clue how to do the first part at all, so it’s not going to happen and the second part is done in the master branch, it’s called tangent normal. |
So, in the past few weeks, I spent some time hacking a new feature into Krita that I had wanted for a long time, and this monday I actually commited it. So, I figured it be best to make a little post about the new functionality.