Krita/ActionPlan2

From KDE Community Wiki
27 akademy: 1 day: writing down issues with abr (we postpone implementation) Windows!
28: check and fix performance with big scaled-down predefined brushes like deevad's
29: custom brush creation
30:  PaintOps that copy pixels are not aware of pixel transparency http://bugs.kde.org/show_bug.cgi?id=217124
21: 1w Refactor brush selection widget so that particle type can be selected with current GUI
32, 33: session management for tools, colors, etc.
34, 35: release readiness


June

  • Week 24: ABR Brush support, we have unfinished business here.

Steps:

    • 1. create separate paintop that mimics Photoshop and the parsed dynamic values
    • 2. implement abr loading of the dynamics into paintop
    • 3. possibly merge with autobrush


  • Week 25 ABR Brush suppert+ (one week is not enough), VBR brush support

(it seems easy, text file with GIMP settings just to match our Autobrush)

  • Week 26 Create workflow for quick creation of brushes from the image

in canvas (here are the specs http://docs.gimp.org/en/gimp-using-variable-size-brush-creating.html) + enki said it looks really good + maybe just need to fix the Custom brush dialog

July

  • Week 27 Refactor brush selection widget so that particle type can be

selected with current GUI

management. Save the state of the brush engines into kra. Some elaboration on related settings will be done (e.g. tools should be saved too, e.g. opacity and composition mode of freehand tool)

August

  • Week 31 Week of filter's performance, cache the calls of

transformation https://bugs.kde.org/show_bug.cgi?id=233004, profile filters and try to optimize some of them so that they are usable for painting

  • Week 32: Spent one week to setup Windows development for Krita, document it on wiki extensively so that it is easy for other hackers, and fix compilation errors for Windows
  • Week 33, 34, 35: release readiness: A Bug A Day Keeps the Doctor Away (or

something like that -- we'd need to carefully preselect the bugs if we want to do that! Many bugs will take more than a day.)

Related links

Discussion points

Boud

  • gradient improvement might be a nice task for one week
  • dockers from enki mail?
  • asking Peter to help with the design, since I'm totally uncertain what would be best here (week 30)
  • not sure about the importance of this item (week 26)

Photoshop brush support in Krita

Photoshop brushes are saved in binary format abr. There is no open specification that can be used in open-source project to implement this support. Reverse engineering is used to get the specification and code.

Brush masks

There is support for brush masks saved in abr files. GIMP, Krita and some code in plasma is using code from Eric Lamarque which skips unknown data in abr and decode only bitmaps. This was already implement as part of the Action Plan I.

Brush engine presets

There are many attributes in abr format that describe the behaviour of the brush mask (scaling, rotation, displacement, etc.) We can map some of them to current status of the brush engines.

Current code is consisting of 2 layers. First layer is the parser. The parser is port of Valek Filippov work. He did the reverse engineering. I did some changes to control layer 2.

Layer 2 is translator, it is responsible for translating the abr attributes with their values into our presets. It groups related attributes into groups. E.g. brush mask attributes (diameter, roundness) are separated from dynamics attributes like dynamic size controlled by pressure or fade. Sometimes the order of attributes is not in logic order, so some context parsing has to be done.

What is done

Here is the specs http://gitorious.org/re-lab/graphics/blobs/master/photoshop/abr/abr-spec.htm

Brush attributes

Attribute | Mapped |
Diameter | In the GUI diameter again. Mapped to mask generators radius.|
Flip X | not yet - Mirror feature is so far only dynamics in Pixel Brush, we miss static version|
Flip Y | same as Flip X |
Angle | Mapped to mask generator so far. It has to work also with preddefined brush masks |
Roundness | Mapped to aspect ratio, we don't have support for this in preddefined brush masks |
Hardness | V/H Fade |
Spacing | Mapped to spacing. Can be disabled, we can't disable TODO: find out what happens in PS |
Intr | Not found what it is intended for. Work with parser supplier needed here (Prokoudine, frob)|
sampledData | not parsed yet , contain the bitmap, but since we have two parsers (bitmap only, presets), some work regarding mapping the data to preset has to be done. Merge the parsers? |

Shape Dynamics

useTipDynamics | Checkbox that enables the dynamics, not mapped yet, our dynamics are scattered over few checkboxes |
Flip X | dynamics version, not mapped but mirror feature was done just lately |
Flip Y | same as Flip X ^ |
Size control | We haven't found the entry that stores information on a chosen control yet. What is known is that there are the controllers for size (pressure, tilt, fade,..see specs)|
Minimum Diameter | can be mapped in the size sensor curve, not done yet |
Tilt Scale | Takes values from 0% to 200%. Is available with Pen Tilt control only. Not mapped yet | 
Fade Step | not mapped, fade sensor needed, used for size, angle, roundness. The sensor is similar to distance, but I'm not sure. |
Size Jitter | random size in interval, we need Fuzzy sensor to be stacked with other sensor for this, in general stack of sensors is needed|
Angle Control | Direction, Initial Direction is missing in our sensors, we have only drawing angle which is probably direction |
Angle Jitter | Rotation sensor with fuzzy, again stack of the sensors required |
Roundness control | Not mapped yet, Roundness sensor has to be implemented (controls vertical / horizontal fade)
Minimum Roundness | Mapped to the curve of the fuzzy roundness sensor |
Roundness Jitter |  Mapped to the curve of the fuzzy roundness sensor |

Attributes above are somehow parsed already but bugs may occur. Many of them can be mapped but so far only the first brush attributes are really mapped to XML.
It's due to some missing features.

Other

Scattering
useScatter | Spray brush supports scattering. Can be mapped there |
Tip count | Can be mapped to count in spray |
Both Axes | we spray differently, has to be added to spray, not complicated |
Tip count dynamics | has to be added to spray , not complicated |
Count Jitter | has to be added to spray , not complicated |
Scatter Jitter | require stack of the sensors |
useTexture | not implemented in brush engines yet |
Texture each tip | not implemented in brush engines yet |
Texture blend mode | not implemented in brush engines yet, some blend modes are missing too (Linear Burn, Hard Mix?) |
Texture depth| not implemented in brush engines yet |
Minimum depth| not implemented in brush engines yet |
Texture Depth Dynamics| not implemented in brush engines yet |
Depth Jitter | not implemented in brush engines yet, stack of sensors |
Texture block | not implemented, but bitmap data again ??? |
Texture Scale | not implemented in brush engines yet |
Invert texture scale | not implemented in brush engines yet |
Dual Brush | not implemented in brush engines yet, and not described in parser spec too |
useColorDynamics | we have HSV dynamics, in spray there are color dynamics |
Foreground/Background Jitter | | not implemented in brush engines yet, not complicated |
Hue jitter | Can be mapped to Hue sensor |
Saturation | Can be mapped to Saturation sensor |
Brightness | Can be mapped to Saturation sensor, but fake?  HSB != HSV |
purity | not implemented in brush engines yet |
Flow Jitter| not implemented in brush engines yet, we need proper flow implementation |
Opacity Jitter | Opacity sensor, stacking needed |
Noise | not implemented in brush engines yet |
Wet Edges| not implemented in brush engines yet |
Airbrush | can be mapped to Airbrush option |
Smoothing| not implemented in brush engines yet |
Protect Texture| not implemented in brush engines yet |
Retrieved from "https://community.kde.org/index.php?title=Krita/ActionPlan2&oldid=4068"