You did realize that GEGL, the new GIMP core that is being integrated right now, does image processing in 32bit floating-point (that's 32 bit per color channel), didn't you?
Not only is that story outdated and copied from another place, it is also badly researched. And Slashdot could have at least included a link to the official release notes for GIMP 2.5.
Re:Still no white-balance function
on
GIMP 2.4 Released
·
· Score: 1
Sorry, but you are plain wrong. You don't have to pick a precisely medium-gray pixel. The brightness is actually irrelevant. You can pick a white spot if there is one. Or in lack of something white, use something that you know is gray. All the gray color picker does is correcting the color cast, it won't adjust for the brightness. That is what the white and black color pickers are for.
At least we added support for adjusting letter spacing. There is still a lot left to be done though and people shouldn't expect me to do all this myself...
Actually, it used to work like this at some point. Pressing a modifier key is not supposed to change the active image. What you are seeing is just a bug and we can probably fix it.
Re:Moving pixels within a selection
on
GIMP 2.4 Released
·
· Score: 1
Select the area, press Enter to commit it, then Ctrl-Alt-Drag to float and move the selected area.
Yeah, this is somewhat more clumsy than in previous versions. But we found that moving the selected pixels is not the common operation for most users and so we optimized the tool for the more common workflows.
Re:Still no white-balance function
on
GIMP 2.4 Released
·
· Score: 2, Informative
GIMP has had this since version 2.2. Go to the Levels dialog, select the gray color-picker and use it to select an area that is supposed to be some shade of gray.
Re:Ask artists, not geeks
on
GIMP 2.4 Released
·
· Score: 3, Informative
You can create CMYK TIFF files with GIMP (Separate plug-in), doing a color separation based on the printer's ICC profile Shouldn't that be enough to get your work printed?
For your peeve #1, the solution is simple. Go to the Preferences dialog and uncheck "Activate the focused image" in the Window Management section. The gimprc manual page explains this setting:
(activate-on-focus yes)
When enabled, an image will become the active image when its
image window receives the focus. This is useful for window man
agers using "click to focus". Possible values are yes and no.
Peeve #4 is also simple to adjust to. Just change the Move tool to "Move the active layer" instead of "Pick a layer". This can be conveniently toggled with the Shift key (as shown in the tool options).
There's a patch for #2 (Editing at image boundaries) in the bug-tracker (bug #362915). It has issues but I very much hope that we can fix them and get it in for 2.6.
Try a recent development version then. We have addressed exactly that problem lately. Panning the zoomed out view of a large image is a lot faster now and the quality of the zoomed out view has been improved at the same time.
The arbitrary split between "filters" and "script-fu" which places important items randomly (from the user perspective) into one of the two areas.
Right. That's why the developers got rid of that arbitrary split in the 2.3 series. Now plug-ins and scripts are organised by functionality instead of categorizing them by the programming language they are implemented in.
The role of channels in the UI is not at all intuitively clear
I am not sure if channels can be intuitively clear at all. But there's a user manual that explains the concepts. Perhaps you could elaborate what's wrong with channels or how they behave differently than what you would expect?
It works exactly like that in GIMP. There's a dedicated tool for it, called the "Clone tool", and you will find it located in the toolbox. The tool works exactly like you described your workflow in Photoshop. No 30 steps, no need to use several tools.
That's due to an optimization that GIMP does here. The brush mask is cached so that it doesn't have to be rescaled all the time. In order to allow such caching the size is adjusted in full pixel steps. That's not a problem for wide strokes but if you go down to very small brushes, it becomes a problem.
Yes, this could certainly be improved, patches welcome. But please check a recent 2.3 release before you start coding. There have been lots of changes to the brush scaling code so this might even have been addressed already.
The paint tools have a set of toggles labeled "Pressure sensitivity". There, next to the check-box "Opacity", is a check-box labeled "Size". If you check that the brush will shrink depending on the pressure you apply.
I added this feature eight years ago at the Chaos Communication Camp. How could you have missed it all that time?
First of all, it's not the GIMP team working on this. The GIMP team is busy preparing GIMP 2.4. The ingimp developers are different people. We are communicating and helping them with technical questions. And at some point we might consider integrating this code into GIMP proper. Of course as an option and certainly not without asking the user.
You said "if you insist on having a separate window for everything, write a little window z-order controller that ensures the relevant windows are visible". Good point. Well, that's what the concept of transient windows is good for. And GIMP 2.4 will make heavy use of that.
That's what happens when you are in feature freeze, preparing a new stable release. There's only bug fixing and minor tweaks because otherwise we would never get 2.4 done and we absolutely want to release GIMP 2.4 for two reasons:
to let our users benefit from the new features, usability and performance improvements
to finally start the integration of GEGL into the GIMP core
GIMP does support variable brush width based on tablet pressure since version 1.2.
And yes, it is still being developed and we are very close to finally releasing GIMP 2.4 which will bring lots of new features and usability improvements.
Why didn't you just use the Photoshop keyboard bindings that ship with GIMP? For someone who is coming from Photoshop, that should make things a lot easier. For someone who is accustomed to the keybindings used on the GNOME desktop, it will feel akward though.
Yes, you can use a gamepad with GIMP, assuming that a driver exists that makes it available as a Linux Input device. Otherwise you could also write your own GIMP input module. That's a pretty small well-defined interface and there's example code that you can base your module on.
Slashdot Mirror
You did realize that GEGL, the new GIMP core that is being integrated right now, does image processing in 32bit floating-point (that's 32 bit per color channel), didn't you?
It doesn't only contain a README. Look again, there's a folder with the GEGL 0.0 pre-releases. Just grab the latest tarball (gegl-0.0.16).
Not only is that story outdated and copied from another place, it is also badly researched. And Slashdot could have at least included a link to the official release notes for GIMP 2.5.
Sorry, but you are plain wrong. You don't have to pick a precisely medium-gray pixel. The brightness is actually irrelevant. You can pick a white spot if there is one. Or in lack of something white, use something that you know is gray. All the gray color picker does is correcting the color cast, it won't adjust for the brightness. That is what the white and black color pickers are for.
At least we added support for adjusting letter spacing. There is still a lot left to be done though and people shouldn't expect me to do all this myself...
Or just hit the "Path from Text" button in the text tool?
Commit your selection by pressing Enter, then Ctrl-Alt-Drag to float and move the selected pixels.
Actually, it used to work like this at some point. Pressing a modifier key is not supposed to change the active image. What you are seeing is just a bug and we can probably fix it.
Select the area, press Enter to commit it, then Ctrl-Alt-Drag to float and move the selected area.
Yeah, this is somewhat more clumsy than in previous versions. But we found that moving the selected pixels is not the common operation for most users and so we optimized the tool for the more common workflows.
GIMP has had this since version 2.2. Go to the Levels dialog, select the gray color-picker and use it to select an area that is supposed to be some shade of gray.
You can create CMYK TIFF files with GIMP (Separate plug-in), doing a color separation based on the printer's ICC profile Shouldn't that be enough to get your work printed?
For your peeve #1, the solution is simple. Go to the Preferences dialog and uncheck "Activate the focused image" in the Window Management section. The gimprc manual page explains this setting:
(activate-on-focus yes)
When enabled, an image will become the active image when its
image window receives the focus. This is useful for window man
agers using "click to focus". Possible values are yes and no.
Peeve #4 is also simple to adjust to. Just change the Move tool to "Move the active layer" instead of "Pick a layer". This can be conveniently toggled with the Shift key (as shown in the tool options).
There's a patch for #2 (Editing at image boundaries) in the bug-tracker (bug #362915). It has issues but I very much hope that we can fix them and get it in for 2.6.
Try a recent development version then. We have addressed exactly that problem lately. Panning the zoomed out view of a large image is a lot faster now and the quality of the zoomed out view has been improved at the same time.
The arbitrary split between "filters" and "script-fu" which places important items randomly (from the user perspective) into one of the two areas.
Right. That's why the developers got rid of that arbitrary split in the 2.3 series. Now plug-ins and scripts are organised by functionality instead of categorizing them by the programming language they are implemented in.
The role of channels in the UI is not at all intuitively clear
I am not sure if channels can be intuitively clear at all. But there's a user manual that explains the concepts. Perhaps you could elaborate what's wrong with channels or how they behave differently than what you would expect?
It works exactly like that in GIMP. There's a dedicated tool for it, called the "Clone tool", and you will find it located in the toolbox. The tool works exactly like you described your workflow in Photoshop. No 30 steps, no need to use several tools.
Startup on Win32 is pretty fast, definitely a lot faster than Photoshop. If it isn't, then your font cache is broken as explained in the FAQ.
Yes, it would be good to finally figure out why this happens at all and there are people working on this (see bug 154968).
That's due to an optimization that GIMP does here. The brush mask is cached so that it doesn't have to be rescaled all the time. In order to allow such caching the size is adjusted in full pixel steps. That's not a problem for wide strokes but if you go down to very small brushes, it becomes a problem.
Yes, this could certainly be improved, patches welcome. But please check a recent 2.3 release before you start coding. There have been lots of changes to the brush scaling code so this might even have been addressed already.
The paint tools have a set of toggles labeled "Pressure sensitivity". There, next to the check-box "Opacity", is a check-box labeled "Size". If you check that the brush will shrink depending on the pressure you apply.
I added this feature eight years ago at the Chaos Communication Camp. How could you have missed it all that time?
First of all, it's not the GIMP team working on this. The GIMP team is busy preparing GIMP 2.4. The ingimp developers are different people. We are communicating and helping them with technical questions. And at some point we might consider integrating this code into GIMP proper. Of course as an option and certainly not without asking the user.
You said "if you insist on having a separate window for everything, write a little window z-order controller that ensures the relevant windows are visible". Good point. Well, that's what the concept of transient windows is good for. And GIMP 2.4 will make heavy use of that.
GIMP does support variable brush width based on tablet pressure since version 1.2.
And yes, it is still being developed and we are very close to finally releasing GIMP 2.4 which will bring lots of new features and usability improvements.
Why didn't you just use the Photoshop keyboard bindings that ship with GIMP? For someone who is coming from Photoshop, that should make things a lot easier. For someone who is accustomed to the keybindings used on the GNOME desktop, it will feel akward though.
Yes, you can use a gamepad with GIMP, assuming that a driver exists that makes it available as a Linux Input device. Otherwise you could also write your own GIMP input module. That's a pretty small well-defined interface and there's example code that you can base your module on.
e l=url2html-27183http://gimp.org/unix/howtos/gimp-m idi.html> for a HOWTO on controlling GIMP with MIDI devices.
On a related note, see ahref=http://gimp.org/unix/howtos/gimp-midi.htmlr
Gestures might be a nice idea for the future. Perhaps you want to try to come up with a more detailed proposal on how this would work?
GIMP explicitely allows non-free plug-ins and the main reason for doing that is to allow such technologies to be added. Someone just needs to do it.
http://bekstation.bek.no/piksel/piksel06/video/pip pin_gegl_presentation_01.oggp pin_gegl_presentation_02.ogg
http://bekstation.bek.no/piksel/piksel06/video/pi