Slashdot Mirror
The GIMP Gets Ready for 2.2
An anonymous contributor writes "As promised, this time it didn't take another 3 years for a new stable GIMP version to be released. 8 months after GIMP 2.0 hit the road, GIMP 2.2 is almost done. The GIMP developers released 2.2-pre2 today and unless any major problems show up, the GIMP 2.2.0 release is going to follow later this month. The GIMP Wiki has a comprehensive list of new features in GIMP 2.2 and here are some screenshots of the development version."
Erm.. I can't work out if you're trolling or not ;)
Clicky for Win32 goodness
I don't read your sig, why do you read mine?
The windows version is in the screen shots, note it says Gimp 2.2 on Windows XP.
I was thinking of the immortal words of Socrates, who said: "I drank what?" - Chris Knight (Val Kilmer)- Real Genius
Then drag the tools you want into the tool window. You have all the tools in one window and your image in another. It's a far superior layout to that of PS.
Looks can be deceiving. Or CAN they?
Just to add to this, it's a cinch to dock all of the toolbars together so you only have one window with all your tools lined up + open images.
Both features you ask for are on the TODO. The GIMP developers are fully aware of the need for higher color depths. Color management is scheduled to be added in the next development cycle. Whether this also means support for 16bit per color in GIMP 2.4 remains to be seen. At some point it will definitely be added.
Macro recording needs a major redesign of the PDB but there are plans to finally address this. Nothing promised because this is entirely a volunteers' project. New features are added if and only if someone's capable and willing to put some time and effort into it.
A lot of people like to be able to select individual windows from the taskbar. If you don't, then you can configure your taskbar to group all GIMP windows together. GIMP sets the same WM_CLASS property on all it's windows (even on plug-in windows) and it has done so since GIMP 1.2. That allows the window manager and your taskbar to easily identify GIMP windows and treat them as a group. You can then minimize/maximize all GIMP windows in a single operation, move the window group to a different desktop or whatever else you want to do...
Now what would be nice if there was an equivalent window manager hint available for Win32. Perhaps there is, and all that's missing is support from the Win32 GTK+ backend?
As of Gimp 2.0, you can "dock" pretty much any window or toolbar in pretty much any other. It's pretty handy for keeping your workspace clutter-free.
If you go the GIMP preferences dialog, select the "Window Management" page and enable the "Utility window" hint for the docks and/or the toolbox, your window manager is supposed to keep the docks and the toolbox above the image windows. So you basically get exactly that behaviour.
/. readers knows more about the Win32 window API and could help to implement this in the Win32 backend of GTK+?
This is not the default because we got a couple of angry bug reports when it used to be the default in the 1.3.x series. Now what's missing is an equivalent setting that works on Win32. Perhaps one of the
Besides Script-Fu and its successor Tiny-Fu, there's Perl, Python and Lua for you to choose from. There also used to be Java bindings and probably others but I am not sure if these have been updated for GIMP 2.x yet. Generally, all the functionality is available in a well-defined API and it is not a big deal to write a binding that allows you to write scripts/plug-ins in your favorite programming language.
Don't like the GTK+ widget defaults? Use GTK-Engines to skin them.
Some things that do need changing about The GIMP are the filters and brush quality, which in general give very poor results compared to those in Photoshop. Also I'd really like layer styles (at least the stroke and overlay, and maybe drop shadow, the rest can pretty much go bugger themselves) and most importantly layer sets.
Working with an image that has 30 or 40 layers (which is really easy to do when texturing 3D models) is a huge PITA without the ability to sort them into sets.
As far as the interface war goes, I'm really inclined to side with GIMP now. Their brush editing panel is a lot easier to use than Photoshop's, which has tons of features but tends to get in the way unless you put it in that tabbed thing which makes it really difficult to use at all. With GIMP the panel just drops behind the editing window so you don't have to have it in the way, which works really well particularly with focus follows mouse and auto-raise, not to mention window shading.
I think it's time that the GIMP devels turn less toward new features and more toward really getting the quality behind the ones that they do have. Because Photoshop isn't advancing very quickly anymore and is past ripe for a take down. It's just a matter of someone stepping up to do it, though beating the Photoshop marketing and mindshare will always be tough.
The Farewell Tour II
Python scripting is in since 2.0 AFAIK.
Analogies don't equal equalities, they are merely somewhat analogous.
Actually there's an easier way to correct for a misrotated image and it's in GIMP since version 1.2. The transform tools have a Corrective mode (available from the tool options). In that mode you rotate the grid so it aligns with the horizontal/vertical lines in your image and the tool will rotate the image in the other direction so that these lines become horizontal/vertical.
GIMP 2.2 adds the often requested preview for transformations but actually Corrective mode is a lot more versatile and much easier to use especially when it comes to correcting perspective distortions.
The development version of GTK+ adds pretty nice keyboard navigation to the new file-chooser. GTK+-2.6 is supposed to be released soon so this will be on everyone's desktop soon. If you want to give it a try right now, you could use GTK+-2.5.5.
> This is very much a hassle, but I actually expect USM preview to be present in the GIMP 2.2.
There is USM preview.
There are two main reasons for this instability under windows. The first is the irregular fashion in which GTK fixes and enhancements are ported to windows-- usually at least several weeks and occasionally several months behind the linux verions typically due to testing cycles. The second is in the gimp dev cycle itself in that (and this seems common to most windows ports of OSS to windows) it's always down to one or two people to do the rather labor intensive and unrewarding task of setting up the windows binaries and installer and keeping it inline with whatever random crap MS & co. is doing this week from windupdate to prevent us from using free (speech) software. (ahem in our work enviornment... hey it pays the bills, ok? I only run *n[i|u]x at home, I swear.)
Frankly, you should count yourself lucky that somebody bothers, and that you don't have to build from source to get a working version on ANY platform, but specifically windows as its installtion cruft is most annoying, and windows users tend to be less patient with the build process.
This comment is fully compliant with RFC 527.
This has been planned for a long while, GEGL is the library that is planned for this in GIMP, by introducing a new low level library for all the core image processing a smoother path towards higher bitdepths will also occur.
There is no opposition between a graph of operations / connectable blocks and a layer tree.
Press and prepress users need it, as do print designers and layout staff. Ad agencies may also need it, if they submit ads in PDF form to be embedded into the final layout as-is (and generally they do).
A designer needs to be able to see out of gamut colour (colour that can not print on their output device / colour space), so they can adjust their image not to change too much when printed in CMYK. You see, the CMYK and RGB colour spaces do not both contain the same set of colours, so some RGB colours cannot be reproduced in CMK and vice versa. Additionally, some output devices have even more restricted colour spaces, such as a litho press for newsprint.
Having someone's blue shirt come out purple in print is an unpleasant experience that's to be avoided. CMYK support and colour management both help avoid this. If the blue-now-purple shirt is a full page advertisment, you'll care about this when the advertiser comes a-knocking.
In general, most colour adjustment for print should be done in RGB (it's easier to control colour in RGB) but previewed in CMYK so you can get a better idea of how it'll print. In the GIMP as things stand, you can't really see how your work will print.
Calibrating your display is only half the story. If you don't have proper ICC profiles for your output device (printer / press), then it does you relatively little good. If you do have a properly calibrated display and suitable output device profiles, plus tools capable of previewing your work according to the output profile, then you may stand a chance of getting decent quality, accurate colour in print.
CMYK support is a pre-requisite for press colour management support. CMYK by its self is helpful, especially with an out-of-gamut warning, but only really comes into its own when combined with colour management.
I think you'll find, frankly, that the majority of people who know what CMYK _is_ will have a legitimate need for support for it. Most people neither know nor care.
For real web development work, you should be using CSS and you can save http overhead by sending a single image and /slicing/ it with CSS,
as demonstrated here!
The only thing holding back 'efficient web dev' is the dominant browser:-(
Run it in Xnest
You should update libexif then. The bug is there, not in the GIMP code.
This has been addressed in GIMP 2.2. Shortcuts work from the image windows as well as from the toolbox and all docks.
> Without virtual desktops GIMP can be... dificult
You could download some plugins to make it look more like 'normal' windows programs.
http://registry.gimp.org/person?id=3891
There's 2 things missing in the windows version:
- Windows open/save dialog (blah gtk)
- 1 window for all windows (alt-tab, task-bar)
I heard in Gimp 3 it will be included by default.
CinePaint, formerly Film Gimp, "...is a free open source painting and image retouching program designed to work best with 35mm film and other high resolution high dynamic range images. It is the most popular open source tool in the motion picture industry -- used in 2 Fast 2 Furious, Scooby-Doo, Harry Potter, Stuart Little and other feature films. CinePaint is used for painting of background mattes and for frame-by-frame retouching of movies. It is being extended to do film restoration. CinePaint is available for Linux, Macintosh OS X, Windows, and other popular operating systems... CinePaint Features: ...
8/16/32-bits of color per channel (up to 128-bits RGBA)"
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Sorry, but the ability to easily draw a straight line has been there forever and more than five years ago a preview was added to make it more apparent that this is what happens when you press Shift. I have even been told that PS does it exactly this way.
If you think this is not intuitive enough, perhaps you should suggest a better way of doing it. You seem to have a lot of time on your hands, judging from the lengthy posts.
The default Gimp layout is actaully the same as the default Photoshop layout under Mac. I personally do not like the Photoshop layout under MS Windows. If I maximize the image I am working on, all the other docked tool windows are always topmost and cover parts of the image. With Gimp, I have every tool window docked into one nice main tool panel. If I need to change a tool, I just alt+tab, select the tool and then alt+tab back to the maximized image with nothing covering the image.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison