Woltumble

More comics management: making proper ACBF files.

Writing a comics manager for Krita

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.

Crossposted from http://wolthera.info/?p=802

GSoC 2016: Soft proofing, Gamut alarms and looks update.

So, after living on Boudewijn and Irina’s pantry for a week, we now have Soft Proofing working:

Partially, this week was spent on me recuperating from my exam-week and the Krita Kickstarter. After that, delving into the jungle that is Pigment, which is Krita’s colour management library, for abstracting the caching and handling of colour managed colours. It’s a bit of a jungle of templates and class inheritance. This part is where living at my mentor for a week was helpful, as communicating some of the problems I bumped into(mostly confusing class names and how to avoid having to rewrite the caching graph), would’ve been too difficult to do over IRC.

The second part was setting the toggles via the canvas, taking data from the image and the view and giving that to the openGL textures, as well as caching the transform in pigment.

We can now softproof to a single cmyk colour space, and the softproofing can be done per view, meaning that you can have two views of the same image open, one set to do softproofing. The idea behind this is that softproofing isn’t a destructive transform, when you are modifying your image to look good in the softproof,you are editing the original. So I figured it would be nice to get the softproof working in a separate view, so you can see how the modifications you make influence both images.

Gamut alarms work as well, what is missing is setting the configuration, and saving/loading the configuration from the image file. This latter is important because if you are a professional illustrator, it might be that you need to juggle several projects with several CMYK profiles associated. Rather than to force the user to save the icc profile they optimised the image for right next to the file, so that they may remember which profile they optimised to, it might be better to just save the profile and the whole configuration.

On Thursday, I was running into architecture trouble, and as Boudewijn was away, I decided to do something different: Implement OCIO looks.

OCIO looks are what colour management people call ‘aesthetic transforms’. In other words: They’re a manipulation of the image that serves to make it prettier! In my case, I wanted to use it to see if I could get colour blindness filters to work via it. At the same time, this feature can be used by people who have a custom OCIO config, where such transforms can be stored. The modified advanced colour selector here is a freebie we get from the earlier work to have them be manipulated by OCIO for Scene-reffered/HDR colour picking. But again, we can have the filter happen in a different view than the original.

I am not 100% sure about the implementation, as the OCIO api docs are very confusing about how to use looks, so this right now uses ‘overrides’ but I am not sure if using something called ‘overrides’ that is remarked on being a ‘fallback’ is the right way to go.

Similarly, I will need to still decipher those papers I looked at, and find a good way to redistribute the OCIO config, as Krita has no default one by itself.

Crossposted from http://wolthera.info/?p=797

Entry for June's Monthly Drawing challenge: Flow

Crossposted from http://wolthera.info/?p=790

Pre-GSoC work: Researching color deficiencies.

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.

Now, aside from LCMS’s display transform, we also have a lot of features through color management via OCIO. For example, you can preview an image’s relative luminosity in a seperate view as you work on it:

This is quite useful for artists, as it serves as a diagnosis tool. And ideally, I’d like to see softproofing done in a similar, per view, manner, so that the artist can tweak the original and see the changes in a softproofed view on the fly. However, the LCMS api’s softproofing is a one-single-function for everything deal, you give it an input(image) profile, the profile to softproof to, and an output (screen profile), and perhaps a warning colour.

Typically, we’d just replace our regular display transform with the softproofing one, but then we can’t have it per view. So what we might be doing instead, is to give it the same profile into the input and output, and keep the display transform seperated. That would mean it is theoretically slower, but if it means that we can have the softproofing per view, it’d be more userfriendly.

For the colour blindness simulation, similar considerations can be made. When we think of adding this, the first question is why? The answer is the same: ‘diagnostic tool’. As a designer and/or production artist you might be in the luxury of having full colour vision, yet at the same time, you want to make sure your designs are still functional for people with any form of colour blindness. And while we can try to imagine that for some people red and green look exactly alike, it’s far more helpful to simulate it and do precision work for such vision. So, you end up with a tool that is somehow there to increase empathy.

With that in mind, the following requirements:

It has to be non-destructive. The original image needs to be shown as if seen by a colour blind person, but not actually transformed and saved as.

It does not have to be 100% truthful, as it is there to create empathy and to diagnose weaknesses in a design.

There should be a variety of them, as there’s not a single colour blindness, but a number of different behaving deficiencies.

With that in mind, my first instinct is to make use of OCIO looks. These are aesthetic colour transforms in the form of LUTs that can be added into the regular colour management chain. The advantages of this are:

We don’t have to do extra architectural work. No need to make LCMS do anything it wasn’t meant to do, for example.

We have to support Looks, which was already a missing feature.

Looks are an aesthetic transform upon a regular transform, which makes the transformation colourspace independant.

With looks support, people can start using other config’s looks.

When we make LUTs, these can then be used by others.

The downsides are:

We’ll have to support looks.

We’ll have to ship a config(which we weren’t doing yet) and communicate to people how to use it.

We are tied to doing LUTs.

That last disadvantage is a peculiar one, and it directly touches upon how we decide to simulate our colour blindness. So this goes back into research, with the question of ‘what would be the right type of transforms’?

There’s several existing implementations.

GTK programs like Gimp and Inkscape(I think Inkscape has it…?) have their colour blindness thingy based on the Vienot, Brettel, Molon  paper from 1998.

Here, the requirement is to first convert RGB to LMS, and then modify the values in the LMS model to simulate the colour blindness chosen, and then convert back to RGB. Furthermore, a lot of decisions seem to have been made based on the input RGB being regular consumer screen sRGB.

So it’s highly questionable whether we can get a single LUT out of the observations of this paper, and whether the results would be fairly agnostic.

The second popular method is one used in all javascript implementations and other open source implementations, and they all seem to be based on Matthew Wickline’s formulas… who doesn’t mention where he got his data from?

Regardless, the result is simple RGB matrices, which could be easily converted to a LUT.

Finally, there’s this little plugin on the GIMP registery, which is based on the Machado, Oliveira, Fernandes paper of 2009. The paper again mentions converting to LMS, but the plugin has managed to simplify this to a set of RGB matrices. The weakness overal here is how sophisticated it is, with a sliding scale of colour blindness strength. Furthermore, the license of the plugin is something I need to stare hard at.

Little update

So, I did two important things recently.

First, I posted my 101 sketches I made with Krita since I started working on it. I made a google+ album out of it, because I didn’t think this server could hanle 101 sketches easily.

Secondly, I formally open sourced my little SVG comic reader with GPL 3.0 (which I think is sensible for a web-application.) You can find it on github here: https://github.com/therahedwig/SVG-comic-reader

I actually made it 2.5 years ago, but I never formally open sourced it, more forgot about it, actually. When at the Krita sprint, Boudewijn remarked he really disliked  the way how webcomics present themselves, I remembered it again and show it to him and Timothée Giet. Timothée, as a comics creator was interested in using it, and I finally took the step to open source it.

Crossposted from http://wolthera.info/?p=783

(GSoC 2015) Merged in color space picking GUI.

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.

Colour Management in Krita is pretty central. You cannot have an unmanaged image in Krita, it automatically attaches a colourspace to it, much to the annoyance of many people who attempt to use Krita as a photo-manipulation type of software instead of a drawing software, which it explicitly is, but I digress.

Krita’s old widget for picking a colourspace was a set of comboboxes, allowing you to pick model, bit depth and profile, which has served well for many years. However Artists often have no clue what profiles and color spaces are, so the widget was a little mystifying to them(to the point we had several requests to get rid of that widget, because it was obviously only for minor corner cases).

On the code side, having a new widget was actually pretty beneficial as well. Krita uses LCMS to deal with ICC profiles, but while it could retrieve a transform, and a name, it couldn’t retrieve information like the whitepoint and colorants. The latter of these is actually quite useful for filters and determining the luminance of a colour, which in turn helps with making powerful colour adjustment filters. And the best way to test if you’ve retrieved that kind of data correctly is by making a widget that gives you more information.

With that in mind, the following widget was made:

The center widget was ported from DigiKam. This widget allows people to see where the white point is on the CIE xy visible color diagram, as well, if available, how the red, green and blue of RGB profiles map onto it. My primary contribution to this was removing the lcms code from the widget and make it more general(as we would be retrieving the data via pigment) and generally making the widget a little bit more readable by adding some extra ellipses, darkening some colors, etc. I want to extend it further in the future.

To the left is an improved version of our old widget. The profile combox got turned into a list, because this is a little easier to read for a lot of files, especially ones that are similarly named like ours are due to Elle Stone’s profiles we ship. Profiles are also alphabetised and the default profile is now marked with a ‘(Default)’.

The Profile Properties box gives the raw info that was retrieved. Now, currently it only gives an Estimated Gamma, which is an LCMS function, but apparantly LCMS can’t discern between sRGBtrc, L*trc and rec 709 trc. These are all pretty alike, so I can’t blame it, but the subtle difference can mean a lot to someone who care about the numbers. I want to replace it with a tone response curve widget, though it may proove equally difficult to do right…

Getting the right whitepoint and colorants was actually tricky. Turns out that newer versions of LCMS support V4 profiles, which don’t store the actual whitepoint, but instead store the d50 whitepoint, and then store a chromatic adaption matrix that adapts from the actual whitepoint to D50. So to get the actual white point, you need get chromatic adaption matrix, invert it, and multiply it with the whitepoint stored in a matrix. This little detour in makes our resultant XYZ coordinates have rounding errors, which, while minor, are annoying, and I sort of agree with the LCMS people that the V4 specs are kinda obnoxious. As I never had matrices in school, I emailed back and forth with Elle for a bit.

I made a little function that tries to find the name of the whitepoint based on the xyY coordinates. It’s not perfect, especially because of those rounding errors mentioned earlier, but it should give a much better readable result. In the worst case hovering over the whitepoint gives a tooltip with the xyY coordinates.

The text-box below gives information on the profile if available. So the name, but information on the color model, general information on the bitdepth, and notes from Elle if available. This is a bit of a weight on the translators so I tried to give as many translation comments as possible.

The first reaction to this widget was ‘this is awesome’, and then there were a couple ‘this is a wall of text, no one is going to read that’, but I don’t think they were getting the point.

Anyway, it’s merged, so the next version of Krita will have this GUI. Hope it’ll be of use.

Crossposted from http://wolthera.info/?p=778

Some faces in Krita

Crossposted from http://wolthera.info/?p=770

Tangent Normal Brush GSoC interim post

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:

Krita’s canvas navigation includes rotation and mirroring, which messes up my vectors. I have this half-solved, but I would like it to work with multibrush if possible.

The tangent normal brush itself needs some cleanup.

I need to add more features to the tangent normal brush engine, like flow, sharpness etc. This shouldn’t be complex.

Tilt cursor could be more visible.

I still need to look at the colour cursor.

I wanted to have an encoding preview in the brush settings.

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.