diff --git a/KritaFAQ.rst b/KritaFAQ.rst index 18a0d3349..27bbea737 100644 --- a/KritaFAQ.rst +++ b/KritaFAQ.rst @@ -1,552 +1,552 @@ .. .. meta:: :description: Frequently asked Krita Questions. .. metadata-placeholder :authors: - Scott Petrovic - Wolthera van Hövell tot Westerflier - Raghavendra Kamath - Boudewijn Rempt - Alvin Wong - Dmitry Kazakov - Timothée Giet - Tokiedian - Nmaghfurusman - RJ Quiralta - Tyson Tan :license: GNU free documentation license 1.3 or later. .. index:: FAQ, Frequently Asked Questions .. _faq: .. _KritaFAQ: ######### Krita FAQ ######### This page contains common problems people have with Krita. Note that we assume that you are using the latest version of Krita. Please verify that to make sure. .. contents:: General ======= General questions What is Krita? -------------- This is our vision for the development of Krita: Krita is a free and open source cross-platform application that offers an end-to-end solution for creating digital art files from scratch. Krita is optimized for frequent, prolonged and focused use. Explicitly supported fields of painting are illustrations, concept art, matte painting, textures, comics and animations. Developed together with users, Krita is an application that supports their actual needs and workflow. Krita supports open standards and interoperates with other applications. Is it possible to use Krita in my own language, not English? ------------------------------------------------------------ Krita should automatically use the system language. If that is not the case, please follow these steps: #. With :menuselection:`Settings --> Switch Application Language...` menu item will appear a small window. #. Click :guilabel:`Primary language` and select your language. #. Click :guilabel:`OK` to close the window. #. Restart krita and it will be displayed in your selected language! If this doesn't work, you might have to add a fall-back language as well. This is a bug, but we haven't found the solution yet. Does Krita have layer clip or clipping mask? -------------------------------------------- Krita has no clipping mask, but it has a clipping feature called inherit alpha. Let's see :ref:`this page ` and learn how to do clipping in Krita! Where are the configuration files stored? ----------------------------------------- These are stored at the following places for the following operating systems: Linux :file:`$HOME/.config/kritarc` Windows :file:`%APPDATA%\\Local\\kritarc` MacOS X :file:`$HOME/Library/Preferences/kritarc` The kritarc file is the configuration file. Krita does not store settings in the Windows registry. .. _faq_reset_krita_configuration: Resetting Krita configuration ----------------------------- You can reset the Krita configuration in following way: - For Krita 3.0 and later: Delete/rename the kritarc file, found here: Linux :file:`$HOME/.config/kritarc` Windows :file:`%LOCALAPPDATA%\\kritarc` MacOS X :file:`$HOME/Library/Preferences/kritarc` There can be two other files you might want to remove: kritaopenglrc and kritadisplayrc. If the configuration was causing a crash, don't delete the mentioned file, but instead rename and send it to us in order for us to figure what caused the crash. If you have installed Krita through the Windows store, the kritarc file will be in another location :file:`%LOCALAPPDATA%\\Packages\\49800Krita_{RANDOM STRING}\\LocalCache\\Local\\kritarc` The random string depends on your installation. Windows users have a habit of uninstalling and reinstalling applications to solve problems. Unless the problem is that the installation was corrupted by a virus scanner or drive failure, that will NOT work. Uninstalling Krita then reinstalling replaces the bytes on your drive with exactly the same bytes that were there before. It doesn't reset anything, least of all Krita's settings. Why my configuration resets on its own? --------------------------------------- There are two possible reasons: - You don't save your settings. This is most probable if you are on Windows and you have either a display with a small resolution (below fullHD) or if you have fullHD resolution with UI scaling in Windows settings (which is 150% by default). In those cases it might happen that you don't see the :guilabel:`OK` button in the :guilabel:`Configure Krita` dialog. You can use :kbd:`Alt + O` instead. (You can go to :menuselection:`Configure Krita... --> General --> Window` and make sure that :guilabel:`Enable HiDPI` checkbox is unchecked to disable scaling for Krita and get a smaller UI). - You close your computer using the power button. If you are on Windows and you use power button instead of a standard procedure to close or restart your computer, it might happen that Krita's configuration file gets corrupted. To solve this, just use the correct way of closing your system: either :menuselection:`Start -> Restart` or :menuselection:`Start -> Shutdown`. Where are my resources stored? ------------------------------ Linux :file:`$HOME/.local/share/krita/` Windows :file:`%APPDATA%\\krita\\` Mac OS X :file:`~/Library/Application Support/Krita/` If you installed Krita in the Windows Store, your custom resources will be in a location like: :file:`%LOCALAPPDATA%\\Packages\\49800Krita_{RANDOM STRING}\\LocalCache\Roaming\krita` Krita tells me it can't find some files and then closes, what should I do? -------------------------------------------------------------------------- Causes for this could be the following: - It might be that your download got corrupted and is missing files (common with bad wifi and bad internet connection in general), in that case, try to find a better internet connection before trying to download again. Krita should be around 80 to 100 MB in size when downloading. - It might be that something went wrong during installation. Check whether your harddrive is full and reinstall Krita with at least 120 MB of empty space. If not, and the problem still occurs, there might be something odd going on with your device and it's recommended to find a computer expert to diagnose what is the problem. -- Some unzippers don't unpack our zipfiles correctly. The native ones on Windows, OSX and most Linux distributions should be just fine, and we recommend using them. +- Some unzippers don't unpack our ZIP files correctly. The native ones on Windows, OSX and most Linux distributions should be just fine, and we recommend using them. - You manually, using a file manager deleted or moved resources around, and thus Krita cannot find them anymore. What Graphics Cards does Krita support? --------------------------------------- Krita can use OpenGL to accelerate painting and canvas zooming, rotation and panning. Nvidia and recent Intel GPUs give the best results. Make sure your OpenGL drivers support OpenGL 3.2 as the minimum. AMD/ATI GPU’s are known to be troublesome, especially with the proprietary drivers on Linux. However, it works perfectly with the Radeon free driver on Linux for supported AMD GPU. Try to get a graphics card that can support OpenGL 3.2 or above for the best results, some examples: .. Following graphics cards have been suggested by Tyson Tan on the basis that they all support 3.2 Intel Intel 3rd Generation HD Graphics, IvyBridge or Bay-Trail microarchitecture, released in 2012. Commonly available products: Celeron J1x00, N2x00, Celeron (G)1xx0, Pentium J2x00, N3500, Pentium (G)2xx0, Core i3/5/7-3xx0. AMD/ATI Radeon HD 2000 family, TeraScale 1 microarchitecture, Released in 2007. Commonly available products: Radeon HD 2400 PRO, Radeon HD 2600 PRO, etc. Nvidia GeForce 8 family, Tesla microarchitecture, released in 2006. Commonly available products: GeForce 8400 GS, GeForce 8800 GTS, 9800 GTX, GTS 250, etc. *For Krita 3.3 or later:* Krita on Windows can use Direct3D 11 for graphics acceleration (through ANGLE). This is enabled automatically on systems with an Intel GPU. I can't edit text from PSD files created by Photoshop ----------------------------------------------------- -There is no text support for psd file yet. The text will appear rasterized and converted into a paint layer. +There is no text support for PSD file yet. The text will appear rasterized and converted into a paint layer. How much memory does my image take? ----------------------------------- For simple images, its easy to calculate: you multiply width \* height \* channels \* size of the channels (so, for a 1000×1000 16 bit integer rgba image: 1000 x 1000 x 4 x 2). You multiply this by the number of layers plus two (one for the image, one for the display). If you add masks, filter layers or clone layers, it gets more complicated. Why do I get a checkerboard pattern when I use the eraser? ---------------------------------------------------------- You’re probably used to Gimp or Photoshop. The default background or first layer in these applications doesn’t have an alpha channel by default. Thus, on their background layer, the eraser paints in the background color. In Krita, all layers have an alpha channel, if you want to paint in the background color, you should simply do it in a layer above the first one (Layer 1), that would prevent you from erasing the white background color, making the checkerboard visible. You get the same effect in, say, Gimp, if you create new image, add an alpha channel and then use the eraser tool. Most Krita users will actually start a sketch in Krita by adding a new blank layer first before doing anything else. (The :kbd:`Ins` key is a useful shortcut here). That doesn’t use extra memory, since a blank layer or a layer with a default color just takes one pixel worth of memory. Can krita work with 8 bit (indexed) images? ------------------------------------------- No. Krita has been designed from the ground up to use real colors, not indexed palettes. There are no plans to support indexed color images, although Krita can export to some indexed color image formats, such as GIF. However, it does not offer detailed control over pixel values. Where can I find older versions of Krita? ----------------------------------------- All the older versions of Krita that are still available can be found here: - `Very old builds `_. On Windows, the Krita User Interface is too big on my screen ------------------------------------------------------------ If you're using Windows, you can set the display scaling to 150% or 200%. Krita comes with HiDPI enabled by default, so if you do that, the Krita UI might be too big for your screen. You can turn it off using the following steps: - On the menu, select :menuselection:`Settings --> Configure Krita...` - On :guilabel:`General` page, switch to :guilabel:`Window` tab. - Uncheck :guilabel:`Enable Hi-DPI support` (or check if you wish to enable it) - Press :guilabel:`OK`, if the settings screen is too big, :kbd:`Alt + O` will trigger the OK button too. - Restart Krita You can also change the toolbox icon size by right-clicking on the toolbox and selecting a size. Windows: In fullscreen mode, why is there a thin gap at the bottom of the window? --------------------------------------------------------------------------------- When :ref:`Canvas Graphics Acceleration ` is set to OpenGL, you may see a thin gap at the bottom of the window which you can see through. This is done deliberately to work around a bug causing menus and dropdowns to be unusable. If you find it distracting, you can consider changing the Renderer to Direct3D 11 which doesn't require this workaround. Windows: OBS can't record the Krita OpenGL canvas ------------------------------------------------- The possible workarounds for this is to do either of the following: #. Turn off OpenGL in :menuselection:`Settings --> Configure Krita... --> Display`. #. Or don't use the hardware accelerated mode (game recording mode) in OBS, thus capturing the whole desktop instead of attempting to capture only Krita. You might also be able to work around the problem by using the ANGLE renderer instead of native OpenGL. Windows: Can I use Krita with Sandboxie? ---------------------------------------- No, this is not recommended. Sandboxie causes stuttering and freezes due to the way it intercepts calls for resources on disk. Windows: Krita cannot save -------------------------- If the message is "File not found. Check the file name and try again.", you probably have Controlled Folder Access enabled. - Select :menuselection:`Start --> Settings`. - Choose :menuselection:`Update & security --> Windows Defender`. - Select :guilabel:`Open Windows Defender Security Center`. - Select :guilabel:`Virus & threat protection`, and then choose :guilabel:`Virus & threat protection settings`. - Under :guilabel:`Controlled folder access`, turn it on or off. You can also whitelist Krita, following `these instructions `_. Windows: Krita cannot open my file anymore ------------------------------------------ Your file got corrupted. There are several things that might cause this: #. Windows was shutdown improperly, like by holding the power button. This prevents your harddrive from finishing up the things it is doing and file away your files incorrectly. Please always try to shutdown your computer via the proper shutdown procedure, and if you are in a situation where this is not possible (like frequent blackouts), make daily backups! This may lead to the file being filled with zeroes, so it cannot be recovered from. .. versionchanged:: 4.2.8 Krita version 4.2.8 introduced special safety measure for Windows that should help avoiding this situation. But in any case, unless something makes it impossible, always make sure to shutdown your system using the standard approach. On Windows that means going to Start menu and selecting "Shutdown". -#. Badly programmed security software may attempt to rewrite kra files, or prevent Krita from writing to the folder you wish to save to. These cases can be checked by trying to save in that location, and then, without shutting down Krita, checking in the folder to see if the file saved. Files lost due this cannot be recovered. +#. Badly programmed security software may attempt to rewrite KRA files, or prevent Krita from writing to the folder you wish to save to. These cases can be checked by trying to save in that location, and then, without shutting down Krita, checking in the folder to see if the file saved. Files lost due this cannot be recovered. #. Cloud services like dropbox and onedrive have been known to prevent Krita from saving. We've implemented fixes for this, but much like the above point it is worth checking that this isn't the cause of the issue. Files lost due this cannot be recovered. -#. Occasionally the zips that kra files comprise of will have the last few bytes missing. We're doing everything in our power to prevent this kind of corruption, but it might be a file system issue. This particular bug can be fixed by renaming the extension (in windows you will need to enable the file extensions, which this FAQ will not cover) to zip, and then using a zip repairing utility to fix the zip file. Then rename it back to kra. +#. Occasionally the ZIPs that KRA files comprise of will have the last few bytes missing. We're doing everything in our power to prevent this kind of corruption, but it might be a file system issue. This particular bug can be fixed by renaming the extension (in windows you will need to enable the file extensions, which this FAQ will not cover) to ZIP, and then using a ZIP repairing utility to fix the ZIP file. Then rename it back to KRA. #. If Krita doesn't give an error message, but rather crashes, your file is too big, and Krita is not so much crashing as that the operating system is shutting it down. Try shutting down some other programs like webbrowsers or streaming services to free up working memory. You should be able to open the file in question. At this point the recommended course of action is to try and reduce the file size in some manner, such as merging layers, splitting up an animation or scaling the image down. How to recover my files? ------------------------- #. Check whether you have any backup file or autosave left: :ref:`autosave`. -#. Check whether you can open the file as zip archive. +#. Check whether you can open the file as ZIP archive. #. Rename the extension of the file from ``.kra`` to ``.zip``. #. Try to open (your system should automatically select an archive opener tool). #. There is file called mergedimage.png inside that represents all layers merged that you can use for reference in case you can't restore anything else. -#. Check whether zip repairer tool helps. +#. Check whether ZIP repairer tool helps. #. Copy the file so you have a backup just in case. #. Rename the extension of the file from ``.kra`` to ``.zip``. - #. Use zip repairer tool on the ``.zip`` file. + #. Use ZIP repairer tool on the ``.zip`` file. .. code-block:: bash # On Linux: mv file.kra file_copy.zip zip -F file_copy.zip --out file_new1.zip unzip file_new1.zip # if it still doesn't work: zip -FF file_copy.zip --out file_new2.zip unzip file_new2.zip - # if it still doesn't work, try to run it again on file_new2.zip file, or try on file_new1.zip file + # if it still doesn't work, try to run it again on *file_new2.zip* file, or try on *file_new1.zip* file # On Windows: Copy the file, rename the extension. - Use any graphical zip repairer on the new file. (Follow the instructions for that specific program). + Use any graphical ZIP repairer on the new file. (Follow the instructions for that specific program). #. Try to open in Krita. #. If it cannot be opened in Krita, try the trick from 2.: open the archive and find mergedimage.png file. #. Open your file in Notepad or any other text editor. If the the content of the file is only a repeated *NUL* symbol, it means the file is most probably unrecoverable using the standard method. If it's of a very high importance for you, you can try to recover the previous save using methods that checks the hard drive directly. Krita crashes on Windows 7 on start-up -------------------------------------- Starting with Krita 4.2.0, Krita uses version 5.12 of the Qt toolkit. This needs to have access to Direct3D 11 or OpenGL ES 2.0 or higher. You might need to install drivers appropriate to your GPU (Nvidia, AMD/ATI, Intel). This also makes it hard to run Krita in a virtual environment: in Virtual Box you need to install the guest addition in safe mode, and enable the experimental Direct3D support. Windows: How can I produce a backtrace? ----------------------------------------- .. seealso:: :ref:`Dr. Mingw debugger ` If you experience a crash on Windows, and can reproduce the crash, the bug report will be much more valuable if you can create a backtrace. A backtrace is somewhat akin to an airplane's blackbox, in that they tell what set of instructions your computer was running when it was crashing (where the crash happened), making it very useful to figure out why the crash happened. The :ref:`Dr. Mingw debugger ` is bundled with Krita. Please visit the page :ref:`Dr. Mingw debugger ` for instructions on getting a backtrace with it. Windows: Krita's window is semi-transparent ------------------------------------------- Chances are you are using an NVidia GPU. Due to a bug in Nvidia's driver that we haven't been able to workaround yet, sometimes Krita's window will be transparent or semi-transparent. The solution is to enable the Angle renderer in Krita's Settings dialog. Open the :menuselection:`Settings` menu (Press Alt-N if the menubar is not visible and your system is in English), then open the :guilabel:`Configure Krita` dialog. In the dialog window select the :guilabel:`Display` page and select the Angle renderer in the :guilabel:`Preferred Renderer` combobox. Restart Krita. Tablets ======= What tablets does Krita support? -------------------------------- Krita isn’t much fun without a pressure sensitive tablet. If the tablet has been properly configured, Krita should work out of the box. On Windows, you need to either install the Wintab drivers for your tablet, or enable the :guilabel:`Windows 8+ Pointer Input` option in Krita's settings. You can find a community curated list of tablets supported by krita :ref:`here `. If you're looking for information about tablets like the iPad or Android tablets, look :ref:`here `. What if your tablet is not recognized by Krita? ----------------------------------------------- First, check if you have installed drivers and the like. The :ref:`drawing_tablets` page has some explanations and descriptions of common issues. If none of those work, we would like to have a bug report at bugs.kde.org, with a tablet log. Here's how you make a tablet log: #. You need to have something to output the log to. On 4.2 you can use the :ref:`log_viewer` docker for this. Just open the log viewer, and enable logging. .. versionchanged:: 4.2 The log viewer got added to Krita in 4.2, so for older versions of Krita, you will need to either run Krita in the terminal if you have Linux or MacOS, or for Windows install `DebugView `_ from the official Microsoft site, start DebugView and then start Krita. When using a terminal, make sure to enable 'unlimited scrollback'. #. Press the :kbd:`Ctrl + Shift + T` shortcut, you will see a message box telling the logging has started. #. Try to reproduce your problem, you will be able to see the log being created in the log viewer as you draw. #. Save the output from the log viewer into a txt file, and attach it to the bugreport. On Linux, it is also useful to have the following information: #. ``lsmod`` #. ``xinput`` #. ``xinput list-props`` (id can be fetched from the item 2) However, in 100\% of the cases where Windows users have reported that their tablet didn't work over the past five years, the problem has been either a buggy driver or a broken driver installation, but not a bug in Krita. How to fix a tablet offset on multiple screen setup on Windows -------------------------------------------------------------- If you see that your tablet pointer has an offset when working with Krita canvas, it might be highly likely that Krita got an incorrect screen resolution from the system. That problem happens mostly when an external monitor is present and when either a monitor or a tablet was connected after the system booted. You can configure this by going to the :ref:`tablet_settings`. Microsoft Surface Pro and N-Trig -------------------------------- Krita 3.3.0 and later supports the Windows Pointer API (Windows Ink) natively. Your Surface Pro or other N-Trig enabled pen tablet should work out of the box with Krita after you enable Windows Ink in :menuselection:`Settings --> Configure Krita... --> Tablet`. Tablet Pro and the Surface Pro ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Unlike Wacom's Companion, the Surface line of tablets doesn't have working hardware buttons. Tablet Pro is a (non-free) utility that puts virtual buttons on screen. Krita 3.1 and above will have predefined shortcut profiles to work with Tablet Pro. https://tabletpro.com/ See https://www.youtube.com/watch?v=WKXZgYqC3tI for instructions. Weird stuff happens on Windows, like ripples, rings, squiggles or poltergeists ------------------------------------------------------------------------------ Windows comes with a lot of settings to make it work with a pen. All these settings can be annoying. This tool can help you set the settings correctly when you're using a tablet: https://github.com/saveenr/Fix_My_Pen/releases Touch doesn't seem to work on Windows ------------------------------------- You might have to disable and enable the touch driver: go to the device manager. (Click the :guilabel:`Start` button and type device manager). Choose HID (User interface devices or something like that). Choose Intel(R) Precise Touch Device. Right click, Disable it. Right click, Enable it. Toolbox ======= Toolbox missing --------------- You can reset the Workspace by pressing the right most button on the toolbar, the Workspace switcher, and click on a desired Workspace from the list. Or you can right-click on any docker title bar or open space in any toolbar, and select Toolbox. It's the first option. Also, you can check the :guilabel:`Settings` menu, it has got a lot of interesting stuff, then go to the Dockers menu and select :guilabel:`Toolbox`. Tool icons size is too big -------------------------- Right click the toolbox to set the size. Krita can't get maximized ------------------------- This happens when your dockers are placed in such a way that the window cannot be made less high. Rearrange your Workspace. Resources ========= Is there a way to restore a default brush that I have mistakenly overwritten with new settings to default? ---------------------------------------------------------------------------------------------------------- Yes. First go to the resource folder, which is in Linux :file:`$HOME/.local/share/krita/` Windows :file:`user\\Appdata\\Roaming\\krita\\` or :file:`%APPDATA%\\Roaming\\krita\\` OSX :file:`~/Library/Application Support/Krita/` You can easily do this by going into :menuselection:`Settings --> Manage Resources... --> Open Resource Folder`. Then go into the *paintoppresets* folder and remove the latest created file that you made of your preset. After that go back to the resources folder and edit the blacklist file to remove the previous paintoppreset so Krita will load it. (Yes, it is a bit of a convoluted system, but at the least you don't lose your brushes) How do I set favorite presets? ------------------------------ Right-click a brush in the brush docker and assign it a tag. Then right-click on canvas to call popup palette, click the second right-most icon on the bottom-right of the palette, now you can pick the tag which contains the brush you assigned to it. Can Krita load Photoshop Brushes? --------------------------------- Yes, but there are limitations. You can load ABR files by using the :guilabel:`Import` button in the :guilabel:`Predefined brush` tab in the brush editor. Since Adobe hasn’t disclosed the file format specification, we depend on reverse-engineering to figure out what to load, and currently that’s limited to basic features. Krita is slow ============= There is a myriad of reasons why this might be. Below is a short checklist. - Something else is hogging the CPU or the memory: spotify and other electron apps have been known to do this. - You are running Windows, and have 3rdparty security software like Sandboxie or Total Defender installed - You are working on images that are too big for your hardware (dimensions, channel depth or number of layers) - You do not have canvas acceleration enabled - You have (NVidia) Vertical Sync enabled Please also check `this page `_. Slow start-up ------------- You probably have too many resources installed. Deactivate some bundles under the :menuselection:`Settings --> Manage Resources...` menu item. -If you're using Windows with the portable zip file, Windows will scan all files every time you start Krita. That takes ages. Either use the installer or tell Microsoft Security Essentials to make an exception for Krita. +If you're using Windows with the portable ZIP file, Windows will scan all files every time you start Krita. That takes ages. Either use the installer or tell Microsoft Security Essentials to make an exception for Krita. Slow Brushes ------------ - Check if you accidentally turned on the stabilizer in the tool options docker. - Try another scaling mode like trilinear. :menuselection:`Settings --> Configure Krita... --> Display`. - Try a lower channel depth than 16-bit. - For NVidia, try a 16-bit floating point color space. - For older AMD CPU's (Krita 2.9.10 and above), turn off the vector optimizations that are broken on AMD CPUs. :menuselection:`Settings --> Configure Krita... --> Performance`. This isn't needed if you've got an AMD Threadripper™ CPU. - It's a fairly memory hungry program, so 2GB of RAM is the minimum, and 4GB is the preferable minimum. - Check that nothing else is hogging your CPU. - Check that Instant Preview is enabled if you're using bigger brushes (but for very small brushes, make sure is disabled). - Set brush precision to 3 or auto. - Use a larger value for brush spacing. - If all of this fails, record a video and post a link and description on the Krita forum. - Check whether OpenGL is enabled, and if it isn't, enable it. If it is enabled, and you are on Windows, try the Angle renderer. Or disable it. Slowdown after a been working for a while ----------------------------------------- Once you have the slowdown, click on the image-dimensions in the status bar. It will tell you how much RAM Krita is using, if it has hit the limit, or whether it has started swapping. Swapping can slow down a program a lot, so either work on smaller images or turn up the maximum amount of RAM in :menuselection:`Settings --> Configure Krita... --> Performance --> Advanced Tab`. Animation ========= Why is my animation black in my video player -------------------------------------------- You did not render the animation using the "baseline" option and you are using the default Windows media player. Re-render using the baseline option or use a better video player application, like VLC. Check `this useful diagram `_. Tools ===== Why does the Transform Tool give a good result and then get blurry upon finalizing? ----------------------------------------------------------------------------------- The transform tool makes a preview that you edit before computing the finalized version. As this preview is using the screen resolution rather than the image resolution, it may feel that the result is blurry compared to the preview. See `this page `__ for more info. License, rights and the Krita Foundation ======================================== Who owns Krita? --------------- The Stichting Krita Foundation owns the Krita trademark. The copyright on the source code is owned by everyone who has worked on the source code. Who and what is Kiki? --------------------- Kiki is a cybersquirrel. She’s our mascot and has been designed by Tyson Tan. We choose a squirrel when we discovered that ‘krita’ is the Albanian word for Squirrel. Why is Krita Free? ------------------ Krita is developed as `free software `_ within the KDE community. We believe that good tools should be available for all artists. You can also buy Krita on the Windows Store if you want to support Krita's development or want to have automatic updates to newer versions. Why isn't Krita on Steam and in the Windows Store Free? ------------------------------------------------------- Krita on Steam and in the Windows Store is still Free and Open Source software; the binaries are exactly the ones you can also download from krita.org. We've put a price tag on downloading Krita from either store to support Krita's development. Nobody is getting rich out of it, but the income from Steam and the Windows Store currently pays for the full-time involvement with Krita of four developers. See `Krita Available from the Windows Store `_ for more information. Can I use Krita commercially? ----------------------------- Yes. What you create with Krita is your sole property. You own your work and can license your art however you want. Krita’s GPL license applies to Krita’s source code. Krita can be used commercially by artists for any purpose, by studios to make concept art, textures, or vfx, by game artists to work on commercial games, by scientists for research, and by students in educational institutions. If you modify Krita itself, and distribute the result, you have to share your modifications with us. Krita’s GNU GPL license guarantees you this freedom. Nobody is ever permitted to take it away. .. _krita_android: .. _krita_ios: Can I get Krita for iPad? for Android? -------------------------------------- Not for iOS or iPadOS at this point in time. Android is being worked on, but it will not have a phone or tablet, but the same desktop ui as always. Who translates Krita -------------------- Krita is a `KDE application `_ — and proud of it! That means that Krita’s translations are done by `KDE localization teams `_. If you want to help out, join the team for your language! There is another way you can help out making Krita look good in any language, and that is join the development team and fix issues within the code that make Krita harder to translate. Reference ========= https://answers.launchpad.net/krita-ru/+faqs diff --git a/contributors_manual/krita_manual_conventions.rst b/contributors_manual/krita_manual_conventions.rst index 1dbfa1dd5..5feef9f2b 100644 --- a/contributors_manual/krita_manual_conventions.rst +++ b/contributors_manual/krita_manual_conventions.rst @@ -1,553 +1,553 @@ .. meta:: :description: reStructuredText conventions for the Krita Manual. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier :license: GNU free documentation license 1.3 or later. .. _krita_markup_conventions: ======================================== Mark-up conventions for the Krita Manual ======================================== This details the style conventions for using restructured text for the Krita Manual. It's recommended to look over the `official specification `_ for reStructuredText, and given it lives on sourceforge, to save a copy to your harddrive (sourceforge has, at this time of writing, some issues with server uptime): User Manual: * `Primer `_ * `Quick Ref `_ * `Text Cheatsheet `_ Reference Documentation: * `Introduction `_ * `Markup `_ * `Directives `_ * `Roles `_ Sphinx specific docs: * `Sphinx' page on restructured text `_ -- This is useful for the specific sphinx directives and roles it uses to generate for example table of contents. There are differences between the official reStructuredText and the sphinx docs multiple ways to do things. This document specifies the suggested conventions to go with. .. contents:: Meta data --------- Each page should start with the following three things: 1. A meta description This is a general description of the page. It will be converted to an html meta tag which will be used by search engines:: .. meta:: :description: Description. 2. A list of authors and a license. This is just to keep track of who edited the page and to give credit. It should be in a comment so that it will not end up being easily readable by machines. The license of the whole manual is GDL 1.3 and should also be mentioned here:: .. metadata-placeholder :authors: - Author 1 - Author 2 :license: GNU free documentation license 1.3 or later. 3. Indexing terms. - These are comma-separated terms under which the page will be indexed in :ref:`genindex`. The generated index is quite useful for both pdf as well as people who are not sure what the exact name is of the term they are looking for. They are defined as follows:: + These are comma-separated terms under which the page will be indexed in :ref:`genindex`. The generated index is quite useful for both PDF as well as people who are not sure what the exact name is of the term they are looking for. They are defined as follows:: .. index:: Keyword, Keyword with Spaces, ! Main Definition Keyword 4. A label. This is so we can easily link to the page using ``:ref:`label_name```. Try to make this a nice variable name:: .. _label_name: After the label you will need to add a heading, as ``:ref:`label_name``` will refer to the heading to fill out its link-text. Headings -------- Headings will be done in the following order:: ############ Part/Section ############ For pages that have a lot of subpages. ========= Heading 1 ========= Start most manual pages with this. Heading 2 --------- Heading 3 ~~~~~~~~~ Heading 4 ^^^^^^^^^ Heading 5 ''''''''' Heading 6 """"""""" These conventions were more or less decided by `Pandoc `_'s mediawiki to reStructuredText conversion. If you need more than 4 headings, ask yourself first if the page hasn't gotten too complicated and needs splitting up. Sometimes you need to link to a subsection of a page, add a label above the heading in that case. Headers should not end with punctuation, as the header will be used as the link name when linking to a label. Linking ------- Linking is done with ``:ref:`label_name```. When you need an alternative link text, you use ``:ref:`actual text shown ```. Linking to external pages is done with ```url`_`` and ```link name `_``, which'll become `link name `_. `Pandoc `_ likes to turn these into ```link name`__`` and then add ``.. __ :url`` at the end of the document. This is a so-called 'anonymous hyperlink', meaning that depending on the order of the links appearing in the text the order of the links at the end of the text are associated with one another. If this sounds confusing and difficult, it is because it is. That is also the exact reason why we'd like to avoid links like these. Footnotes and further reading ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Footnotes can be made in 3 ways, the most common one is with autonumbering, as per reference: [#]_ is a reference to footnote 1, and [#]_ is a reference to footnote 2. .. [#] This is footnote 1. .. [#] This is footnote 2. .. [#] This is footnote 3. [#]_ is a reference to footnote 3. Here is a citation reference: [CIT2002]_ . .. [CIT2002] This is the citation. It's just like a footnote, except the label is textual. Citation can also be referenced with ```citation `_``. We don't actually use footnotes in the manual due to the fact that it is a little bit too academical for our readers. However, we do collect documents and links that give a little bit more information on a topic at the end of a page. Sphinx has the ``.. seealso::`` directive for linking to external links, while reStructuredText suggests to use ``.. rubic:: Footnotes`` for specifically collecting footnotes as that plays nice with LaTeX. Images ------ Use the image directive for images without captions:: .. image:: /images/sample.png :width: 800 :align: center :alt: an image. And figure directives for images with captions:: .. figure:: /images/sample.png :figwidth: 800 :align: center :alt: an image. A caption -- notice how the first letter is aligned with the :figwidth: option. The latter gives: .. figure:: /images/sample.png :figwidth: 800 :align: center :alt: an image. A caption -- notice how the first letter of the caption in the directive is aligned with the :figwidth: option. Images should go into the ``/images`` folder. By using ``/images`` instead of ``images``, sphinx will know the filepath isn't relative. In-text Markup -------------- You can make text *emphasized* and **strong** with a single asterisk and double respectively:: *emphasize* **strong** You cannot do both ***emphasized and strong***, so take a pick. You can :sub:`subscript text` and :sup:`superscript text` by using ``:sub:`text``` and ``:sup:`text```. However, use these super-sparingly! It is preferred to use the existing semantic markup in sphinx in any case, because that makes it easier for translators to make decisions about the nature of the text:: :menuselection:`Settings --> Configure Krita...` :guilabel:`File` :kbd:`Ctrl + Z` :program:`Krita` Avoid randomly bolding words. It does *not* make the text easier or friendlier to read. Substitution References ----------------------- You can create a sort of shorthand for a piece of text or an image by doing:: .. |shorthand| replace:: something or the other. which means that if you use ``|shorthand|``, in the text, it'll be replaced with 'something or the other'. This is useful for images and text that needs to be formatted in a complicated way, like in the case of "LaTeX". The krita documentation has ``|mouseleft|``, ``|mousemiddle|``, ``|mousescroll|`` and ``|mouseright|``, which'll turn into |mouseleft|, |mousemiddle|, |mousescroll| and |mouseright| respectively. These are defined in the sphinx conf.py, and are appended to each rst file. For links, if you reuse the same link over and over, you can write something like the following at the end of the file:: .. _bugzilla: https://bugs.kde.org/ .. _Krita Manual: https://docs.krita.org/ Then, when typing a link, you can just use ```bugzilla`_`` to link to bugzilla with "bugzilla" used as the text of the link. ```Krita Manual`_`` will in turn link to docs.krita.org with the text "Krita Manual". Lists ----- Ordinated lists ~~~~~~~~~~~~~~~ 1. Apple 2. Pear 3. Banana Or... A. Table B. Chair C. Wardrobe. I. Augustus #. Nero #. Caligula #. Trajan They can be defined as follows:: 1. Apple 2. Pear 3. Banana #. Apple #. Pear #. Banana A. Table B. Chair C. Wardrobe A. Table #. Chair #. Wardrobe I. Augustus #. Nero #. Caligula #. Trajan Unordered lists ~~~~~~~~~~~~~~~ - red - yellow - green - seagreen - verdigris - teal - viridian - emerald - dark emerald - light emerald - very light emerald. - blue Defined as such:: - red - yellow - green - seagreen - verdigris - teal - viridian - emerald - dark emerald - light emerald - very light emerald. - blue Definition Lists ~~~~~~~~~~~~~~~~ A favourite! Definition lists are especially useful when dealing with enumerating all the options in a docker and trying to add a simple explanation behind them. Definition Explanation. Another option Explanation. To make them. You can make them like this:: Definition Explanation. Another option Explanation. Tables ------ ================== ============ Purpose Table type ================== ============ listing shortcuts Simple table lots of colspans Grid table Simple but long List Table ================== ============ Done as follows:: ================== ============ Purpose Table type ================== ============ listing shortcuts Simple table lots of colspans Grid table Simple but long List Table ================== ============ +-----------------+------------+ |Purpose |Table Type | +=================+============+ |listing shortcuts|Simple table| +-----------------+------------+ |lots of colspans |Grid table | +-----------------+------------+ |Simple but long |List table | +-----------------+------------+ .. list-table:: :header-rows: 1 - * Purpose * Table Type - * listing shortcuts * simple table - * lots of colspans * grid table - * simple but long * list table Full grid tables are best for when you need all features like complex column and row spans, but they're tricky to make. For that reason, small tables are best off being done with the simple syntax, while really long tables are best done with a list directive because that is just much easier to write and maintain. Admonishments and asides ------------------------ .. note:: Admonishments are sort of like a separate section that the reader needs to pay attention to. Admonishments that can be used are the following (in order of seriousness): .. hint:: Hints are useful to give a little bit more information on a topic than is useful in the main text. Like, "These packages are named differently in openSuse versus Debian". .. tip:: Extra information on how to do something, like, "You can make a template of your favourite document setup", or "Use m to mirror the canvas and see errors more easily in your drawing". .. important:: Something that is important to note, but is not necessarily negative. .. warning:: This is in general when something is negative. .. attention:: General attention grabber. Use this when the subject is more important than warning, but not as important that is could get a dataloss. .. caution:: This is for things that could cause dataloss, like forgetting to save, or that Python currently has no undo functionality. .. danger:: This should be for things that are dangerous for the computer in general, this includes things that can cause out of memory style freezes. .. error:: This one is probably not relevant for a manual. Sphinx can create these manually given some situations, but our configuration does not do so by default. .. admonition:: Generic admonition that can have any text Text. You can make it like this:: .. admonition:: Generic admonition that can have any text Text. Sphinx also adds:: .. seealso:: Which is useful to collect external links and references. .. Topic:: Horizontal Rulers Horizontal rulers are usually used when the topic switches rather directly. This is very common in more narrative based writing, such as history or fiction. The Krita manual is more instruction and reference style writing, that is to say, we don't usually tell a long story to indicate how different elements come together, but rather long stories are there to motivate why certain steps are taken in a certain manner. Topic changes then usually happen because we go into a new section, rather than switching to a related section. It is therefore better to use headings or the ``.. Topic::`` directive. Headings also make it easier to read. ---------------- That said, horizontal rulers can be made with ``----``. .. rubric:: The rubric directive The rubric directive is a heading directive that at first glance looks like "topic", but where the topic is over several paragraphs, rubric itself only deals with the header, like so:: .. rubric:: The rubric directive .. rubric:: So, when to use these? Only use them when you think the subject is too minor to have a proper heading. Topic When the text is separated from the flow, so it goes into a different subject than the text itself is naturally going to. Rubric When the text isn't separated from the flow, but it does not need a header either. Admonishments Only when they fit semantically. This is especially necessary for the danger and warning admonishments, as seeing them too often can make users blind to them. Code Snippets ------------- ``Inline code snippets`` are done with ````backticks````. Multi-line code snippets are done by ending the previous section with ``::``, which'll look like this:: This is a paragraph, and we define a preformated snippet like so:: Be sure to add a white space and a tab afterwards before starting the snippet. You can also use the ``.. code::`` directive. If you add the language name after it, it'll do the appropriate syntax highlighting:: .. code:: python # Python comment def my_function(): alist = [] alist.append(1) string = "hello world" Becomes .. code:: python # Python comment def my_function(): alist = [] alist.append(1) string = "hello world" some more... .. code:: c++ // C++ comment int myFunction(int i) { i += 1; // Check if more than 12 if (i>12) { i = 0; } return i; } .. code:: css /* CSS comment */ body { margin: 0 auto; /* is 800 still sensible? */ max-width:800px; font-size:16px; color:#333; background-color: #eee; padding:1em; font-family:serif; line-height: 1.4; } .. code:: html

this is a paragraph.

Other preformatted text ----------------------- | One can | preformat | text by | prepending | each line | with a pipe | symbol Like so:: | One can | preformat | text by | prepending | each line | with a pipe | symbol We don't actually use this anywhere in the manual. Glossaries, Terms and Index --------------------------- These are sphinx features. Index is used in the top section, right now only single index entries are used. Glossaries are used for some of the menu entry sections, but not all of them. Quotes ------ Quotes are done like this:: I am not sure why you'd need quotes in a user manual... -- Wolthera This becomes a blockquote. I am not sure why you'd need quotes in a user manual... -- Wolthera We do actually use quotes in some places. Try to add a link to the name to define where it came from. diff --git a/contributors_manual/krita_manual_readme.rst b/contributors_manual/krita_manual_readme.rst index e792a413f..d3742dd44 100644 --- a/contributors_manual/krita_manual_readme.rst +++ b/contributors_manual/krita_manual_readme.rst @@ -1,466 +1,466 @@ .. meta:: :description: Contributor's Readme for the Krita Manual. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier - Micheal Abrahams - Agata Cacko :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 .. _KDE_gitlab : https://invent.kde.org/ .. _Manual Project Workboard : https://phabricator.kde.org/project/view/135/ .. _repository : https://invent.kde.org/websites/docs-krita-org/tree/master .. _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. .. _merge-request-diff: Sending patches to Phabricator ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Recommended for users without a technical knowledge who don't plan on contributing more to the project. Not recommended when you plan to contribute more in the future. (See :ref:`merge-request-edit` if you don't have technical knowledge and want to contribute to Krita Manual more than once). 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 the manual. -4. Bundle up the items into a zip. +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. + 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. +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. + 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. .. _merge-request-edit: Creating merge requests using Edit mode ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Recommended for users without a technical knowledge. Not recommended when you want to change more than one file at once. (See :ref:`merge-request-webide` or :ref:`merge-request-terminal` if you want to change more files, or simply edit only one per merge request). If you have a lot of changes you want to contribute, we recommend trying to follow these instructions. #. Get a KDE identity. #. Login to `KDE_gitlab`_. #. Go to the `repository`_ and press :guilabel:`fork`. #. You should be redirected to the fork of your repository now. Typically it's located at ``invent.kde.org/YOUR_KDE_LOGIN_NAME/docs-krita-org``. #. Come back to the official repository. Make sure you're browsing ``Websites/Krita Documentation``, not your own fork. Otherwise this method won't work correctly. #. Gitlab has an option to Edit files in the gitlab itself. To access this, go to :menuselection:`Repository --> Files`. #. At the top of the page you should see a dropbox with ``master`` as a chosen item. #. Find the file you want to edit, open it and then click :guilabel:`Edit`. #. Make your changes. (Note: in this mode you can edit only one file at a time). #. Go to the smaller textbox below and write a nice message in the commit message section with the changes you've made. When done, press :guilabel:`Commit changes`. This will make a merge request for you, just fill in all of the fields as explained here: :ref:`new-merge-request`. The downside is that right now there's no way to tell if you made errors with the mark up using this method. Please check your changes with the `Online Sphinx Editor `_ (just copy and paste the entire file you're editing). .. attention:: :guilabel:`Edit` and :guilabel:`WebIDE` are two different things! Make sure you select :guilabel:`Edit`. .. image:: /images/gitlab/screenshot_editmode.png :width: 1000px .. _merge-request-webide: Creating merge requests using WebIDE ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Recommended for users with a bit of knowledge about Git that want to edit multiple files at once. Not recommended when you don't know what a branch is (see :ref:`merge-request-edit` instead). #. Follow the instructions above to login to `KDE_gitlab`_ and create your fork. #. Go to your fork (make sure the url contains your username). #. Make sure you're on the ``master`` branch. #. Click :guilabel:`WebIDE`. This should take you to a page that has a list of files on the left side and a big empty space for file contents on the right side. #. Open the files you want to edit and make the changes. #. Click :guilabel:`Commit...`. Double-click on all files in the :guilabel:`Unstaged changes` category to move them to :guilabel:`Staged changes`. #. Click :guilabel:`Commit...` again - it will expand a commit message textbox. Write commit message that explains what changes have you made and why. #. Make sure the settings are correct: you need to select :guilabel:`Create a new branch` (the name of the branch should be: ``[username]/[very short description of your changes]``). If you finished your changes, make sure that :guilabel:`Start a new merge request` is checked. Otherwise you'll need to make a new merge request manually later. #. Click :guilabel:`Stage & Commit`. #. Fill all of the fields correctly: see :ref:`new-merge-request`. #. To create a new merge request manually, go to Krita Manual official repository (make sure the url *doesn't* contain your username now) and click :guilabel:`Create a new merge request` (bright green button at the left). Select your fork and select the branch that you've created in WebIDE. .. .. image:: /images/gitlab/screenshot_webidemode.png .. :width: 1000px .. note:: If you don't have a push access to the official repository, gitlab won't allow you to save your changes if you were editing the official repository by mistake (and :guilabel:`Create a merge request` won't help with that: you still need to commit your changes to your branch, but if you don't have push access, you can't do it). It will just show the message: *An error occurred whilst committing your changes. Please try again.* In this case, simply copy contents of all of the files you changed, go to your fork and paste them in the fork WebIDE. .. _merge-request-terminal: Creating merge requests using command line ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Recommended for users that know how Git works and how to use command line. Not recommended when you don't know what a branch is (see :ref:`merge-request-edit` instead). #. Follow the instructions above to login to `KDE_gitlab`_ and create your fork. #. Clone the repository locally with :guilabel:`git clone`. The repository page has the urls you can perform git clone from, and you can then push to your fork. The advantage of this is that you can use all the tools on your computer to edit these text files as well as build the manual locally to check for errors. (You need to do this step only once). .. code-block:: bash # for ssh access git clone git@invent.kde.org:/krita.git git remote add upstream git@invent.kde.org:kde/krita.git # for https access git clone https://invent.kde.org//krita.git git remote add upstream https://invent.kde.org/kde/krita.git #. Remember to always pull changes from the official repository before making new changes: .. code-block:: bash git pull upstream master #. Make sure you create a new branch for your changes, since september 2019, all changes should be branched from ``master``. .. code-block:: bash git checkout master # and then: git checkout -b "/" #. After you make your changes, commit them and push to your fork. For a detailed description of how to use Git in terminal in case of this workflow, go to :ref:`forking_gitlab`. .. code-block:: bash # make sure everything is correct make html git status git diff # add all of the files git add . # commit your changes git commit # submit your changes to your fork git push #. Finally, go to the website of the original repository, and then to Merge Requests. Select your fork and the correct branch and create a new merge request. For instruction on how to fill the fields, see :ref:`new-merge-request`. .. _new-merge-request: Guidelines for new merge requests ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ #. Your commit messages should conform to standards explained here: `How to Write a Git Commit Message `_ #. :guilabel:`Title` and :guilabel:`Description` should explain what changes did you make and why did you make them, just like a commit message, so follow the guidelines from the link above in this case, too. #. :guilabel:`Target` should point to ``master``. #. If you're sure the merge request will demand some changes later, start the title of your merge request with :code:`[WIP]`. #. Make sure you checked :guilabel:`Allow commits from members who can merge to the target branch.` -- it is often needed for technical reasons that merge request is rebased on master, which technically changes the merge request, but it doesn't change the actual content of it. Rebase can be done by you or by the reviewer -- if you don't want to be bothered later too much, better check this checkbox so the reviewer can do it themselves with only a few clicks. #. You can safely check :guilabel:`Delete source branch when merge request is accepted` in most cases. #. Unless your reviewers tell you otherwise, check :guilabel:`Squash commits when merge request is accepted`. The first line of the commit message will come from the :guilabel:`Title` of your merge request and the rest of it will be taken from the :guilabel:`Description` of the merge request. #. When you finish creating your merge request, go to IRC and ask someone with push access to add the ``Needs Review`` label on your merge request. #. You might get feedback on your merge request if it has mistakes. Just fix the mistakes in your branch in one of the following ways. * If you want to use :guilabel:`Edit` mode, just go to :guilabel:`Changes` section of the merge request and click on the pencil icon (with a tooltip that says *Edit*) to use the Edit mode again. * If you want to use :guilabel:`WebIDE` mode, go to your fork, select the branch your changes are on and go to the WebIDE. * If you edit files on your computer and work with terminal, make sure you're on the correct branch and push your changes - gitlab will update your merge request automatically. After making changes, make sure you ask someone to change the label to ``Needs Review`` again. For more detailed information, check out :ref:`forking_gitlab` in the technical section. .. note:: At the time of writing this guide setting labels on merge requests is only possible by contributors with write access to the official repository. (If you don't know what that means, you're most probably not one of them). Because of that, when you create or change your merge request you need to get on IRC (see :ref:`the_krita_community`) and ask someone to label it for you. 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. +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. + 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 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 merge 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 `KDE_gitlab`_ in two ways: 1. Reviewing merge requests You can help review merge requests. Request 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 this to check against typos as well! A merge request, 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. Commenting on changes in the manual. Commenting changes happens after the fact. You can comment on 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 speech bubble icon to add an 'inline' comment. 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. Images can be translated if a translation team wants to provide their own images. All images in the image folder are by default for 'en'. When you want to translate a specific image, go into that folder and add another folder with your language code to add in the translated versions of images. So Sphinx will search for a dutch version of :file:`/images/Pixels-brushstroke.png` at :file:`/images/nl/Pixels-brushstroke.png` and for a dutch version of :file:`/images/dockers/Krita-tutorial2-I.1-2.png` in :file:`/images/dockers/nl/Krita-tutorial2-I.1-2.png`. 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/contributors_manual/optimising_images.rst b/contributors_manual/optimising_images.rst index 7a4fcfd43..32e47f8ed 100644 --- a/contributors_manual/optimising_images.rst +++ b/contributors_manual/optimising_images.rst @@ -1,268 +1,268 @@ .. meta:: :description: How to make and optimise images for use in the manual. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier :license: GNU free documentation license 1.3 or later. .. index:: Metadata, Optimising Images .. _images_for_manual: ===================== Images for the Manual ===================== This one is a little bit an extension to :ref:`saving_for_the_web`. In particular it deals with making images for the manual, and how to optimise images. .. contents:: Tools for making screenshots ---------------------------- Now, if you wish to make an image of the screen with all the dockers and tools, then :ref:`saving_for_the_web` won't be very helpful: It only saves out the canvas contents, after all! So, instead, we'll make a screenshot. Depending on your operating system, there are several screenshot utilities available. Windows ~~~~~~~ Windows has a build-in screenshot tool. It is by default on the :kbd:`Print Screen` key. On laptops you will sometimes need to use the :kbd:`Fn` key. Linux ~~~~~ Both Gnome and KDE have decent screenshot tools showing up by default when using the :kbd:`Print Screen` key, as well do other popular desktop environments. If, for whatever reason, you have no ImageMagick With imagemagick, you can use the following command:: import -depth 8 -dither -While we should minimize the amount of gifs in the manual for a variety of accessibility reasons, you sometimes still need to make gifs and short videos. Furthermore, gifs are quite nice to show off features with release notes. +While we should minimize the amount of GIFs in the manual for a variety of accessibility reasons, you sometimes still need to make GIFs and short videos. Furthermore, GIFs are quite nice to show off features with release notes. -For making short gifs, you can use the following programs: +For making short GIFs, you can use the following programs: * `Peek `_ -- This one has an appimage and a very easy user-interface. Like many screenrecording programs it does show trouble on Wayland. OS X ~~~~ The Screenshot hotkey on OS X is :kbd:`Shift + Command + 3`, according to `the official apple documentation `_. The appropriate file format for the job --------------------------------------- Different file formats are better for certain types of images. In the end, we want to have images that look nice and have a low filesize, because that makes the manual easier to download or browse on the internet. GUI screenshots - This should use png, and if possible, in gif. + This should use PNG, and if possible, in GIF. Images that have a lot of flat colors. - This should use png. + This should use PNG. Grayscale images - These should be gif or png. + These should be GIF or PNG. Images with a lot of gradients These should be JPG. Images with a lot of transparency. These should use PNG. -The logic is the way how each of these saves colors. Jpeg is ideal for photos and images with a lot of gradients because it :ref:`compresses differently `. However, contrasts don't do well in jpeg. PNG does a lot better with images with sharp contrasts, while in some cases we can even have less than 256 colors, so gif might be better. +The logic is the way how each of these saves colors. JPEG is ideal for photos and images with a lot of gradients because it :ref:`compresses differently `. However, contrasts don't do well in JPEG. PNG does a lot better with images with sharp contrasts, while in some cases we can even have less than 256 colors, so GIF might be better. -Grayscale images, even when they have a lot of gradients variation, should be PNG. The reason is that when we use full color images, we are, depending on the image, using 3 to 5 numbers to describe those values, with each of those values having a possibility to contain any of 256 values. JPEG and other 'lossy' file formats use clever psychological tricks to cut back on the amount of values an image needs to show its contents. However, when we make grayscale images, we only keep track of the lightness. The lightness is only one number, that can have 256 values, making it much easier to just use gif or PNG, instead of jpeg which could have nasty artifacts. (And, it is also a bit smaller) +Grayscale images, even when they have a lot of gradients variation, should be PNG. The reason is that when we use full color images, we are, depending on the image, using 3 to 5 numbers to describe those values, with each of those values having a possibility to contain any of 256 values. JPEG and other 'lossy' file formats use clever psychological tricks to cut back on the amount of values an image needs to show its contents. However, when we make grayscale images, we only keep track of the lightness. The lightness is only one number, that can have 256 values, making it much easier to just use GIF or PNG, instead of JPEG which could have nasty artifacts. (And, it is also a bit smaller) **When in doubt, use PNG.** Optimising Images in quality and size ------------------------------------- Now, while most image editors try to give good defaults on image sizes, we can often make them even smaller by using certain tools. Windows ~~~~~~~ The most commonly recommended tool for this on Windows is `IrfranView `_, but the dear writer of this document has no idea how to use it exactly. The other option is to use PNGCrush as mentioned in the linux section. Linux ~~~~~ Optimising PNG ^^^^^^^^^^^^^^ There is a whole laundry list of `PNG optimisation tools `_ available on Linux. They come in two categories: Lossy (Using psychological tricks), and Lossless (trying to compress the data more conventionally). The following are however the most recommended: `PNGQuant `_ A PNG compressor using lossy techniques to reduce the amount of colors used in a smart way. To use PNGquant, go to the folder of choice, and type:: pngquant --quality=80-100 image.png Where *image* is replaced with the image file name. When you press the :kbd:`Enter` key, a new image will appear in the folder with the compressed results. PNGQuant works for most images, but some images, like the color selectors don't do well with it, so always double check that the resulting image looks good, otherwise try one of the following options: `PNGCrush `_ A lossless PNG compressor. Usage:: pngcrush image.png imageout.png This will try the most common methods. Add ``-brute`` to try out all methods. `Optipng `_ Another lossless PNG compressor which can be run after using PNGQuant, it is apparently originally a fork of png crush. Usage:: optipng image.png - where image is the filename. OptiPNG will then proceed to test several compression algorithms and **overwrite** the image.png file with the optimised version. You can avoid overwriting with the ``--out imageout.png`` command. + where image is the filename. OptiPNG will then proceed to test several compression algorithms and **overwrite** the *image.png* file with the optimised version. You can avoid overwriting with the ``--out imageout.png`` command. Optimising GIF ^^^^^^^^^^^^^^ * `FFmpeg `_ * `Gifski `_ * `LossyGif `_ Optimising JPEG ^^^^^^^^^^^^^^^ Now, JPEG is really tricky to optimize properly. This is because it is a :ref:`lossy file format `, and that means that it uses psychological tricks to store its data. However, tricks like these become very obvious when your image has a lot of contrast, like text. Furthermore, JPEGs don't do well when they are resaved over and over. Therefore, make sure that there's a lossless version of the image somewhere that you can edit, and that only the final result is in JPEG and gets compressed further. MacOS/ OS X ~~~~~~~~~~~ * `ImageOptim `_ -- A Graphical User Interface wrapper around commandline tools like PNGquant and gifski. Editing the metadata of a file ------------------------------ Sometimes, personal information gets embedded into an image file. Othertimes, we want to embed information into a file to document it better. There are no less than 3 to 4 different ways of handling metadata, and metadata has different ways of handling certain files. The most commonly used tool to edit metadata is :program:`ExifTool`, another is to use :program:`ImageMagick`. Windows and OS X ~~~~~~~~~~~~~~~~ To get exiftool, `just get it from the website `_. Linux ~~~~~ On Linux, you can also install exiftool. Debian/Ubuntu ``sudo apt-get install libimage-exiftool-perl`` Viewing Metadata ~~~~~~~~~~~~~~~~ Change the directory to the folder where the image is located and type:: exiftool image where image is the file you'd like to examine. If you just type ``exiftool`` in any given folder it will output all the information it can give about any file it comes across. If you take a good look at some images, you'll see they contain author or location metadata. This can be a bit of a problem sometimes when it comes to privacy, and also the primary reason all metadata gets stripped. You can also use `ImageMagick's identify `_:: identify -verbose image Stripping Metadata ~~~~~~~~~~~~~~~~~~ Stripping metadata from the example ``image.png`` can be done as follows: `ExifTool `_ `exiftool -all= image.png` This empties all tags exiftool can get to. You can also be specific and only remove a single tag: `exiftool -author= image.png` OptiPNG `optipng -strip image.png` This will strip and compress the png file. `ImageMagick `_ `convert image.png --strip` Extracting metadata ~~~~~~~~~~~~~~~~~~~ -Sometimes we want to extract metadata, like an icc profile, before stripping everything. This is done by converting the image to the profile type: +Sometimes we want to extract metadata, like an ICC profile, before stripping everything. This is done by converting the image to the profile type: `ImageMagick's Convert `_ First extract the metadata to a profile by converting:: convert image.png image_profile.icc Then strip the file and readd the profile information:: convert -profile image_profile.icc image.png Embedding description metadata ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Description metadata is really useful for the purpose of helping people with screenreaders. Webbrowsers will often try to use the description metadata if there's no alt text to generate the alt-text. Another thing that you might want to embed is stuff like color space data. ExifTool ImageMagick Setting an exif value:: convert -set exif:ImageDescription "An image description" image.png image_modified.png Setting the PNG chunk for description:: convert -set Description "An image description" image.png image_modified.png Embedding license metadata ~~~~~~~~~~~~~~~~~~~~~~~~~~ In a certain way, embedding license metadata is really nice because it allows you to permanently mark the image as such. However, if someone then uploads it to another website, it is very likely the metadata is stripped with imagemagick. Using Properties ^^^^^^^^^^^^^^^^ You can use dcterms:license for defining the document where the license is defined. ImageMagick For the GDPL:: convert -set dcterms:license "GDPL 1.3+ https://www.gnu.org/licenses/fdl-1.3.txt" image.png This defines a shorthand name and then license text. For Creative Commons BY-SA 4.0:: convert -set dcterms:license "CC-BY-SA-4.0 https://creativecommons.org/licenses/by-sa/4.0/" image.png The problem with using properties is that they are a non-standard way to define a license, meaning that machines cannot do much with them. Using XMP ^^^^^^^^^ The creative commons website suggest we `use XMP for this `_. You can ask the Creative Commons License choose to generate an appropriate XMP file for you when picking a license. We'll need to use the `XMP tags for exiftool `_. So that would look something like this:: exiftool -Marked=true -License="https://creativecommons.org/licenses/by-sa/4.0" -UsageTerms="This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License." -Copyright="CC-BY-SA-NC 4.0" image.png Another way of doing the marking is:: exiftool -Marked=true -License="https://creativecommons.org/licenses/by-sa/4.0" -attributionURL="docs.krita.org" attributionName="kritaManual" image.png With imagemagick you can use the profile option again. First extract the data (if there is any):: convert image.png image_meta.xmp Then modify the resulting file, and embed the image data:: convert -profile image_meta.xmp image.png The XMP definitions per license. You can generate an XMP file for the metadata on the creative commons website. diff --git a/general_concepts/colors/color_space_size.rst b/general_concepts/colors/color_space_size.rst index 13990a2c8..1a47e3a2c 100644 --- a/general_concepts/colors/color_space_size.rst +++ b/general_concepts/colors/color_space_size.rst @@ -1,49 +1,49 @@ .. meta:: :description: About Color Space Size .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier :license: GNU free documentation license 1.3 or later. .. index:: Color, Color Spaces .. _color_space_size: ================ Color Space Size ================ Using Krita's color space browser, you can see that there are many different space sizes. .. figure:: /images/color_category/Basiccolormanagement_compare4spaces.png :figwidth: 800 :align: center How do these affect your image, and why would you use them? There are three primary reasons to use a large space: #. Even though you can't see the colors, the computer program does understand them and can do color maths with it. #. For exchanging between programs and devices: most CMYK profiles are a little bigger than our default sRGB in places, while in other places, they are smaller. To get the best conversion, having your image in a space that encompasses both your screen profile as your printer profile. #. For archival purposes. In other words, maybe monitors of the future will have larger amounts of colors they can show (spoiler: they already do), and this allows you to be prepared for that. Let's compare the following gradients in different spaces: .. image:: /images/color_category/Basiccolormanagement_gradientsin4spaces_v2.jpg .. image:: /images/color_category/Basiccolormanagement_gradientsin4spaces_nonmanaged.png -On the left we have an artifact-ridden color managed jpeg file with an ACES sRGBtrc v2 profile attached (or not, if not, then you can see the exact different between the colors more clearly). This should give an approximation of the actual colors. On the right, we have an sRGB png that was converted in Krita from the base file. +On the left we have an artifact-ridden color managed JPEG file with an ACES sRGBtrc v2 profile attached (or not, if not, then you can see the exact different between the colors more clearly). This should give an approximation of the actual colors. On the right, we have an sRGB PNG that was converted in Krita from the base file. Each of the gradients is the gradient from the max of a given channel. As you can see, the mid-tone of the ACES color space is much brighter than the mid-tone of the RGB colorspace, and this is because the primaries are further apart. What this means for us is that when we start mixing or applying filters, Krita can output values higher than visible, but also generate more correct mixes and gradients. In particular, when color correcting, the bigger space can help with giving more precise information. If you have a display profile that uses a LUT, then you can use perceptual to give an indication of how your image will look. Bigger spaces do have the downside they require more precision if you do not want to see banding, so make sure to have at the least 16bit per channel when choosing a bigger space. diff --git a/general_concepts/colors/viewing_conditions.rst b/general_concepts/colors/viewing_conditions.rst index 9cd141eb0..72d6ba38e 100644 --- a/general_concepts/colors/viewing_conditions.rst +++ b/general_concepts/colors/viewing_conditions.rst @@ -1,93 +1,93 @@ .. meta:: :description: What are viewing conditions. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier :license: GNU free documentation license 1.3 or later. .. index:: Viewing Conditions, Metamerism, Color .. _viewing_conditions: ================== Viewing Conditions ================== We mentioned viewing conditions before, but what does this have to do with 'white points'? A lot actually, rather, white points describe a type of viewing condition. So, usually what we mean by viewing conditions is the lighting and decoration of the room that you are viewing the image in. Our eyes try to make sense of both the colors that you are looking at actively (the colors of the image) and the colors you aren't looking at actively (the colors of the room), which means that both sets of colors affect how the image looks. .. figure:: /images/color_category/Meisje_met_de_parel_viewing.png :figwidth: 800 :align: center **Left**: Let's ruin Vermeer by putting a bright purple background that asks for more attention than the famous painting itself. **Center**: a much more neutral backdrop that an interior decorator would hate but brings out the colors. **Right**: The approximate color that this painting is displayed against in real life in the Maurits House, at the least, last time I was there. Original image from wikipedia commons. This is for example, the reason why museum exhibitioners can get really angry at the interior decorators when the walls of the museum are painted bright red or blue, because this will drastically change the way how the painting's colors look. (Which, if we are talking about a painter known for their colors like Vermeer, could result in a really bad experience). .. figure:: /images/color_category/Krita_example_metamerism.png :figwidth: 500 :align: center Lighting is the other component of the viewing condition which can have dramatic effects. Lighting in particular affects the way how all colors look. For example, if you were to paint an image of sunflowers and poppies, print that out, and shine a bright yellow light on it, the sunflowers would become indistinguishable from the white background, and the poppies would look orange. This is called `metamerism `_, and it's generally something you want to avoid in your color management pipeline. An example where metamerism could become a problem is when you start matching colors from different sources together. .. figure:: /images/color_category/White_point_mix_up_ex1_01.svg :figwidth: 500 :align: center For example, if you are designing a print for a red t-shirt that's not bright red, but not super grayish red either. And you want to make sure the colors of the print match the color of the t-shirt, so you make a dummy background layer that is approximately that red, as correctly as you can observe it, and paint on layers above that dummy layer. When you are done, you hide this dummy layer and sent the image with a transparent background to the press. .. figure:: /images/color_category/White_point_mixup_ex1_02.png :figwidth: 300 :align: center But when you get the t-shirt from the printer, you notice that all your colors look off, mismatched, and maybe too yellowish (and when did that T-Shirt become purple?). This is where white points come in. You probably observed the t-shirt in a white room where there were incandescent lamps shining, because as a true artist, you started your work in the middle of the night, as that is when the best art is made. However, incandescent lamps have a black body temperature of roughly 2300-2800K, which makes them give a yellowish light, officially called White Point A. Your computer screen on the other hand, has a black body temperature of 6500K, also known as D65. Which is a far more blueish color of light than the lamps you are hanging. What's worse, Printers print on the basis of using a white point of D50, the color of white paper under direct sunlight. .. figure:: /images/color_category/White_point_mix_up_ex1_03.svg :figwidth: 500 :align: center So, by eye-balling your t-shirt's color during the evening, you took its red color as transformed by the yellowish light. Had you made your observation in diffuse sunlight of an overcast (which is also roughly D65), or made it in direct sunlight light and painted your picture with a profile set to D50, the color would have been much closer, and thus your design would not be as yellowish. .. figure:: /images/color_category/White_point_mixup_ex1_03.png :figwidth: 500 :align: center Applying a white balance filter will sort of match the colors to the tone as in the middle, but you would have had a much better design had you designed against the actual color to begin with. Now, you could technically quickly fix this by using a white balancing filter, like the ones in G'MIC, but because this error is caught at the end of the production process, you basically limited your use of possible colors when you were designing, which is a pity. Another example where metamerism messes things up is with screen projections. We have a presentation where we mark one type of item with red, another with yellow and yet another with purple. On a computer the differences between the colors are very obvious. .. figure:: /images/color_category/Krita_metamerism_presentation.svg :figwidth: 800 :align: center However, when we start projecting, the lights of the room aren't dimmed, which means that the tone scale of the colors becomes crunched, and yellow becomes near indistinguishable from white. Furthermore, because the light in the room is slightly yellowish, the purple is transformed into red, making it indistinguishable from the red. Meaning that the graphic is difficult to read. In both cases, you can use Krita's color management a little to help you, but mostly, you just need to be ''aware'' of it, as Krita can hardly fix that you are looking at colors at night, or the fact that the presentation hall owner refuses to turn off the lights. -That said, unless you have a display profile that uses LUTs, such as an OCIO LUT or a cLUT icc profile, white point won't matter much when choosing a working space, due to weirdness in the icc v4 workflow which always converts matrix profiles with relative colorimetric, meaning the white points are matched up. +That said, unless you have a display profile that uses LUTs, such as an OCIO LUT or a cLUT ICC profile, white point won't matter much when choosing a working space, due to weirdness in the ICC v4 workflow which always converts matrix profiles with relative colorimetric, meaning the white points are matched up. diff --git a/general_concepts/file_formats.rst b/general_concepts/file_formats.rst index c202c62c4..65726eb00 100644 --- a/general_concepts/file_formats.rst +++ b/general_concepts/file_formats.rst @@ -1,58 +1,58 @@ .. meta:: :description: The file formats category. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier :license: GNU free documentation license 1.3 or later. .. _general_concept_file_formats: ============ File Formats ============ This category is for graphics file-formats. While most file-formats can be looked up on wikipedia, this doesn't always explain what the format can be used for and what its strengths and weaknesses are. In this category we try to describe these in a manner that can be read by beginners. Generally, there are the following features that people pay attention to in regards to file formats: Compression ----------- Compression is how the file-format tries to describe the image with as little data as possible, so that the resulting file is as small as it can get without losing quality. What we generally see is that formats that are small on disk either lose image quality, or require the computer to spend a lot of time thinking about how the image should look. Vector file-formats like ``SVG`` are a typical example of the latter. They are really small because the technology used to create them is based on mathematics, so it only stores maths-variables and can achieve very high quality. The downside is that the computer needs to spend a lot of time thinking about how it should look, and sometimes different programs have different ways of interpreting the values. Furthermore, vector file-formats imply vector graphics, which is a very different way of working than Krita is specialized in. :ref:`Lossy file formats `, like ``JPG`` or ``WebP`` are an example of small on disk, but lowering the quality, and are best used for very particular types of images. Lossy thus means that the file format plays fast and loose with describing your image to reduce filesize. :ref:`Non-lossy or lossless formats `, like ``PNG``, ``GIF`` or ``BMP`` are in contrast, much heavier on disk, but much more likely to retain quality. Then, there's proper working file formats like Krita's ``KRA``, Gimp's ``XCF``, Photoshop's ``PSD``, but also interchange formats like ``ORA`` and ``EXR``. These are the heaviest on the hard-drive and often require special programs to open them up, but on the other hand these are meant to keep your working environment intact, and keep all the layers and guides in them. Metadata -------- -Metadata is the ability of a file format to contain information outside of the actual image contents. This can be human readable data, like the date of creation, the name of the author, a description of the image, but also computer readable data, like an icc-profile which tells the computer about the qualities of how the colors inside the file should be read. +Metadata is the ability of a file format to contain information outside of the actual image contents. This can be human readable data, like the date of creation, the name of the author, a description of the image, but also computer readable data, like an ICC profile which tells the computer about the qualities of how the colors inside the file should be read. Openness -------- This is a bit of an odd quality, but it's about how easy it to open or recover the file, and how widely it's supported. Most internal file formats, like PSD are completely closed, and it's really difficult for human outsiders to recover the data inside without opening Photoshop. Other examples are camera raw files which have different properties per camera manufacturer. SVG, as a vector file format, is on the other end of the spectrum, and can be opened with any text-editor and edited. Most formats are in-between, and thus there's also a matter of how widely supported the format is. JPG and PNG cannot be read or edited by human eyes, but the vast majority of programs can open them, meaning the owner has easy access to them. .. toctree:: :maxdepth: 1 :caption: Contents: :glob: file_formats/* diff --git a/general_concepts/file_formats/file_exr.rst b/general_concepts/file_formats/file_exr.rst index 2ea308b7b..3452650da 100644 --- a/general_concepts/file_formats/file_exr.rst +++ b/general_concepts/file_formats/file_exr.rst @@ -1,22 +1,22 @@ .. meta:: :description: The EXR file format as exported by Krita. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier :license: GNU free documentation license 1.3 or later. -.. index:: EXR, HDR Fileformat, OpenEXR, *.exr +.. index:: *.exr, EXR, HDR Fileformat, OpenEXR .. _file_exr: ====== \*.exr ====== ``.exr`` is the prime file format for saving and loading :ref:`floating point bit depths `, and due to the library made to load and save these images being fully open source, the main interchange format as well. Floating point bit-depths are used by the computer graphics industry to record scene referred values, which can be made via a camera or a computer renderer. Scene referred values means that the file can have values whiter than white, which in turn means that such a file can record lighting conditions, such as sunsets very accurately. These EXR files can then be used inside a renderer to create realistic lighting. Krita can load and save EXR for the purpose of paint-over (yes, Krita can paint with scene referred values) and interchange with applications like Blender, Mari, Nuke and Natron. diff --git a/general_concepts/file_formats/file_gbr.rst b/general_concepts/file_formats/file_gbr.rst index 14a053d90..26e8f9f40 100644 --- a/general_concepts/file_formats/file_gbr.rst +++ b/general_concepts/file_formats/file_gbr.rst @@ -1,28 +1,28 @@ .. meta:: :description: The GIMP Brush file format as used in Krita. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier :license: GNU free documentation license 1.3 or later. -.. index:: Gimp Brush, GBR, *.gbr +.. index:: *.gbr, GBR, Gimp Brush .. _file_gbr: ====== \*.gbr ====== The GIMP brush format. Krita can open, save and use these files as :ref:`predefined brushes `. There's three things that you can decide upon when exporting a ``*.gbr``: Name This name is different from the file name, and will be shown inside Krita as the name of the brush. Spacing This sets the default spacing. Use color as mask This'll turn the darkest values of the image as the ones that paint, and the whitest as transparent. Untick this if you are using colored images for the brush. GBR brushes are otherwise unremarkable, and limited to 8bit color precision. diff --git a/general_concepts/file_formats/file_gif.rst b/general_concepts/file_formats/file_gif.rst index 737005f0f..d91e37d83 100644 --- a/general_concepts/file_formats/file_gif.rst +++ b/general_concepts/file_formats/file_gif.rst @@ -1,19 +1,19 @@ .. meta:: :description: The GIF file format in Krita. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier :license: GNU free documentation license 1.3 or later. -.. index:: GIF, *.gif +.. index:: *.gif, GIF .. _file_gif: ====== \*.gif ====== ``.gif`` is a file format mostly known for the fact that it can save animations. It's a fairly old format, and it does its compression by :ref:`indexing ` the colors to a maximum of 256 colors per frame. Because we can technically design an image for 256 colors and are always able save over an edited GIF without any kind of extra degradation, this is a :ref:`lossless ` compression technique. This means that it can handle most grayscale images just fine and without losing any visible quality. But for color images that don't animate it might be better to use :ref:`file_jpg` or :ref:`file_png`. diff --git a/general_concepts/file_formats/file_gih.rst b/general_concepts/file_formats/file_gih.rst index 94bb29ab0..6569773d4 100644 --- a/general_concepts/file_formats/file_gih.rst +++ b/general_concepts/file_formats/file_gih.rst @@ -1,59 +1,59 @@ .. meta:: :description: The GIMP Image Hose file format in Krita. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier :license: GNU free documentation license 1.3 or later. -.. index:: Image Hose, Gimp Image Hose, GIH, *.gih +.. index:: *.gih, GIH, Image Hose, Gimp Image Hose .. _file_gih: ====== \*.gih ====== The GIMP image hose format. Krita can open and save these, as well as import via the :ref:`predefined brush tab `. Image Hose means that this file format allows you to store multiple images and then set some options to make it specify how to output the multiple images. .. figure:: /images/brushes/Gih-examples.png :figwidth: 640px :align: center From top to bottom: Incremental, Pressure and Random Dimension and ranks. -------------------- The GIMP image hose format allows multiple dimensions for a given brush. You could for example have a dimension that updates incrementally, and one that updates on pressure, or updates randomly. Upon export, Krita will use the ranks to subdivide the layers per dimension. If you have a 24 layer image and three ranks, and the first dimension is set to 2, the second to 4 and the third to 3, then Krita will divide 24 into 2 groups of 12, each of which have unique images for the 2 parts of the first dimension. Then those 2 groups of 12 get divided into 8 groups of 4, each of which have unique brush tips for the four parts of the second dimension, and finally, the grouped three images have each a unique brush for the final dimension. So, the following image has a table where dimension 1 is unique in one of 4 numbers, while dimension 2 is unique in one of 3 shapes. So our ranks for dimension 1 and dimension 2 need to be 4 and 3 respectively. Now, to order the layers, you need to subdivide the table first by the first dimension, and then by the second. So we end up with three layers each for a shape in the second dimension but for the first number, then another three layers, each for a shape, but then for the second number, and so forth. .. figure:: /images/category_filetypes/gih_multi_dimension_explaination.png :figwidth: 800px :align: center See `the GIMP documentation `_ for a more thorough explaination. GIMP image hose format options: ------------------------------- Constant This'll use the first image, no matter what. Incremental This'll paint the image layers in sequence. This is good for images that can be strung together to create a pattern. Pressure This'll paint the images depending on pressure. This is good for brushes imitating the hairs of a natural brush. Random This'll draw the images randomly. This is good for image-collections used in speedpainting as well as images that generate texture. Or perhaps more graphical symbols. Angle This'll use the dragging angle to determine with image to draw. When exporting a Krita file as a ``.gih``, you will also get the option to set the default spacing, the option to set the name (very important for looking it up in the UI) and the ability to choose whether or not to generate the mask from the colors. Use Color as Mask This'll turn the darkest values of the image as the ones that paint, and the whitest as transparent. Untick this if you are using colored images for the brush. -We have a :ref:`Krita Brush tip page ` on how to create your own gih brush. +We have a :ref:`Krita Brush tip page ` on how to create your own GIH brush. diff --git a/general_concepts/file_formats/file_jpeg.rst b/general_concepts/file_formats/file_jpeg.rst index e6226ec28..edcaf2a89 100644 --- a/general_concepts/file_formats/file_jpeg.rst +++ b/general_concepts/file_formats/file_jpeg.rst @@ -1,26 +1,26 @@ .. meta:: :description: The JPEG file format as exported by Krita. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier :license: GNU free documentation license 1.3 or later. -.. index:: jpeg, jpg, *.jpg +.. index:: *.jpg, *.jpeg, JPG, JPEG .. _file_jpg: .. _file_jpeg: ====== \*.jpg ====== ``.jpg``, ``.jpeg`` or ``.jpeg2000`` are a family of file-formats designed to encode photographs. Photographs have the problem that they have a lot of little gradients, which means that you cannot index the file like you can with :ref:`file_gif` and expect the result to look good. What JPEG instead does is that it converts the file to a perceptual color space (:ref:`YCrCb `), and then compresses the channels that encode the colors, while keeping the channel that holds information about the relative lightness uncompressed. This works really well because human eye-sight is not as sensitive to colorfulness as it is to relative lightness. JPEG also uses other :ref:`lossy ` compression techniques, like using cosine waves to describe image contrasts. However, it does mean that JPEG should be used in certain cases. For images with a lot of gradients, like full scale paintings, JPEG performs better than :ref:`file_png` and :ref:`file_gif`. But for images with a lot of sharp contrasts, like text and comic book styles, PNG is a much better choice despite a larger file size. For grayscale images, :ref:`file_png` and :ref:`file_gif` will definitely be more efficient. Because JPEG uses lossy compression, it is not advised to save over the same JPEG multiple times. The lossy compression will cause the file to reduce in quality each time you save it. This is a fundamental problem with lossy compression methods. Instead use a lossless file format, or a working file format while you are working on the image. diff --git a/general_concepts/file_formats/file_kpl.rst b/general_concepts/file_formats/file_kpl.rst index 0ca2e16cc..e63adfe89 100644 --- a/general_concepts/file_formats/file_kpl.rst +++ b/general_concepts/file_formats/file_kpl.rst @@ -1,19 +1,19 @@ .. meta:: :description: The Krita Palette file format. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier :license: GNU free documentation license 1.3 or later. .. index:: *.kpl, KPL, Krita Palette .. _file_kpl: ====== \*.kpl ====== Since 4.0, Krita has a new palette file-format that can handle colors that are wide gamut, RGB, CMYK, XYZ, GRAY, or LAB, and can be of any of the available bitdepths, as well as groups. These are Krita Palettes, or ``*.kpl``. -``*.kpl`` files are ZIP files, with two XMLs and ICC profiles inside. The colorset XML contains the swatches as ColorSetEntry and Groups as Group. The profiles.XML contains a list of profiles, and the ICC profiles themselves are embedded to ensure compatibility over different computers. +``*.kpl`` files are ZIP files, with two XMLs and ICC profiles inside. The colorset XML contains the swatches as ColorSetEntry and Groups as Group. The *profiles.xml* contains a list of profiles, and the ICC profiles themselves are embedded to ensure compatibility over different computers. diff --git a/general_concepts/file_formats/file_png.rst b/general_concepts/file_formats/file_png.rst index 1441757fe..c134c2a9d 100644 --- a/general_concepts/file_formats/file_png.rst +++ b/general_concepts/file_formats/file_png.rst @@ -1,26 +1,26 @@ .. meta:: :description: The Portable Network Graphics file format in Krita. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier - Boudewijn Rempt :license: GNU free documentation license 1.3 or later. -.. index:: *.png, png, portable network graphics +.. index:: *.png, PNG, portable network graphics .. _file_png: ====== \*.png ====== ``.png``, or Portable Network Graphics, is a modern alternative to :ref:`file_gif` and with that and :ref:`file_jpg` it makes up the three main formats that are widely supported on the internet. PNG is a :ref:`lossless ` file format, which means that it is able to maintain all the colors of your image perfectly. It does so at the cost of the file size being big, and therefore it is recommended to try :ref:`file_jpg` for images with a lot of gradients and different colors. Grayscale images will do better in PNG as well as images with a lot of text and sharp contrasts, like comics. Like :ref:`file_gif`, PNG can support indexed color. Unlike :ref:`file_gif`, PNG doesn't support animation. There have been two attempts at giving animation support to PNG, APNG and MNG, the former is unofficial and the latter too complicated, so neither have really taken off yet. .. versionadded:: 4.2 Since 4.2 we support saving HDR to PNG as according to the `W3C PQ HDR PNG standard `_. To save as such files, toggle :guilabel:`Save as HDR image (Rec. 2020 PQ)`, which will convert your image to the Rec 2020 PQ color space and then save it as a special HDR PNG. diff --git a/general_concepts/file_formats/file_svg.rst b/general_concepts/file_formats/file_svg.rst index 07cc7dc2f..383a565ab 100644 --- a/general_concepts/file_formats/file_svg.rst +++ b/general_concepts/file_formats/file_svg.rst @@ -1,25 +1,25 @@ .. meta:: :description: The Scalable Vector Graphics file format in Krita. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier :license: GNU free documentation license 1.3 or later. -.. index:: SVG, *.svg, Scalable Vector Graphics Format +.. index:: *.svg, SVG, Scalable Vector Graphics Format .. _file_svg: ====== \*.svg ====== ``.svg``, or Scalable Vector Graphics, is the most modern vector graphics interchange file format out there. Being vector graphics, SVG is very light weight. This is because it usually only stores coordinates and parameters for the maths involved with vector graphics. It is maintained by the W3C SVG working group, who also maintain other open standards that make up our modern internet. While you can open up SVG files with any text-editor to edit them, it is best to use a vector program like Inkscape. Krita 2.9 to 3.3 supports importing SVG via the add shape docker. Since Krita 4.0, SVGs can be properly imported, and you can export singlevector layers via :menuselection:`Layer --> Import/Export --> Save Vector Layer as SVG...`. For 4.0, Krita will also use SVG to save vector data into its :ref:`internal format `. SVG is designed for the internet, though sadly, because vector graphics are considered a bit obscure compared to raster graphics, not a lot of websites accept them yet. Hosting them on your own webhost works just fine though. diff --git a/reference_manual/create_new_document.rst b/reference_manual/create_new_document.rst index b158fe3d2..7828d4115 100644 --- a/reference_manual/create_new_document.rst +++ b/reference_manual/create_new_document.rst @@ -1,80 +1,80 @@ .. meta:: :description: A simple guide to the first basic steps of using Krita: creating and saving an image. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier - Raghavendra Kamath - Scott Petrovic - DMarquant - Vancemoss - Bugsbane - Hamlet 1977 - Lifeling - Yurchor :license: GNU free documentation license 1.3 or later. .. index:: Save, Load, New .. _create_new_document: Create New Document =================== A new document can be created as follows. #. Click on :guilabel:`File` from the application menu at the top. #. Then click on :guilabel:`New`. Or you can do this by pressing the :kbd:`Ctrl + N` shortcut. #. Now you will get a New Document dialog box as shown below: .. image:: /images/Krita_newfile.png There are various sections in this dialog box which aid in creation of new document, either using custom document properties or by using contents from clipboard and templates. Following are the sections in this dialog box: Custom Document ~~~~~~~~~~~~~~~ From this section you can create a document according to your requirements: you can specify the dimensions, color model, bit depth, resolution, etc. In the top-most field of the :guilabel:`Dimensions` tab, from the Predefined drop-down you can select predefined pixel sizes and PPI (pixels per inch). You can also set custom dimensions and the orientation of the document from the input fields below the :guilabel:`Predefined:` drop-down. This can also be saved as a new predefined preset for your future use by giving a name in the :guilabel:`Save Image Size as:` input box and clicking on the :guilabel:`Save` button. Below we find the Color section of the new document dialog box, where you can select the color model and the bit-depth. Check :ref:`general_concept_color` for more detailed information regarding color. On the :guilabel:`Content` tab, you can define a name for your new document. This name will appear in the metadata of the file, and Krita will use it for the auto-save functionality as well. If you leave it empty, the document will be referred to as 'Unnamed' by default. You can select the background color and the amount of layers you want in the new document. Krita remembers the amount of layers you picked last time, so be careful. Finally, there's a description box, useful to note down what you are going to do. Create From Clipboard ~~~~~~~~~~~~~~~~~~~~~ This section allows you to create a document from an image that is in your clipboard, like a screenshot. It will have all the fields set to match the clipboard image. Templates: ~~~~~~~~~~ These are separate categories where we deliver special defaults. Templates are -just .kra files which are saved in a special location, so they can be pulled up -by Krita quickly. You can make your own template file from any .kra file, by +just ``.kra`` files which are saved in a special location, so they can be pulled up +by Krita quickly. You can make your own template file from any ``.kra`` file, by using :menuselection:`File --> Create Template from Image...` in the top menu. This will add your current document as a new template, including all its properties along with the layers and layer contents. Once you have created a new document according to your preference, you should now have a white canvas in front of you (or whichever background color you chose in the dialog). diff --git a/reference_manual/dockers/specific_color_selector.rst b/reference_manual/dockers/specific_color_selector.rst index ee0c6d937..68754ffa5 100644 --- a/reference_manual/dockers/specific_color_selector.rst +++ b/reference_manual/dockers/specific_color_selector.rst @@ -1,38 +1,38 @@ .. meta:: :description: Overview of the specific color selector docker. .. metadata-placeholder :authors: - Wolthera van Hövell tot Westerflier - Scott Petrovic :license: GNU free documentation license 1.3 or later. .. index:: Color, Color Selector, Specific Color Selector, Color Space .. _specific_color_selector_docker: ======================= Specific Color Selector ======================= .. image:: /images/dockers/Krita_Specific_Color_Selector_Docker.png The specific color selector allows you to choose specific colors within a color space. Color Space Chooser ------------------- -Fairly straightforward. This color space chooser allows you to pick the color space, the bit depth and the icc profile in which you are going to pick your color. +Fairly straightforward. This color space chooser allows you to pick the color space, the bit depth and the ICC profile in which you are going to pick your color. Use the checkbox 'show color space selector' to hide this feature. Sliders ------- These change per color space. If you chose 16bit float or 32 bit float, these will go from 0 to 1.0, with the decimals deciding the difference between colors. Hex Color Selector ------------------ This is only available for the color spaces with a depth of 8 bit. This allows you to input hex color codes, and receive the RGB, CMYK, LAB, XYZ or YCrCb equivalent, and the other way around! diff --git a/reference_manual/dr_minw_debugger.rst b/reference_manual/dr_minw_debugger.rst index 6c2f34eb1..50ba25800 100644 --- a/reference_manual/dr_minw_debugger.rst +++ b/reference_manual/dr_minw_debugger.rst @@ -1,81 +1,81 @@ .. meta:: :description: How to get a backtrace in Krita using the dr. MinGW debugger. .. metadata-placeholder :authors: - Scott Petrovic - Wolthera van Hövell tot Westerflier - Raghavendra Kamath - Alvin Wong :license: GNU free documentation license 1.3 or later. .. index:: Backtrace, Debug .. _dr_minw: ================== Dr. MinGW Debugger ================== .. note:: The information on this page applies only to the Windows release of Krita. Using the Debug Package ----------------------- If you have your Krita version installed and you want to get a backtrace, it's best to download a portable version (either the latest release, or the one that someone told you to try, for example Krita Next or Krita Plus package). Alongside downloading the portable version, download the debug symbols package, too. It should be located in the same place -you download Krita. You can see which is which by checking the end of the name of the zip file - debug symbols package always ends with *-dbg.zip*. +you download Krita. You can see which is which by checking the end of the name of the ZIP file - debug symbols package always ends with *-dbg.zip*. -* Links to the debug packages should be available on the release announcement news item on https://krita.org/, along with the release packages. You can find debug packages for any release either in https://download.kde.org/stable/krita for stable releases or in https://download.kde.org/unstable/krita for unstable releases (for example beta versions). Portable zip and debug zip are found next to each other. +* Links to the debug packages should be available on the release announcement news item on https://krita.org/, along with the release packages. You can find debug packages for any release either in https://download.kde.org/stable/krita for stable releases or in https://download.kde.org/unstable/krita for unstable releases (for example beta versions). Portable ZIP and debug ZIP are found next to each other. * Make sure you’ve downloaded the same version of debug package for the portable package you intend to debug / get a better backtrace. * Extract the portable Krita. * Extract the files from the debug symbols package inside the portable Krita main directory, where the sub-directories *bin*, *lib* and *share* is located, like in the figures below: .. image:: /images/Mingw-dbg7zip.png .. image:: /images/Mingw-dbg7zip-dir.png * After extracting the files, check the ``bin`` dir and make sure you see the ``.debug`` dir inside. If you don't see it, you probably extracted to the wrong place. Getting a Backtrace ------------------- #. When there is a crash, Krita might appear to be unresponsive for a short time, ranging from a few seconds to a few minutes, before the crash dialog appears. .. figure:: /images/Mingw-crash-screen.png An example of the crash dialog. * If Krita keeps on being unresponsive for more than a few minutes, it might actually be locked up, which may not give a backtrace. In that situation, you have to close Krita manually. Continue to follow the following instructions to check whether it was a crash or not. #. Open Windows Explorer and type ``%LocalAppData%`` (without quotes) on the address bar and press the :kbd:`Enter` key. .. image:: /images/Mingw-explorer-path.png #. Find the file ``kritacrash.log`` (it might appear as simply ``kritacrash`` depending on your settings.) #. Open the file with Notepad and scroll to the bottom, then scroll up to the first occurrence of “Error occurred on