diff --git a/contributors_manual/krita_manual_readme.rst b/contributors_manual/krita_manual_readme.rst index 3c27da6f4..e38bab38b 100644 --- a/contributors_manual/krita_manual_readme.rst +++ b/contributors_manual/krita_manual_readme.rst @@ -1,296 +1,296 @@ .. meta:: :description: Contributor's Readme for the Krita Manual .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier - Micheal Abrahams :license: GNU free documentation license 1.3 or later. .. Website shorthands. Sphinx/reStructuredText prefers it if you use shorthands when repeating websites. .. _phabricator : https://phabricator.kde.org .. _Manual Project Workboard : https://phabricator.kde.org/project/view/135/ .. _repository : https://phabricator.kde.org/source/websites-docs-krita-org/ .. _bugzilla : https://bugs.kde.org/ .. _krita_manual_contributors_guide: =============================== Krita Manual Contribution Guide =============================== Welcome to our new documentation! We've moved from userbase.kde.org to docs.krita.org, then we moved from Mediawiki to Sphinx. This latter change is because Sphinx allows us to handle translations much better than mediawiki can. The manual will include: A reference manual for Krita This one is probably what everyone is expecting when they type in docs.krita.org. Dry, basic, 'what does this button do' type of information. General concept tutorials. We've found over the past two years that for certain types of users, a reference manual, even with some examples, just isn't enough. The manual should also provide fast and concise explanations for things, and provide a basic workflow for preparing an image for the web. We also have found that certain concepts, such as color management and layer handling are far more advanced in Krita than the average artist is used to. Krita is free and many of its users will not have formal training in digital artwork. So there is no pre-existing artist-focused knowledge on how to use color management or filter layers. In addition there are systems that are unique to Krita, for example the brush system, the transform masks, the alpha inheritance and the perspective assistants. Finally, there are users who aren't familiar with even standard painting workflows, and are not flexible enough to understand how to port a tutorial for Sai or Photoshop to Krita. A list of known tutorials and video tutorials Apparently, one of the great things about Krita's team is how we connect with artists and acknowledge that they're doing cool stuff. The same should count for tutorials, especially because there are ways of using Krita and ways of approaching painting that are unique and we should encourage people to share their knowledge. Contributor's Manual Krita is (free) open source software, which makes us effectively a community project, with dozens of volunteers pitching in to make it better. This, of course, requires we keep track of manuals and howto's for new volunteers to come in and help us. The various places we've done this have been rather spread out, and are often under maintained. The contributor's manual is an attempt to solidify all the information. It is therefore very technical in places. krita.org tutorials There have been a bunch of tutorials on the krita.org and the krita-foundation.tumblr.com, the former focusing on explaining how to use a new feature and the later stimulated by user request. FAQ This one is already online and a merger of the different FAQs that we had. It's currently being translated and we hope to keep this one the primary one to update. For first timers ---------------- Unlike Mediawiki, Sphinx works more like how we write code for Krita. First things first, you will want to talk to us! For this you can either go to the `IRC on krita.org (#krita on freenode.org) `_, or, more importantly, make an account at `identity.kde.org `_. The account you make at identity can be used to both access the forum as well as the `phabricator`_, where we organise Krita development. If you have no idea where to begin, make a Kde identity account and make a post on `the forum `_. Sphinx works by writing simple text files with reStructuredText mark up, and then it takes those text files and turns them into the manual. We keep track of changes in the manual by putting them into a version control system called :program:`Git`. .. _making_changes_sphinx: Making changes ~~~~~~~~~~~~~~ Because we use Git, there's only a few people who can put things into the version control system, so if you want to make changes you will need to put it up for review. If you are not familiar with Git ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1. Get the source text from the `repository`_. Save a copy of the text as it existed originally. 2. Modify it. 3. Tools to check whether your modifications work. You can use the `Online Sphinx Editor `_ to check if your changes don't break 4. Bundle up the items into a zip. Put all the files you changed into a zip file. This also includes the images if you're changing them. Try to keep the filenames the same, that's easier for us to copy over. 5. Upload the zip on phabricator. 1. First, go to phabricator.kde.org and log in with your identity account. 2. Go to the `Manual Project Workboard`_ and there create a new task. 3. Explain what you did and use drag and drop to move the zip file to the input textbox. That should upload it. We will also need the email address you associate with your kde identity account. 4. Then, if the changes are accepted, someone with commit access will unpack those files into the manual folder and push the differences using the mail address. If you are familiar with Git ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1. Get the source from the `repository`_ using :program:`Git` clone 2. Make changes 3. Build locally (optional) 4. Generate a git diff. Go to the source directory in your terminal and write ``git diff > ../mydiff.diff`` this will make a diff file in the folder above. 5. Create a review request on phabricator 1. Login into `phabricator`_ with your identity account. 2. Go to differential. 3. Upper-right --> "Star" menu --> Create Review Request. 4. Upload the diff you made, select the correct repository (``websites-docs-krita-org``, easier to find with ``Krita.org Documentation Website``, *make sure you do not select docs-kde-org!*). 5. Confirm the file is correct. 6. Then in the next screen: 1. Add in Title/Short Summary. 2. Tell us what you changed in the summary. 3. (Optional) put your email in the comment if you want attribution. 4. Phabricator has a system that automatically tags the review request with the Krita Manual team. General philosophy ------------------ This is for determining what is an appropriate writing style. A writing style, whether we consider its practical or aesthetic qualities, is usually underpinned by a goal or general philosophy. What do we want to achieve with the manual, and for whom is the manual meant? Demographics and target audience(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We cannot talk about a demographic in the sense that we know all Krita users are 55 year old men. Krita is used by a hugely different amount of people, and we are actually kind of proud that we have such a varied userbase. Despite that, we know a couple of things about our users: * They are artists. This is explicitly the type of users that we target. * Therefore, we know they prefer pretty pictures. * They are visual. * They are trying to achieve pretty pictures. Therefore, the implicit goal of each page would be to get the feature used for pretty pictures. Other than that, we've observed the following groups: * High-school and college students trying out drawing software for illustrations. These usually have some previous experience with drawing software, like Painttool Sai or Photoshop, but need to be introduced to possibilities in :program:`Krita`. This group's strength is that they share a lot of information with each other like tips and tricks and tutorials. * Professionals, people who earn their money with digital drawing software. The strength of this group is that they have a lot of know-how and are willing to donate to improve the program. These come in two types: * Non technical professionals. These are people who do not really grasp the more mathematical bits of a piece of software, but have developed solid workflows over the years and work with software using their finely honed instincts. These tend to be illustrators, painters and people working with print. * Technical professionals. These are people who use :program:`Krita` as part of a pipeline, and care about the precise maths and pixel pushing. These tend to be people working in the games and VFX industry, but occasionally there's a scientist in there as well. * Adult and elderly hobbyists. This group doesn't know much about computers, and they always seem to get snagged on that one little step missing from a tutorial. Their strength as a group is that they adapt unconventional workflows from real life that the student wouldn't know about and the professional has no time for and create cool stuff with that, as well as that they have a tempering effect on the first group in the larger community. From these four groups... * there's only one that is technical. Which is why we need the concept pages, so that we can create a solid base to write our manual texts on top of. * three of them likely have previous experience with software and may need migration guides and be told how. * two of them need to know how to get Krita to cooperate with other software. * two of them have no clue what they are doing and may need to be guided through the most basic of steps. From that we can get the following rules: General Writing ~~~~~~~~~~~~~~~ Use American English if possible. We use American English in the manual, in accordance to Krita's UI being American English by default. Keep the language polite, but do not use academic language. As a community, we want to be welcoming to the users, so we try to avoid language that is unwelcoming. Swearing is already not condoned by KDE, but going to the far other end, an academic style where neither writer nor reader is acknowledged might give the idea that the text is far more complex than necessary, and thus scare away users. Avoid using gifs (open for debate) The reason is that people with epilepsy may be affected by fast moving images. Similarly, gifs can sometimes carry too much of the burden of explanation. If you can't help but use gifs, at the least notify the reader of this in the introduction of the page. Keep it translation compatible This consists of using svg for infographics, and using the appropriate markup for a given text. Regarding photos and paintings ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -* I would like to discourage photos and traditional paintings in the manual if they are not illustrating a concept. The reason is that it is very silly and a little dishonest to show Rembrand's work inside the Krita GUI, when we have so many modern works that were made in Krita. All of the pepper&carrot artwork was made in Krita and the original files are available, so when you do not have an image handy, start there. Photos should be avoided because Krita is a painting program. Too many photos can give the impression Krita is trying to be a solution for photo retouching, which really isn't the focus. +* I would like to discourage photos and traditional paintings in the manual if they are not illustrating a concept. The reason is that it is very silly and a little dishonest to show Rembrandt's work inside the Krita GUI, when we have so many modern works that were made in Krita. All of the pepper&carrot artwork was made in Krita and the original files are available, so when you do not have an image handy, start there. Photos should be avoided because Krita is a painting program. Too many photos can give the impression Krita is trying to be a solution for photo retouching, which really isn't the focus. * Of course, we still want to show certain concepts in play in photos and master paintings, such as glossing or indirect light. In this case, add a caption that mentions the name of the painting or the painter, or mentions it's a photograph. * Photos can still be used for photobashing and the like, but only if it's obviously used in the context of photobashing. Regarding images in general ~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Avoid text in the images and use the caption instead. You can do this with the figure directive. * If you do need to use text, make either an SVG, so the text inside can be manipulated easier, or try to minimize the amount of text. * Try to make your images high quality/cute. Let's give people the idea that they are using a program for drawing! * Remember that the manual is licensed under GDPL 1.3, so images submitted will be licensed under that. In the case of CC-By-Sa/CC-By ensure that the file gets attributed appropriately through a figure caption. Needless to say, don't submit images that cannot be licensed under either license. Protocol -------- So here we line out all the boring workflows. Tagging and Branches ~~~~~~~~~~~~~~~~~~~~ Adding and removing text will be done in the ``draft`` branch. Proofreading results for old pages will be considered as bugfixes and thus will go into the ``master`` branch and merged into the ``draft`` branch as necessary. Before the ``draft`` branch is merged for a given release: * The master branch will be tagged with the old version. * The draft branch is first double checked that it has updated version number and updated epub cover. The ``draft`` branch will not be merged until the day before a release to keep the pages intact for long enough. Each release will have a version of the epub uploaded as part of the release process. .. Where do we get the POT files from? Even the translated versions? Removing Pages ~~~~~~~~~~~~~~ If a feature is removed in a certain version, the corresponding pages. 1. Will first be marked deprecated. This can be done as so:: .. deprecated:: version number Text to indicate what the user should do without this feature. 2. Will be linked on a page called 'deprecated' 3. If the next version rolls around all the pages linked in the deprecated section will be removed. Adding Pages ~~~~~~~~~~~~ 1. Ensure that it is located in the right place. 2. Follow the :ref:`krita_markup_conventions` to ensure the page is formatted correctly. 3. Add the page to the TOC. 4. If the feature is new, add in versionadded:: .. versionadded:: version number optional something or the other. As with images, don't add text that you do not have permission to add. This means that text is either written by you, or you have permission to port it from the original author. The manual is GDPL 1.3+ so the text will be relicensed under that. Changing Pages ~~~~~~~~~~~~~~ If you fully rewrite a page, as opposed to proofreading it, the resulting page should be reviewed. If you change a page because a feature has changed, and you have commit access, the change can be pushed without review (unless you feel more comfortable with a review), but you should add:: .. versionchanged:: version number This and that changed. In all cases, check if you want to add yourself to the author field in the metadata section on top. Using deprecated, versionadded and versionchanged with the version number allows us to easily search the manual for these terms with grep: .. code:: bash grep -d recurse versionadded * --exclude-dir={_build,locale} Faulty pages ~~~~~~~~~~~~ If a page slips through the cracks, either... * Make a review request per the :ref:`making_changes_sphinx` section. * Make a task at the `Manual Project Workboard`_. * Make a bug at `bugzilla`_ under the project Krita in the section 'documentation'. Proofreading ~~~~~~~~~~~~ There are two types of proofreading that needs to be done. The most important one is **reviewing changes people make**. You can do this on phabricator in two ways: 1. Reviewing patches in differential. Reviewing patches is done in differential. Patch reviewing is usually done by programmers to find mistakes in each other's code, but because programming code is text based just like regular text, we can use patch reviewing to check against typos as well! A patch, or diff, is an amount of changes done in a document (added, removed) put into a machine readable file. When someone submits a review request (on system like gitlab or github this is a merge or pull request), people who maintain the original files will have to look them over and can make comments about things needing to change. This allows them to comment on things like typos, over-complicated writing but also things that are incorrect. After a patch has been accepted it can be pushed into the version control system. 2. Auditing changes in the manual. Auditing changes happens after the fact. You can audit a change by going to the commit message (from the repository page, go to history and then click on an entry), where you will be able to make comments on the changes made. In both cases, the interface consists of the difference being shown, with on the left the old version, and on the right the new version. Lines that have been added will be marked in green while lines that have been removed will be marked with red. You can click a line to add an 'inline' comment. Usually, when reviewing you go over the whole set of changes making comments where needed. To submit the inline comments, go to the bottom here you can add a general comment. When you submit the general comment all the inline comments will be submitted along side of it. The second major way the manual needs to be proofread is **over the whole file**. Many of the pages have only been checked for correctness but not for style and grammar. For this you will need to follow the :ref:`making_changes_sphinx` section, so that you can have full access to the pages and edit them. Translating ~~~~~~~~~~~ Translation of the manual is handled by the `KDE localization community `_. To join the translation effort, go to the localization site, select the list of `translation teams `_, select the language you wish to translate for, and follow the instructions on the team page to get in contact with fellow translators. The localization team has access to the PO files for this manual, which is a file type used by translation programs like POEdit and Lokalize. A translation team is able to work together on translating these files and uploading them to the translations SVN. A special script will then take the translations from the SVN and bring them to the manual section to be incorporated on a daily basis. Finished translations also need to be added to the build script to show up online. Translator teams which are confident in the state of their translation should contact the main Krita team via the kimageshop mailinglist(kimageshop@kde.org), or foundation@krita.org, to accomplish this. Other ----- For restructured text conventions, check :ref:`krita_markup_conventions` . diff --git a/general_concepts/colors/scene_linear_painting.rst b/general_concepts/colors/scene_linear_painting.rst index f61c3e446..6a3285786 100644 --- a/general_concepts/colors/scene_linear_painting.rst +++ b/general_concepts/colors/scene_linear_painting.rst @@ -1,164 +1,164 @@ .. meta:: :description: Scene Linear painting in Krita .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier :license: GNU free documentation license 1.3 or later. .. index:: Color, HDR, High Dynamic Range, Scene Linear, Scene Referred, Scene Linear Painting .. _scene_linear_painting: ===================== Scene Linear Painting ===================== Previously referred to as HDR painting and Scene Referred painting, Scene Linear Painting is doing digital painting in a peculiar type of colorspace. It is painting in a color space that is... 1. Linear - there’s no gamma encoding, or tone-mapping or whatever going on with the pixels you manipulate. (This is different from the pixels you see, but we’ll get to that later) 2. Floating Point - So 16bit or 32bit floating point per channel. These are the two important characteristics. The colorspace has a few more properties than this, such as the white point, or more importantly, the colorants that make up the gamut. But here’s the thing, those two could be anything, as long as the space is linear and the color depth is floating point. So, *Scene Linear is not a single one colorspace, but a* **TYPE** *of colorspace*. You can have a scene linear space that uses the sRGB/rec 709 colorants, or one that uses adobeRGB, or maybe one that uses rec 2020, as long as it is *linear* and in a *floating point bit depth*. -These two factors are for one reason: To make black and white arbitrary values. This might seem a bit weird. But when you are dealing with light-sources, you are dealing with a massive range of contrasts, and will have to decide afterwards which white and black you’d like to have. This is what the scene means in scene-linear, the relevant values are unique per scene, like a real world scene: a flowerfield lit by moonlight, a city in twilight or a sunny beach. You want to be able to put the right emphasis on the most important contrasting values, and being able to choose what is white and what is black is a very powerful tool here. After all, humans in the real world can see much more when they get used to the dark, or to the sun, so why not apply that to how we make our images? +These two factors are for one reason: To make black and white arbitrary values. This might seem a bit weird. But when you are dealing with light-sources, you are dealing with a massive range of contrasts, and will have to decide afterwards which white and black you’d like to have. This is what the scene means in scene-linear, the relevant values are unique per scene, like a real world scene: a flower field lit by moonlight, a city in twilight or a sunny beach. You want to be able to put the right emphasis on the most important contrasting values, and being able to choose what is white and what is black is a very powerful tool here. After all, humans in the real world can see much more when they get used to the dark, or to the sun, so why not apply that to how we make our images? This is also why it needs to be Linear. Gamma and Tone-mapped color spaces are already choosing which contrast is the most important to you. But for that, they too need to choose what is white or black. Linear doesn’t make such assumptions, so much better for when you want to choose yourself. You will eventually want to stick your image through some tone-mapping or gamma correction, but only at the end after you have applied filters and mixed colors! In fact, there’s always a non-destructive sort of transform going on while you are working on your image which includes the tone-mapping. This is called a display or view transform, and they provide a sort of set of binoculars into the world of your image. Without it, your computer cannot show these colors properly; it doesn’t know how to interpret it properly, often making the image too dark. Providing such a transform and allowing you to configure it is the prime function of color management. Between different view and display transforms, there’s also a difference in types. Some are really naive, others are more sophisticated, and some need to be used in a certain manner to work properly. The ICC color management can only give a certain type of view transforms, while OCIO color management in the LUT docker can give much more complex transforms easily configurable and custom settings that can be shared between programs. .. figure:: /images/en/color_category/Krita_scenelinear_cat_01.png :figwidth: 800 :align: center Above, an example of the more naive transform provided by going from scene-linear sRGB to regular sRGB, and to the right a more sophisticated transform coming from the filmic blender OCIO configuration. Look at the difference between the paws. Image by Wolthera van Hövell tot Westerflier, License: CC-BY-SA Conversely, transforming and interpreting your image’s colors is the only thing OCIO can do, and it can do it with really complex transforms, really fast. It doesn’t understand what your image’s color space is originally, doesn’t understand what CMYK is, and there’s also no such thing as a OCIO color profile. Therefore you will need to switch to an ICC workflow if you wish to prepare for print. Yes, but what is the point? --------------------------- The point is making things easier in the long run: #. It is easier to keep saturated non-muddy colors in a linear space. #. The high bit depth makes it easier to get smoother color mixes. #. Filters are more powerful and give nicer results in this space. It is far more easy to get nice blurring and bokeh results. #. Simple Blending Modes like Multiply or Addition are suddenly black magic. This is because Scene-Linear is the closest you can get to the physical (as in, physics, not material) model of color where multiplying colors with one another is one of the main ways to calculate the effect of light. #. Combining painting with other image results such as photography and physically based rendering is much easier as they too work in such a type of colorspace. So you could use such images as a reference with little qualms, or make textures that play nice with such a renderer. So the advantages are prettier colors, cooler filter results, more control and easier interchange with other methods. Okay, but why isn’t this all the rage then? ------------------------------------------- Simply put, because while it’s easier in the long run, you will also have to drop tools and change habits... In particular, there are many tools in a digital painter’s toolbox that have **hard-coded assumptions about black and white**. A very simple but massive problem is one with **inversion**. Inverting colors is done code-wise by taking the color for white and subtracting the color you want to invert from it. It’s used in many blending modes. But often the color white is hardcoded in these filters. There’s currently no application out there that allows you to define the value range that inversion is done with, so inverting is useless. And that also means the filters and blending modes that use it, such as (but not limited to)... * Screen (invert+multiply+invert) * Overlay (screens values below midtone-value, in sRGB this would be middle gray) * Color-dodge (divides the lower color with an inversion of the top one) * Color-burn (inverts the lower color and then divides it by the top color) * Hardlight (A different way of doing overlay, including the inversion) * Softlight (Uses several inversions along the way) Conversely Multiply, Linear Dodge/Addition (they’re the same thing), Subtract, Divide, Darker (only compares colors’ channel values), Lighter (ditto), and Difference *are fine to use*, as long as the program you use doesn’t do weird clipping there. Another one is HSL, HSI and HSY algorithms. They too need to assume something about the top value to allow scaling to white. HSV doesn’t have this problem. So it’s best to use an HSV color selector. For the blending modes that use HSY, there’s always the issue that they tend to be hardcoded to sRGB/Rec709 values, but are otherwise fine (and they give actually far more correct results in a linear space). So these are not a good idea to use with wide-gamut colorspaces, and due to the assumption about black and white, not with scene linear painting. The following blending modes use them: * Color * Luminosity * Saturation * Darker Color (uses luminosity to determine the color) * Lighter Color (Ditto) So that is the blending modes. Many filters suffer from similar issues, and in many applications, filters aren’t adjusted to work with arbitrary whites. Speaking of filters, when using the transform tool, you should also avoid using lanczos3, it’ll give a weird black halo to sharp contrasts in scene-linear. The bilinear interpolation filter will work just fine in this case. The second big problem is that **black doesn’t work quite the same**. If you have mixed pigments before, you will know that black can quite easily overpower the other colors, so you should only add the tiniest amount of it to a mixture. White in contrast gets dirtied quite easily. In a Scene Linear Color space, this is flipped. White is now more overpowering and black gets washed out super quickly. This relates to the additive nature of digital color theory, that becomes more obvious when working in linear. This makes sketching a bit different, after all, it’s really difficult to make marks now. To get around this, you can do the following: * Sketch on a mid-gray background. This is recommended anyway, as it serves as a neutral backdrop. For a linear space, 18% or 22% gray would be a good neutral. * Make a special brush that is more opaque than the regular sketching brushes you use. * Or conversely, sketch with white instead. * For painting, block out the shapes with a big opaque brush before you start doing your mixing. Overall, this is something that will take a little while getting used to, but you will get used to it soon enough. Finally, there’s the **issue of size**. 16 bit float per channel images are big. 32 bit float per channel images are bigger. This means that they will eat RAM and that painting and filtering will be slower. This is something that will fix itself over the years, but not many people have such a high-end PC yet, so it can be a blocker. So the issues are tools, expectations and size. In Summary ~~~~~~~~~~ Scene Linear Painting is painting an image in a color space that is linear and has a floating point bit depth. This does not assume anything about the values of black and white, so you can only use tools that don’t assume anything about the values of black and white. It has the advantage of having nicer filter results and better color mixtures as well as better interoperability with other scene-linear output. To be able to view such an image you use a view transform, also called a display conversion. Which means that if you wish to finalize your image for the web, you make a copy of the image that goes through a display conversion or view transform that then gets saved to png or jpeg or tiff. Getting to actual painting -------------------------- Now we’ve covered the theory, let us look at a workflow for painting scene linear. Setting up the Canvas ~~~~~~~~~~~~~~~~~~~~~ Select either a 16bit or 32bit image. By default Krita will select a linear sRGB profile. This is fine. Then, download an OCIO config. I will use `Filmic Blender `_ here because it is quite simple to set up. Extract the downloaded zip somewhere you can find it back. Open the LUT docker, turn on OCIO, select ‘OCIO’ and set the path to the downloaded OCIO config. Set the view to ‘Filmic log encoding’ and the look to ‘Base Contrast’. And now you can start painting! Keep in mind everything mentioned above. Not all filters and not all blending modes work. This will improve in the future. Other than that, everything else is the same. Picking really bright colors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Picking regular colors is easy, but how do we pick the really bright colors? There are three ways of getting access to the really bright colors in Krita: #. By lowering the exposure in the LUT docker. This will increase the visible range of colors in the color selectors. You can even hotkey the exposure in the canvas input settings. #. Or simply by opening the internal color selector by double clicking the dual color button and typing in values higher than 1 into the field. #. And finally by picking a really bright color from an image that has such values. Then paint. It’s recommended to make a bunch of swatches in the corner, at the least, until Krita’s new palette docker allows you to save the values properly. Lighting based workflow ~~~~~~~~~~~~~~~~~~~~~~~ So, we have our typical value based workflow, where we only paint the grays of the image so that we can focus on the values of the image. We can do something similar with Scene Linear Painting. Where with the value based workflow you paint the image as if it were a grayscale of what you intended to paint, with a lighting based workflow you paint as if all the objects are white. The effect of the color of an object can be determined by multiplying its base color with the color of the light. So you could paint objects as if they were white, paint the colors on a separate layer and just use the multiply blending mode to get the right colors. .. figure:: /images/en/color_category/Krita_scenelinear_cat_02.png :align: center :figwidth: 800 - The leftmost image is both the lighting based one and the color layer separate, the middle with the two layers multiplied and the right a luminosity based view. This cat is a nice example as it demonstrates why having textures and lighting separate could be interesting.) + The leftmost image is both the lighting based one and the color layer separate, the middle with the two layers multiplied and the right a luminosity based view. This cat is a nice example as it demonstrates why having textures and lighting separate could be interesting. You can even combine this with a value based workflow by opening a new view and setting the component to luminosity. That way you can see both the grayscale as well as the lighting based version of the image next to one another. -The keen minded will notice that a lighting based workflow kind of resembles the idea of a light-pass and a color pas in 3d rendering. And indeed, it is basically the same, so you can use lighting passes from 3d renders here, just save them as EXR and import them as a layer. One of the examples where scene linear painting simplifies combining methods. +The keen minded will notice that a lighting based workflow kind of resembles the idea of a light pass and a color pass in 3d rendering. And indeed, it is basically the same, so you can use lighting passes from 3d renders here, just save them as EXR and import them as a layer. One of the examples where scene linear painting simplifies combining methods. Finishing up ~~~~~~~~~~~~ When you are done, you will want to apply the view transform you have been using to the image (at the least, if you want to post the end result on the internet)... This is called LUT baking and not possible yet in Krita. Therefore you will have to save out your image in EXR and open it in either Blender or Natron. Then, in Blender it is enough to just use the same OCIO config, select the right values and save the result as a png. You can even use some of Blender’s or Natron’s filters at this stage, and when working with others, you would save out in EXR so that others can use those. diff --git a/tutorials/common_workflows.rst b/tutorials/common_workflows.rst index bbdb6192b..ed66fb55e 100644 --- a/tutorials/common_workflows.rst +++ b/tutorials/common_workflows.rst @@ -1,210 +1,210 @@ .. meta:: :description lang=en: Common workflows used in Krita .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier - Vancemoss - Raghavendra Kamath :license: GNU free documentation license 1.3 or later. .. _common_wokflows: ================ Common Workflows ================ Krita's main goal is to help artists create a digital painting from scratch. Krita is used by comic artists, matte painters, texture artists, and illustrators around the world. This section explains some common workflow that artists use in Krita. When you open a new document in Krita for the first time, you can start painting instantly. The brush tool is selected by default and you just have to paint on the canvas. However, let us look at what artists do in Krita. Below are some of the common workflows used in Krita: Speed Painting and Conceptualizing ---------------------------------- Some artists work only on the digital medium, sketching and visualizing concepts in Krita from scratch. As the name suggests a technique of painting done within a matter of hours to quickly visualize the basic scene, character, look and feel of the environment or to denote the general mood and overall concept is called a **speed painting**. Finishing and finer details are not the main goals of this type of painting, but the representation of form value and layout is the main goal. Some artists set a time limit to complete the painting while some paint casually. Speed painting then can be taken forward by adding finer details and polish to create a final piece. Generally, artists first block in the composition by adding patches and blobs of flat colors, defining the silhouette, etc. Krita has some efficient brushes for this situation, for example, the brush under **Block Tag** like Block fuzzy, Block basic, layout_block, etc. After the composition and a basic layout has been laid out the artists add as many details as possible in the given limited time, this requires a decent knowledge of forms, value perspective and proportions of the objects. Below is an example of speed paint done by `David Revoy `_ in an hours time. .. image:: /images/en/Pepper-speedpaint-deevad.jpg :alt: speedpaint of pepper and carrot by deevad (David Revoy) :width: 800 Artwork by David Revoy, license : `CC-BY `_ You can view the recorded speed painting demo for the above image `on Youtube `_. Colorizing Line Art ------------------- Often an artist, for example, a comic book colorist will need to take a pencil sketch or other line art of some sort and use Krita to paint underneath it. This can be either an image created digitally or something that was done outside the computer and has been scanned. Preparing the line art ^^^^^^^^^^^^^^^^^^^^^^ If your images have a white or other single-tone background, you can use either of the following methods to prepare the art for coloring: Place the line art at the top of the layer stack and set its layer blending mode to :guilabel:`Multiply` If you want to clean the line art a bit you can press :kbd:`Ctrl + L` or go to :menuselection:`Filters --> Adjust --> Levels` .. image:: /images/en/Levels-filter.png :alt: level filter dialog You can clean the unwanted greys by moving the white triangle in the input levels section to left and darken the black by moving the black triangle to right. If you draw in blue pencils and then ink your line art you may need to remove the blue lines first to do that go to :menuselection:`Filters --> Adjust --> Color adjustment` curves or press shortcut :kbd:`Ctrl + M`. .. image:: /images/en/common-workflows/Color-adjustment-cw.png :alt: remove blue lines from image step 1 Now select **Red** from the drop-down, click on the top right node on the graph and slide it all the way down. Or you can click on the top right node and enter **0** in the input field. Repeat this step for **Green** too. .. image:: /images/en/common-workflows/Color-adjustment-02.png :alt: removing blue lines from scan step 2 Now the whole drawing will have a blue overlay, zoom in and check if the blue pencil lines are still visible slightly. If you still see them, then go to **Blue** Channel in the color adjustment and shift the top right node towards left a bit, Or enter a value around 190 (one that removes the remaining rough lines) in the input box. .. image:: /images/en/common-workflows/Color-adjustment-03.png :alt: remove blue lines from scans step 3 Now apply the color adjustment filter, yes we still have lots of blue on the artwork. Be patient and move on to the next step. Go to :menuselection:`Filters --> Adjust --> Desaturate` or press :kbd:`Ctrl + Shift + U`. Now select :guilabel:`Max` from the list. .. image:: /images/en/common-workflows/Color-adjustment-04.png :alt: remove blue lines from scans step 4 .. hint:: It is good to use non-photo-blue pencils to create the blue lines as those are easy to remove. If you are drawing digitally in blue lines use #A4DDED color as this is closer to non-photo-blue color. You can learn more about doing a sketch from blue sketch to digital painting `here in a tutorial by David Revoy `_. After you have a clean black and white line art you may need to erase the white color and keep only black line art, to achieve that go to :menuselection:`Filters --> Color --> Color to Alpha`. Use the dialog box to turn all the white areas of the image transparent. The Color Picker is set to White by default. If you have imported scanned art and need to select another color for the paper color then you would do it here. .. image:: /images/en/Color-to-alpha.png :alt: color to alpha dialog box -This will convert the white color in your line art to alpha i.e. it will make the white transparent leaving only the line art. Your line art can be in grey-scale color space, this is a unique feature in Krita which allows you to keep a layer in a color-space independent from the image. +This will convert the white color in your line art to alpha i.e. it will make the white transparent leaving only the line art. Your line art can be in greyscale color space, this is a unique feature in Krita which allows you to keep a layer in a color-space independent from the image. Laying in Flat Colors ^^^^^^^^^^^^^^^^^^^^^ There are many ways to color a line art in Krita, but generally, these three are common among the artists. 1. Paint blocks of color directly with block brushes. 2. Fill with Flood fill Tool. 3. Use one of the G'MIC colorize comics filters. Blocking with brush """"""""""""""""""" The first is the more traditional method of taking a shape brush or using the geometric tools to lay in color. This would be similar to using an analog marker or brush on paper. There are various block brushes in Krita, you can select **Block** Tag from the drop-down in the brush presets docker and use the brushes listed there. Add a layer underneath your line art layer and start painting with the brush. If you want to correct any area you can press :kbd:`E` and convert the same brush into an eraser. You can also use a layer each for different colors for more flexibility. Filling with Flood Fill tool """""""""""""""""""""""""""" The second method is to use the Flood fill tool to fill large parts of your line art quickly. This method generally requires closed gaps in the line art. To begin with this method place your line art on a separate layer. Then activate the flood fill tool and set the :guilabel:`Grow selection` to 2px, uncheck :guilabel:`Limit to current layer` if previously checked. .. image:: /images/en/common-workflows/Floodfill-krita.png :alt: flood fill in krita Choose a color from color selector and just click on the area you want to fill the color. As we have expanded the fill with grow selection the color will be filled slightly underneath the line art thus giving us a clean fill. GMIC Colorize [Interactive] """"""""""""""""""""""""""" The third method is to use take advantage of the integrated G'Mic filters. These are powerful filters that can dramatically improve your workflow and cut you down on your production time. To begin coloring with the G'MIC colorize interactive, go to :menuselection:`Filters --> G'MIC`. Choose :menuselection:`Filters --> G'MIC --> Black & white --> Colorize[interactive]` from the list of filters. Then select Line art for :menuselection:`Input type, Image + Colors (2 Layers)` for output type, set the view resolution according to your need. If you have any specific color palette to use for coloring add the path for it in an additional color palette. The example of the filter window with the required inputs is shown below. .. image:: /images/en/common-workflows/GMIC-colorize-interactive-krita.png :alt: G'MIC window in Krita Press **Apply** to begin the coloring, this will open a color selector **palette** window and a window showing your line art. Choose the color from the palette and click on the areas that need to be filled with color like the example shown below. .. image:: /images/en/common-workflows/Krita-GMIC-colorize-interactive.png :alt: G'MIC colorize interactive window If you feel that the dots are a bit distracting you can press :kbd:`Tab` to reduce the size or hide the dots. to zoom out you can press :kbd:`Ctrl + ↓` and :kbd:`Ctrl + ↑` vice versa. Panning is done by |mousemiddle| + drag. Press :kbd:`Spacebar` to generate the colors. If you want to replace a color select the color by |mousemiddle| and pressing :kbd:`R` then you can select an alternate color from the palette. Once you have finished adding the desired flat colors you can press :kbd:`Enter` to apply the filter. Then don't forget to press **Ok** in the G'MIC dialog box. The flats colors will be placed on a separate layer. You can check `this `_ tutorial by David Revoy to know more about this technique. GMIC Colorize [comics] """""""""""""""""""""" Krita provides one more option to prepare flat colors through G'MIC colorize comics filter. This technique needs some preparations before you run the G'MIC filter. This layer extrapolates the color spots that you input below the line art You have to create two layers below the line art, one for the color spots indicating which color you need to be filled in the region and one for the final extrapolated output of the filter. Mark some colors spots in the layer beneath the line art. The layer setup can be seen in the image below. .. image:: /images/en/common-workflows/Colorize-krita.png :alt: G'MIC colorize comics layer setup The colors spots are marked in red in the image Now go to :menuselection:`Filters --> G'MIC --> Black & white --> Colorize[comics]`. In the G'MIC dialog box, select all for input and inplace (default) for output, select :guilabel:`Lineart + color spots + extrapolated layers` for both input and output layers on the right-hand side. Smoothness is for filling gap tolerance and details the default is 0.5 you can adjust it according to your line art. .. image:: /images/en/common-workflows/Colorise-comics-setting.png :alt: Colorize Interactive dialog and settings -Press **Apply** and **Ok** to apply and exit the G'MIC dialog. You'll now have flat colors beneath you line art. +Press **Apply** and **Ok** to apply and exit the G'MIC dialog. You'll now have flat colors beneath your line art. More details about this technique can be found in the tutorial `at Timothée Giet's blog `_. Painting -------- Starting from chaos ^^^^^^^^^^^^^^^^^^^ Here, you start by making a mess through random shapes and texture, then taking inspirations from the resulting chaos you can form various concepts. It is kind of like making things from clouds or finding recognizable shapes of things in abstract and random textures. Many concept artists work with this technique. You can use brushes like the shape brush, or the spray brush to paint a lot of different shapes, and from the resulting noise, you let your brain pick out shapes and compositions. .. image:: /images/en/common-workflows/Chaos2.jpg :alt: Starting a painting from chaotic sketch You then refine these shapes to look more like shapes you think they look, and paint them over with a normal paintbrush. This method is best done in a painting environment. Starting from a value based underground ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This method finds its origins in old oil-painting practice: You first make an under-painting and then paint over it with color, having the dark underground shine through. With Krita you can use blending modes for this purpose. Choosing the color blending mode on a layer on top allows you to change the colors of the image without changing the relative luminosity. This is useful, because humans are much more sensitive to tonal differences than the difference in saturation and hue. This'll allow you to work in greyscale before going into color for the polishing phase. You can find more about this technique `here `_. Preparing Tiles and Textures ---------------------------- -Many artists use Krita to create textures for 3d assets used for games animation etc. Krita has many texture template for you to choose and get started with creating textures. These templates have common sizes, bit depth and color profiles that are used for texturing workflow. +Many artists use Krita to create textures for 3d assets used for games animation etc. Krita has many texture templates for you to choose and get started with creating textures. These templates have common sizes, bit depth and color profiles that are used for texturing workflow. Krita also has a real-time seamless tile mode to help texture artist prepare tiles and texture easily and check if it is seamless on the fly. The tiled mode is called wrap-around mode, to activate this mode you have press :kbd:`W`. No when you paint the canvas is tiled in real-time allowing you to create seamless pattern and texture, it is also easy to prepare interlocking patterns and motifs in this mode. Creating Pixel Art ------------------ Krita can also be used to create a high definition pixel painting. The pixel art look can be achieved by using Index color filter layer and overlaying dithering patterns. The general layer stack arrangement is as shown below. .. image:: /images/en/common-workflows/Layer-docker-pixelart.png :alt: Layer stack setup for pixel art The index color filter maps specific user-selected colors to the grey scale value of the artwork. You can see the example below, the strip below the black and white gradient has an index color applied to it so that the black and white gradient gets the color selected to different values. .. image:: /images/en/common-workflows/Gradient-pixelart.png :alt: color mapping in index color to greyscale You can choose the required colors and ramps in the index color filter dialog as shown below. .. image:: /images/en/common-workflows/Index-color-filter.png :alt: index color filter dialog Dithering can be used to enhance the look of the art and to ease the banding occurred by the index color filter. Krita has a variety of dithering patterns by default, these can be found in pattern docker. You can use these patterns as fill layer, then set the blend mode to **overlay** and adjust the opacity according to your liking. Generally, an opacity range of 10% - 25% is ideal. -Paint the artwork in grey-scale and add an index color filter layer at the top then add the dithering pattern fill layer below the index color filter but above the artwork layer, as shown in the layer stack arrangement above. You can paint or adjust the artwork at any stage as we have added the index color filter as a filter layer. +Paint the artwork in greyscale and add an index color filter layer at the top then add the dithering pattern fill layer below the index color filter but above the artwork layer, as shown in the layer stack arrangement above. You can paint or adjust the artwork at any stage as we have added the index color filter as a filter layer. You can add different groups for different colors and add different dithering patterns for each group. Below is an example painted with this layer arrangement. .. image:: /images/en/common-workflows/Kiki-pixel-art.png :alt: Pixel art done in Krita