Verified Commit 28e253b7 authored by Raghavendra Kamath's avatar Raghavendra Kamath 🎨
Browse files

Merge branch 'master' into krita/4.3

parents b3c185ea 6f8b32af
RewriteEngine on
RewriteEngine on
# Old mediawiki pages redirects.
RewriteRule "^Main_Page" /en/index.html [R=301]
......
This diff is collapsed.
......@@ -180,6 +180,8 @@ rst_epilog = """
.. |toolselectpolygon| image:: /images/icons/polygonal_select_tool.svg
.. |toolselectmagnetic| image:: /images/icons/magnetic_select_tool.svg
.. |toolselectpath| image:: /images/icons/path_select_tool.svg
.. |toolselectoutline| image:: /images/icons/outline_select_tool.svg
......
.. meta::
:description:
Guide to the Krita community
Guide to the Krita community.
.. metadata-placeholder
......@@ -31,11 +31,13 @@ There are also the:
You’ll find that there are a number of people are almost always around: the core team.
* Boudewijn (irc: boud): project maintainer, lead developer. Works full-time on Krita. Manages the Krita Foundation, triages bugs, does social media and admin stuff. Boudewijn is also on Reddit as boudewijnrempt.
* Dmitry (irc: dmitryk_log): lead developer. Works full-time on Krita.
* Wolthera (irc: wolthera_laptop): developer, writes the manual and tutorials, triages bugs, helps people out
* Scott Petrovic (irc: scottyp): UX designer, developer, webmaster
* Dmitry (irc: dmitryK|log): lead developer. Works full-time on Krita.
* Wolthera (irc: Wolthera_laptop): developer, writes the manual and tutorials, triages bugs, helps people out. Works full-time on Krita.
* Ivan Yossi (irc: ivanyossi|log): developer. Works full-time on Krita.
* Agata Cacko (irc: tiar): developer, user supporter. Works full-time on Krita. Also on reddit as u/-tiar- .
* Scott Petrovic (irc: scottyp): UX designer, developer, webmaster.
* David Revoy (irc: deevad): expert user, creates Pepper & Carrot, maintains the preset bundle.
* Alvin Wong (irc: windragon): windows guru
* Alvin Wong (irc: windragon): windows guru.
* Ben Cooksley (irc: bcooksley): KDE system administrator.
Krita’s team spans the globe, but most development happens in Europe and Russia.
......
.. meta::
:description:
reStructuredText conventions for the Krita Manual
reStructuredText conventions for the Krita Manual.
.. metadata-placeholder
......@@ -58,7 +58,7 @@ Each page should start with the following three things:
: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
......@@ -181,11 +181,11 @@ You can make text *emphasized* and **strong** with a single asterisk and double
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```
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`
:menuselection:`Settings --> Configure Krita...`
:guilabel:`File`
:kbd:`Ctrl + Z`
:program:`Krita`
......
.. meta::
:description:
Contributor's Readme for the Krita Manual
Contributor's Readme for the Krita Manual.
.. metadata-placeholder
......@@ -85,15 +85,15 @@ Not recommended when you plan to contribute more in the future. (See :ref:`merge
You can use the `Online Sphinx Editor <https://livesphinx.herokuapp.com/>`_ 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.
......@@ -118,7 +118,7 @@ If you have a lot of changes you want to contribute, we recommend trying to foll
#. 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 see a dropbox with ``master`` as a chosen item; please select ``draft`` if your changes contain anything other than pure typo fixes.
#. 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`.
......@@ -150,7 +150,7 @@ Not recommended when you don't know what a branch is (see :ref:`merge-request-ed
#. Go to your fork (make sure the url contains your username).
#. Make sure you're on ``draft``, not on ``master``, unless your changes contain *only* spelling and grammatical fixes.
#. 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.
......@@ -168,12 +168,12 @@ Not recommended when you don't know what a branch is (see :ref:`merge-request-ed
#. 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
.. .. 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.`
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.
......@@ -195,12 +195,12 @@ Not recommended when you don't know what a branch is (see :ref:`merge-request-ed
.. code-block:: bash
# for ssh access
git clone git@invent.kde.org:<username>/krita.git
git remote add upstream git@invent.kde.org:kde/krita.git
git clone git@invent.kde.org:<username>/docs-krita-org.git
git remote add upstream git@invent.kde.org:websites/docs-krita-org.git
# for https access
git clone https://invent.kde.org/<username>/krita.git
git remote add upstream https://invent.kde.org/kde/krita.git
git clone https://invent.kde.org/<username>/docs-krita-org.git
git remote add upstream https://invent.kde.org/websites/docs-krita-org.git
#. Remember to always pull changes from the official repository before making new changes:
......@@ -210,15 +210,12 @@ Not recommended when you don't know what a branch is (see :ref:`merge-request-ed
git pull upstream master
#. Make sure you create a new branch for your changes and make sure you branched from the correct branch: ``master`` in case if your changes only contain typo fixes, ``draft`` in all other cases.
#. Make sure you create a new branch for your changes, since september 2019, all changes should be branched from ``master``.
.. code-block:: bash
# if your changes need to go to master
git checkout master
# if your changes need to go to draft
git checkout draft
# and then:
git checkout -b "<username>/<description of the new feature>"
......@@ -229,6 +226,8 @@ Not recommended when you don't know what a branch is (see :ref:`merge-request-ed
.. code-block:: bash
# install the python3-sphinx package for your system. For example for Ubuntu:
sudo apt install python3-sphinx
# make sure everything is correct
make html
git status
......@@ -240,7 +239,7 @@ Not recommended when you don't know what a branch is (see :ref:`merge-request-ed
# submit your changes to your fork
git push
#. Finally, go to the website of the original repository (make sure you're on the correct branch, `master` or `draft`), 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`.
#. 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:
......@@ -252,7 +251,7 @@ Guidelines for new merge requests
#. :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 ``draft``, unless your changes contain only typo fixes.
#. :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]`.
......@@ -266,7 +265,7 @@ Guidelines for new merge requests
#. 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:`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.
......@@ -328,10 +327,10 @@ 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
......
......@@ -39,9 +39,9 @@ ImageMagick
import -depth 8 -dither <filename.png>
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 <https://github.com/phw/peek>`_ -- This one has an appimage and a very easy user-interface. Like many screenrecording programs it does show trouble on Wayland.
......@@ -56,19 +56,19 @@ 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 <lossy_compression>`. 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 <lossy_compression>`. 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.**
......@@ -113,7 +113,7 @@ There is a whole laundry list of `PNG optimisation tools <https://css-ig.net/png
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
^^^^^^^^^^^^^^
......@@ -190,7 +190,7 @@ OptiPNG
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 <https://imagemagick.org/script/command-line-options.php#profile>`_
First extract the metadata to a profile by converting::
......
......@@ -47,9 +47,9 @@ Quick solutions
#. Change API in :menuselection:`Settings --> Configure Krita... --> Tablet Settings`.
#. Wintab: older standard; it supports multiple buttons and high number of pressure levels high. If it works fine for you, don't change to Windows Ink. 2-in-1 devices by default use Windows Ink, you can get a Wintab driver but you need to install it separately.
#. Windows Ink: newer standard; it cuts the pressure levels to 1024. It is more suitable for 2-in-1 devices like Surfacce Pro and Yoga. Some less known brands might not have this standard implemented.
#. Wintab: older standard; it supports multiple buttons and high number of pressure levels. If it works fine for you, don't change to Windows Ink. 2-in-1 devices by default use Windows Ink, you can get a Wintab driver but you need to install it separately.
#. Windows 8+ Pointer (Windows Ink): newer standard; it cuts the pressure levels to 1024. It is more suitable for 2-in-1 devices like Surface Pro and Yoga. Some less known brands might not have this standard implemented.
*For Windows, tablet/digitizer devices (not convertible/2-in-1 ones):*
......@@ -57,8 +57,7 @@ Quick solutions
#. *Wacom tablets:* if you get straight lines at the beginnings of the strokes, first try to update your driver: it should be fixed in 6.3.34-3. If it doesn't work, disable/minimize "double-click distance" in Wacom settings.
#. *XP-Pen tablets, pressure being uneven:* either switch to Windows 8+ Pointer, or disable Windows Ink in XP-Pen settings.
#. *XP-Pen tablets, pressure being uneven:* either switch to Windows 8+ Pointer (Windows Ink) in :menuselection:`Settings --> Configure Krita... --> Tablet Settings`, or disable Windows Ink in XP-Pen settings.
Gathering information
......@@ -75,23 +74,23 @@ Gathering information
#. More detailed Tablet Events log:
1. Go to :menuselection:`Settings --> Dockers --> Log Viewer` docker, make sure it's checked.
#. In the Log Viewer docker, make sure the first button is pressed (which means the logging is turned on).
#. Press :kbd:`Ctlr + Shift + T` to turn on tablet events logging.
#. Press :kbd:`Ctrl + Shift + T` to turn on tablet events logging.
#. Make a few strokes (depending on the situation, the user supporter or developer can ask you for specific series of strokes).
#. Press :kbd:`Ctlr + Shift + T` to turn off the logging of the tablet events.
#. Press :kbd:`Ctrl + Shift + T` to turn off the logging of the tablet events.
#. Press the third button in the Log Viewer to save the output into a file.
#. Share the file or share the content of the file: :ref:`intro_user_support_sharing_files`.
On Linux, you can just use a console instead of Log Viewer -- then you'd only need to enable tablet events logging, not logging in general.
Additional information for supporters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
......@@ -100,7 +99,7 @@ Additional information for supporters
#. Huion tablets should work on Windows and on Linux, on Mac there might be issues.
#. XP-Pen tablets and other brands can have issues everywhere.
#. XP-Pen tablets and the rest of brands can have issues everywhere (on all systems).
#. If someone asks about a tablet to buy, generally a cheaper Wacom or a Huion are the best options as of 2019, if they want to work with Krita. :ref:`list_supported_tablets`.
......@@ -133,7 +132,7 @@ In case of crash try to determine if the problem is known, if not, instruct user
#. Is it possible to reproduce (repeat)? If yes, provide a step-by-step instruction to get the crash.
#. Backtrace (crashlog) -- the instruction is here: :ref:`dr_minw`, and the debug symbols can be found in the annoucement of the version of Krita that the user has. But it could be easier to just point the user to `https://download.kde.org/stable/krita <https://download.kde.org/stable/krita>`_.
#. Backtrace (crashlog) -- the instruction for Windows is here: :ref:`dr_minw`, and the debug symbols can be found in the annoucement of the version of Krita that the user has. But it could be easier to just point the user to `https://download.kde.org/stable/krita <https://download.kde.org/stable/krita>`_.
Other possible questions with quick solutions
......@@ -145,7 +144,7 @@ Other possible questions with quick solutions
#. When the user has trouble with anything related to preview or display, ask them to change :guilabel:`Canvas Graphics Acceleration` in :menuselection:`Settings --> Configure Krita... --> Display`.
.. note::
Telling people to disable canvas acceleration to get better performance is something we shouldn't do, ever.
......@@ -175,19 +174,19 @@ How to share a file
* Images (e.g. screenshots): `Imgur <https://imgur.com>`_ [*], `Pasteboard <https://pasteboard.co>`_
* Text only: `Pastebin <https://pastebin.com>`_ [*], `BPaste <https://bpaste.net>`_, `paste.ubuntu.org.cn <https://paste.ubuntu.org.cn>`_, `FedoraProject's Paste <https://paste.fedoraproject.org/>`_ or `KDE Snippets (needs KDE Identity) <https://invent.kde.org/dashboard/snippets>`_.
* ``.kra`` and other formats: by mail? Or encode the file using *base64* command on Linux, send by mail or on Pastebin, then decode using the same command.
.. attention::
If you ask user to store their log or other data on a website, make sure it stays there long enough for you to get it -- for example bpaste.net stores files by default only for a day! And you can extend it only to one week.
.. admonition:: Blocked websites
If the user is behind a firewall of some sorts (for example lives in China), websites with [*] will probably be blocked; please use the alternatives.
......@@ -231,7 +231,7 @@ LUT docker manipulations are per view, so you can create a new view and set it t
Another example is to carefully watch the gradients in a certain section.
Like ICC, the LUT Docker allows you to create a profile of sorts for your device. In this case it's the 'LUT', which stands for 'Look Up Table', and which can be added to OCIO by modifying the configuration file. When OCIO is turned on, the configuration in :menuselection:`Settings --> Configure Krita --> Color Management` is turned off, unless you are using the :guilabel:`Internal` color engine.
Like ICC, the LUT Docker allows you to create a profile of sorts for your device. In this case it's the 'LUT', which stands for 'Look Up Table', and which can be added to OCIO by modifying the configuration file. When OCIO is turned on, the configuration in :menuselection:`Settings --> Configure Krita... --> Color Management` is turned off, unless you are using the :guilabel:`Internal` color engine.
In summary
----------
......@@ -242,7 +242,7 @@ Krita has two modes of color management:
* OCIO works in terms of interpretation, and makes use of LUTs.
* both can be made with a colorimeter.
* If you want to have a properly color managed workflow, you have one made customary for the input device (your screen) and the output devices (your printer, or target screen). For web the output is always sRGB.
* Set up your screen profiles under :menuselection:`Settings --> Configure Krita --> Color management`.
* Set up your screen profiles under :menuselection:`Settings --> Configure Krita... --> Color management`.
* Do NOT use screen profiles or other device profiles to draw in. Use a working space profile such as any of the 'elle' profiles for this, as the color maths will be much more predictable and pleasant. Krita will convert between your screen and working space on the fly, allowing you to pick the correct colors. This turns your screen into binoculars to view the image.
* Use the appropriate color management for the appropriate workflow. If you are working with Blender, you will be better off using OCIO, than ICC. If you are working with Scribus or Photoshop, use ICC.
......@@ -304,7 +304,7 @@ Example workflows
Here are some example workflows to get a feeling of how your color management workflow may look like.
As mentioned before, input for your screen is set via :menuselection:`Settings --> Configure Krita --> Color management`, or via the LUT docker's 'screen space'. Working space is set via new file per document, or in the LUT docker via 'input space'.
As mentioned before, input for your screen is set via :menuselection:`Settings --> Configure Krita... --> Color management`, or via the LUT docker's 'screen space'. Working space is set via new file per document, or in the LUT docker via 'input space'.
Webcomic
~~~~~~~~
......@@ -345,7 +345,7 @@ Output
The CMYK profiles are different per printer, and even per paper or ink-type so don't be presumptuous and ask ahead for them, instead of doing something like trying to paint in any random CMYK profile. As mentioned in the viewing conditions section, you want to keep your options open.
You can set the advanced color selector to transform to a given profile via :menuselection:`Settings --> Configure Krita --> Color Selector Settings`. There, tick :guilabel:`Color Selector Uses Different Color Space than Image` and select the CMYK profile you are aiming for. This will limit your colors a little bit, but keep all the nice filter and blending options from RGB.
You can set the advanced color selector to transform to a given profile via :menuselection:`Settings --> Configure Krita... --> Color Selector Settings`. There, tick :guilabel:`Color Selector Uses Different Color Space than Image` and select the CMYK profile you are aiming for. This will limit your colors a little bit, but keep all the nice filter and blending options from RGB.
Games
~~~~~
......
......@@ -38,7 +38,7 @@ Let's compare the following gradients in different spaces:
.. 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.
......
......@@ -90,4 +90,4 @@ However, when we start projecting, the lights of the room aren't dimmed, which m
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.
......@@ -37,7 +37,7 @@ Then, there's proper working file formats like Krita's ``KRA``, Gimp's ``XCF``,
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
--------
......
......@@ -7,7 +7,7 @@
:authors: - Wolthera van Hövell tot Westerflier <griffinvalley@gmail.com>
:license: GNU free documentation license 1.3 or later.
.. index:: EXR, HDR Fileformat, OpenEXR, *.exr
.. index:: *.exr, EXR, HDR Fileformat, OpenEXR
.. _file_exr:
======
......
.. meta::
:description:
The Gimp Brush file format as used in Krita.
The GIMP Brush file format as used in Krita.
.. metadata-placeholder
:authors: - Wolthera van Hövell tot Westerflier <griffinvalley@gmail.com>
:license: GNU free documentation license 1.3 or later.
.. index:: Gimp Brush, GBR, *.gbr
.. index:: *.gbr, GBR, Gimp Brush
.. _file_gbr:
======
......
......@@ -7,7 +7,7 @@
:authors: - Wolthera van Hövell tot Westerflier <griffinvalley@gmail.com>
:license: GNU free documentation license 1.3 or later.
.. index:: GIF, *.gif
.. index:: *.gif, GIF
.. _file_gif:
======
......
.. meta::
:description:
The Gimp Image Hose file format in Krita.
The GIMP Image Hose file format in Krita.
.. metadata-placeholder
:authors: - Wolthera van Hövell tot Westerflier <griffinvalley@gmail.com>
: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:
======
......@@ -24,7 +24,21 @@ Image Hose means that this file format allows you to store multiple images and t
From top to bottom: Incremental, Pressure and Random
Gimp image hose format options:
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 <https://docs.gimp.org/2.8/en/gimp-using-animated-brushes.html>`_ for a more thorough explaination.
GIMP image hose format options:
-------------------------------
Constant
This'll use the first image, no matter what.
......@@ -42,4 +56,4 @@ When exporting a Krita file as a ``.gih``, you will also get the option to set t
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 <brush_tip_animated_brush>` on how to create your own gih brush.
We have a :ref:`Krita Brush tip page <brush_tip_animated_brush>` on how to create your own GIH brush.
......@@ -7,7 +7,7 @@
:authors: - Wolthera van Hövell tot Westerflier <griffinvalley@gmail.com>
:license: GNU free documentation license 1.3 or later.
.. index:: jpeg, jpg, *.jpg
.. index:: *.jpg, *.jpeg, JPG, JPEG
.. _file_jpg:
.. _file_jpeg:
......
......@@ -16,4 +16,4 @@
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.
......@@ -8,7 +8,7 @@
- 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:
......
......@@ -7,7 +7,7 @@
:authors: - Wolthera van Hövell tot Westerflier <griffinvalley@gmail.com>
: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:
======
......@@ -20,6 +20,6 @@ Being vector graphics, SVG is very light weight. This is because it usually only
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 <file_kra>`.
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...` menu item. For 4.0, Krita will also use SVG to save vector data into its :ref:`internal format <file_kra>`.
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.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment