The goal is to find out how Krita fits into a Visual FX pipeline.

I hope for this to be an open exchange between those in the Krita/KDE community and myself.

Thanks in advance...

My primary function at work is the shading/texturing of digital assets. This is where my interest of Krita comes into play. We have a full linux pipeline with macs on the side to run Photoshop. Since Adobe is not going to release a linux version anytime soon it would be great to have a production worthy linux alternative.

Over the next bit I will attempt to describe the normal day to day use/functions/requirements of the work involved. From there try to relate that to Krita and where it fits and does not.

The main tasks of texturing breakdown to: (in order of importance)

1. Image Manipulation
2. Colour Correction
3. Layering
4. Painting(which connects to all previous 3)



Image Manipulation:
-Getting the colour information to fit within the required uv space. There for making it the most basic and important of all the tool sets used.

Colour Correction
-Correcting the colour information so it fits the required use or look that needs to be achieved.

Layering
-The ability to take multiple sets of colour information and use them in a way to achieve a more complex image/element through creative blending and mixing.

Painting
-Involved in the final aspects of blending, look, and control on a per pixel basis.



From here I would like to take time to explore each of those main tasks in more detail... till then cheers.

Before I continue elaborating...lets set the stage for scope of what we are dealing with. Aka the texture file.

The resolution of the texture will vary from 4k (4096x4096) to 8k. Under certain circumstances we will push it to 10k. ie hero objects and uv layouts that don't yield the required detail.

For speed sake working at 8 bit is a guilty pleasure. However if the displacement maps require more detail/smoother gradation or there are subtle colour corrects that start cranking in weird ways the file will be pushed to 16 bit. If 16 bit did not increase save times so much and there was less of a performance hit it would be preferred to work in 16 bit all of the time. There are occasions where 32 bit is needed especially for night time backgrounds that are constant shaded and need lights to streak properly with motion blur.


The texture file itself will usually be organized with nesting folders that contain each aspect relating to the channels being mapped out. At the very least Diffuse/Colour, Specular/Reflection, and Displacement/Bump. If it was a worst case scenario add to that, Roughness/Reflection Blur, Opacity, Facing Min, Specular Tint/Reflection Tint, and heaven forbid SSS. That does not even include the reference used to work from, the mattes that need to be painted for the compositors or even uv guides.


To put it lightly it can get complicated and big fast. File sizes range from 300 megs to 9 gigs. I have to commend OSX and Adobe on Photoshop CS3 for handling such large files and crashing rarely.


The main thing I am trying to stress from all of that is the ability to organize content within the texture file, the requirement to juggle large amounts of data and the absolute need for stability especially when saving files.

Cio 4 now!

1. Image Manipulation
What features do you need ? Or what exactly do you mean by that ?

2. Colour Correction
I think we have a good cover of color correction filters, if you see something missing, do not hesitate to fill http://bugs.kde.org

3. Layering


4. Painting(which connects to all previous 3)
That the area we are going to try to make krita excel.

Big images: it is two challenges, memory wise, and computational wise. When it comes to memory, we are working under the assumption that people who need such image size will go and buy the memory they need to accomplish that task (after all there are systems with 96GB of ram nowdays which is more than my laptop harddrive :/ ) That said, 10000x10000 in 8bit, is 400MB of memory (for a full layer), just for the layer, it is not that much, but after you add a bit of overhead, an other layer, undo operation, it grow. And of course there is the challenge of the CPU use, and we are working on that.

In the end, I had say, try Krita 2.2 when it is out (or even now from svn it is going to be much better than 2.1), and report to http://bugs.kde.org or come to disscuss with us either here or on IRC (#krita on freenode.net) to see if the features you need fit our vision, I think it should, what you describe seems to be very close to what we have in our vision.

The systems we use are 8 core intel macs with 4 gigs of ram. The linux are dells with the same specs pretty much. Photoshop CS3 on OSX 10.5.8 somehow juggles more data than they have ram and do it well.

I'll probably try Krita 2.2 out when lucid is released as it seems like kde 4.4 with qt 4.6 is required to run it. Unless there is an easy way to run it on karmic that I don't know about?



So now I will take some time and elaborate about each major aspect of the texture creation.

Image Manipulation:

It is a simple dilemma. You have useful colour information or element but need to transform, distort and mash it into place.

In Photoshop the transform tool with all the options are employed. So free transform, rotate, scale, distort, skew and warp are all used and together in the same run. This is good because the more times the transform tool is used, the more filtering occurs and increases the degradation of the element. One major thing that is very useful is the ability to use a key modifier to constrain the editing of the transforms handles. ie shift + modify distort corner lets it move only in a straight line along the x axis if that is the first way you drag it. The lattice like warp option is very useful. If only Photoshop would let you choose how many lattice devisions you want then it would be perfect (hint hint )

The final tool that is used especially on organic elements where there is bound to be the presence of some uv distortion is the liquefy tool that lets you distort the image by pushing and pulling on the surface like it is tangible putty. The need to use it has degraded since the warp option came to in the transform tool but there are situations where there is no other way but to liquefy.


One comment is that due to gimps **** way of dealing with transformations separately automatically disqualifies it. All transform options need to be part of the same tool so you can switch between modes to massage the element into place in one operation. Which in Krita 2.1 seems like you already going that way.


On that note I am off to bed and will continue hopefully sooner than later!

For this year's google summer of code, one of the ideas is to develop a new transform tool. If a student picks this idea and we get a slot for him, would you be interested in being a sparring partner for the student and the mentor?

It is the least that I could do! Let me know when and where.

I have been examining Krita 2.1 and it seems that for the most part the things that are required for Colour Correcting, and Layering are there in some shape or form. I am still poking at the painting/brushes...

At the current state of 2.1 I would have a lot to comment on overall ui and workflow let alone that it is unusable in that it crashes at every corner I turn. Though it seems pointless to criticize when I'm sure a lot has been spruced up and changed in the newer 2.2 version.


The only one cc tool missing that is very useful in photoshop is the colour match tool. It can get good results fast if you feed it proper elements and can achieve complex shifts that would normally take much effort to do manually sometimes(other times its useless lol).

I think the "color transfer" filter is what you want, but it seems to be crashing in both 2.1 and 2.2. As for stability and performance, there are major improvements in 2.2 compared to 2.1.