Yes, you can. GIMP is free software, it doesn’t put restrictions on the kind of work you produce with it.
GIMP is distributed under terms of General Public License v3 and later. In a nutshell, this means:
Note that once you distribute modified version of GIMP, you also must publish your changes to the source code under GPLv3+ as well.
Yes, under terms of the General Public License this is perfectly legal, provided that the seller also gave you the source code of GIMP and any modifications he/she introduced.
No. Most generic image editors look like Photoshop simply because Adobe’s application was among the first image editors as we know them now, so developers tend to stick to what people know — in general terms.
What we aim to do is to create a high-end image manipulation application that is free to use and modify by everyone, ever.
Feature-wise, the proposed “high-end” status does automatically put GIMP into direct comparison against Photoshop, but we don’t think about competition much. We have too many ideas of our own to implement, and too many things to improve before the notion of competition begins to make the slightest sense.
We do, however, acknowledge the fact that people will treat GIMP as Photoshop replacement no matter what we tell them, and that’s all right with us. You own this software, it’s up to you to decide how you make use of it.
In the past, the development in the project was somewhat erratic with regards to taking usability into consideration, which is rather typical for free software projects, but inexcusable for a high-end image editor that GIMP aims to become.
Between 2006 and 2013, we worked with Peter Sikking of Man+Machine Works, a professional usability architect, who helped us shape the project vision for GIMP, interviews professional users to better understand their workflows and demands, and wrote functional specifications for various GIMP features.
This collaboration resulted in major improvements of GIMP’s usability, in particular: the rectangular-based selection/cropping tools, the unified free/polyline selection tool, the single-window mode, the upcoming unified transformation tool etc.
While working on functional specifications, Peter researched how various features are implemented in applications with a partially matching feature set (such as Adobe Photoshop), but the final design was made to help actual users complete their tasks as fast as possible. This is exactly the kind of approach to designing interfaces that we consider to be superior to merely copying user interaction decisions.
No. We’ve discussed this numerous times, and we don’t think this is really all that necessary. We understand that some people feel offended by the colloquial meaning of the name GIMP, but we cannot please everybody and should not attempt to do so.
We release both updates to the current stable version and development versions.
We cut new updates of the stable version in two cases: 1) some newly introduced bug is knowingly affecting a lot of users; 2) the amount of improvements and bug fixes is large enough to justify an update — typically, a few dozens of each, but there is no rule.
Currently we are cleaning up GIMP code for v2.10 release some time in 2017.
We are a team of volunteers with day jobs, families, and personal interests beyond development of software. Given that, we try to avoid the situation when we cannot deliver a release, because something else at work/in family came up.
Instead we provide a feature-based roadmap that roughly outlines, in what order we will be implementing various popular requests made by users.
We already have jobs we love. However we actively encourage personal fundraisers by trusted contributors. There are two such campaigns running at the moment. You can learn more about them on the Donate page.
If you are willing to launch a campaign and develop some features for GIMP, talk to us about changes you are about to propose. We’ll help you to flesh out your idea and promote it to a larger community.
GIMP 2.10 will be the first version to feature processing with precision of 16, 32, and 64bit per color channel. This version is currently in the works, and this particular feature has already been implemented.
Currently the plan is to introduce non-destructive editing in GIMP 3.2. This is a huge change that will require rethinking the workflow, designing a new file format for GIMP projects etc.
Currently you need to install UFRaw to open raw files. It’s both a standalone application and a GIMP plug-in for opening and processing raw images.
Upcoming GIMP 2.10 is featuring a plug-in for using darktable to process raw images on Linux. Additionally, users will be able to set a preferred raw processing application, when multiple GIMP plug-ins of that kind are available.
Better support for CMYK has been on our roadmap for a long time. However this project has certain prerequisites such as the complete port of GIMP to GEGL.
The idea, how we want to make this work, was introduced by user interaction architect Peter Sikking at Libre Graphics Meeting 2009 and later — in his two-part article in his company’s blog: 1, 2. Please take some time to read up on that.
It’s worth mentioning that currently CMYK is considered by us a low-priority project. Here’s why.
Things like non-destructive editing are required by pretty much all users — photographers, designers, desktop publishing engineers, and even scientists. At the same time, CMYK is required only by a small subset of our user base. We prioritize our work accordingly.
Note that should a new developer join the team to specifically work on CMYK-related features, we will do our best to help him/her to complete this project and get it to our users as soon as possible.
We realize that some changes are disruptive to some groups of users, especially those who got used to GIMP as an image editor for doing quick fixes to lossy files such as JPEG, PNG etc. (i.e. files that cannot store layers, masks, custom channels, paths).
However, adding a switch for every change we make adds numerous levels of complexity that we’d rather avoid. Additionally, it would lead to dramatically changing the way we mean GIMP to work. Hence we respectfully disagree to make extra behaviour switches.
At the same time, if you don’t wish to abandon GIMP completely, we recommend having a look at the Saver and Save/export clean plug-ins by Akkana Peck, as well as at various GIMP forks on GitHub, although typically they aren’t maintained up to date with regards to bugfixes.
We made a preliminary port of GIMP to GTK+3 a few years ago and intend to complete it once v2.10 is out. GTK+3 based GIMP will be eventually released as v3.0 (see the roadmap for reference).
The reason we prioritize it that way is that users who don’t make a heavy use of Wacom tablets on Windows can live with GTK+2 based GIMP another year or so. However not providing high bit depth precision for editing makes GIMP unusable in professional workflows involving color grading and retouching.
When completing the GTK+3 port, we will have to break API/ABI compatibility to make GIMP’s custom widgets work with GTK+3. Moreover, we need to break a few more things to make GIMP’s architecture cleaner and prepare it for non-destructive editing (a feature currently planned for v3.2).
In any of the drawing tools (Pen, Pencil, etc.), click on one endpoint of the line. Then hold the shift key and click on the other endpoint.
In the Rectangular or Elliptical selection tool, click in one corner of your square or circle, then press Shift while dragging toward the other corner. Or enable the checkbox for Fixed: Aspect Ratio in tool options and make sure the aspect ratio is set to 1:1 before starting your square or circular selection.
Once you have a selection, Edit->Stroke Selection… will draw a line the shape of the selection you just made.
For curved selections, like circles, stroking with the Paintbrush paint tool will usually give a smoother looking line. You can get an even smoother line by converting the selection to a path (Select->To Path), then using Edit->Stroke Path… instead of Stroke Selection…
Yes, GIMP does support graphic tablets and maps pressure, stroke speed and other events to its advanced brush engine properties. However, the version of the user interface toolkit that GIMP currently relies on (GTK+ 2.x) is broken beyond repair on Windows and Mac with regards to supporting advanced input devices such as Wacom’s.
To fix this, we need to port GIMP to GTK+3 where everything works as expected. Some work on that has already been done in the gtk3-port Git branch. However we won’t have time to give this our full attention until GIMP 2.10 is out. We encourage interested developers to either work on the GTK+3 port or, better yet, help us finish GIMP 2.10.
Absolutely! Here are some of the ways you can help us: