wolthera - Tumblr blog

[wolthera]

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

More comics management: making proper ACBF files.

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.

[wolthera]

Ah man, completely forgot my blog is set to crosspost to tumblr O_O

Sorry.

[wolthera]

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

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.

EDIT: SNIPPED A LOT OF THAT, THAT WAS 4.5 K WORDS, AND WAAAAAY TOO MUCH FOR TUMBLR! SORRRY O_O

[wolthera]

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.

After all this is done, I’ll be working on a good core colour selector for Krita, that we can use for filters, but I am satisfied with the progress up till now.

[wolthera]

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

Entry for June's Monthly Drawing challenge: Flow

Didn’t get anywhere with my GSoC code today, so decided to start do some painting and doing the drawing challenge. Had some fun

[wolthera]

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.

Overal, I suspect that I’ll need to do proper testing of each method, and maybe search a bit further.

[wolthera]

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

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.

It has quite a few features, so check out the readme at github.

[wolthera]

I think the thing here though is timing? They are kinda in the middle of a war... Also, why does the resident wordsmith have to slap people to get her point across? How about she starts to talk normally to him, like a normal human being, and starts off with just expressing how lonely she was? Because she hasn't even done that yet. And you might argue that this is because she felt a lot of things during that year and hasn't sorted through them yet, but I am not sure why that immidiately requires physical violence from a character that isn't all that inclined to do so.

(Personally, I suspect Natsu's gonna apologise for leaving when it turned out to be such a bust instead of a garantuee of a relatively peaceful future with only acnologia to deal with. He is a fairly moral person, and the primary way for him to justify Lucy being upset must've been to succeed. It's probably part of why he didn't want to lessen his resolve, because he now has to face Lucy and tell her he made a huge mistake and nothing good came out of it.)

Not a fan of how all of you want Lucy to smack Natsu. Natsu’s just went through a pretty traumatic experience… Idk, maybe you’re projecting your feelings onto Lucy? I just don’t think now is a good time for them to discuss anything besides what’s happening right now.

[wolthera]

Notice also that Lucy didn't pick a side in the Gray and Erza argument(trust him or not), but focused on seperating the two.

My guess is that she'll focus on Happy and Natsu being alive, and not dead as one would expect after an encounter of that type. Especially with the suicide thing, because if it had been Midnight or someone like that saying this, Natsu would've been fully right to assume it was bullshit. Lucy's sensible enough to know that.

(Crackfic idea: Lucy is so happy they're alive that she continues to dote on them for a few hours, making Natsu uncomfortable and wish she was pissed and giving Cana gildarts-flashbacks ;) ) (Though, probably, even though Lucy wouldn't be pissed at Natsu, Natsu in an angsty mood would probably be in a pretty destructive mood and want someone to be angry at him, perhaps the nalu shippers are projecting what Natsu wishes than what Lucy truly does, in a similar way to how everyone assumes Natsu is like how Gray says he is, even though Gray calls everyone a dumbass.)

Not a fan of how all of you want Lucy to smack Natsu. Natsu’s just went through a pretty traumatic experience… Idk, maybe you’re projecting your feelings onto Lucy? I just don’t think now is a good time for them to discuss anything besides what’s happening right now.

[wolthera]

I have no idea what post you're talking about, I am just scanning the tag, but yeah Natsu's pretty damn reserved when it comes to Lucy's body. He doesn't even climb into her bed as much as the fandom would like to pretend. Really, the only two things I can think of is the aftermath of the flying Lucy incident and the rabbit suit, and the latter was not sexual.

And we do know he realises she's a looker because of the blond maid thing as well as getting her to try and seduce an enemy back in the Edolas arc, but at the same time he refuses Ashley's offer to strip naked, so it must be a respect thing instead of him being too immature to know what his penis is for.

Cana, Erza, Mira, Tauros, Marakov and distantly Gajeel, can't say the same thing.

Damn, I wanted to like that post, but then they mentioned something about Natsu sexual assaulting Lucy several times and I just kind of rolled my eyes.

All but one of those inappropriate grabs have been accidental, and the one that was on purpose he got smacked for.

You know who else we can say sexually assaulted Lucy? Cana. Cana has grabbed Lucy without permission more times than any other character, yet I never see people complaining about that!

[wolthera]

*male artist voice* this is my new project, it’s like, the dark side of Disney princesses. so like, Alice is on drugs, belle has Stockholm syndrome, jasmine is a terrorist and sleeping beauty is getting plastic surgery. it’s super cutting edge as you can see

[wolthera]

My Google Summer of Code Project is in! Woohoo!

With over 150 bugs fixed! Check the release notes for the full list!

If you have resource bundles installed, Krita may say something about md5sum mismatch. Don’t worry, this should only happen once, and it means that Krita is updating old faulty bundles to have proper md5sums, which are special strings that allow Krita to check if the resources aren’t accidentally corrupted. 

Also, we’re doing a friendly contest to determine which version of Kiki, our cyber-squirrel mascot, gets to go onto the Kickstarter Reward t-shirts! https://forum.kde.org/viewtopic.php?f=277&t=128083

[wolthera]

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.

I will sent a mail to the LCMS mailing list because I want to give better feedback on non-RGB color spaces, but one of their functions is confusing me.

[wolthera]

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

Some faces in Krita

Did some face-studies for character designs in Krita past week as a way to relax. I can´t stop detailing the woman, so I am posting now to stop myself.

[wolthera]

I passed my year.

:D :D :D :D :D :D :D

[wolthera]

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.

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.

[wolthera]

Bit of an update: Still alive, might pass this year, was accepted for google summer of code, saw age of ultron:it was fon, very busy with ooen source painting programs. Will return in summerish. Procrastinating on madam bouvary right now.