What's Ahead For The GIMP? 157
Ur@eus writes "Hi,
We have just interviewed Sven Neuman, lead developer on the Gimp. The interview covers the upcoming 1.2, 1.3 and 2.0 releases of the Gimp and how [they]will evolve further. You will find the interview here" Improved path support, GIMP/GNOME interaction and an improved rendering system are a few of the points that Sven addresses -- The GIMP has impressed for years and keeps getting better.
Re:Benchmarks (Score:1)
--
Re:Benchmarks (Score:1)
--
Re:Benchmarks (Score:1)
No extra optimizing software should be installed, though. Just changing the configuration of the software that the distribution comes with.
--
i tried (Score:1)
image viewing in irix (Score:1)
using open gl for the gimp would be easy, its a simple call, but it would slow the gimp down for most platforms. maybe an #ifdef FAST_GL would be a good thing...
Re:Gimp for Windows (GTK+ porting) (Score:1)
--
Re:UI (menu structure) (Score:1)
Re:Phil! (Score:1)
--Phil (channel!)
Re:A Sad Gimp Story (Score:1)
Q: What happened to the mosaic effect? (Score:1)
I recently upgraded from 1.2 to 1.0 because I needed to use the mosaic effect on something, and it wasn't present in the version of 1.2 I had. Will they be putting it back in anytime soon?
Re:Phil! (Score:1)
--
Re:Please merge that 16 bit branch back in! (Score:1)
Just so you know, that is 16 bits per channel. That's more colours than your video card handles, in all likelihood. And yes, it looks like it will be merged in.
Re:KDE integration. (Score:1)
Re:Another major bug (Score:1)
This is very likely an X configuration issue, as I'm a lazy ass and haven't bothered tackling it, so the number pad Enter doesn't even work in Netscape or Xterm....
Re:Benchmarks (Score:1)
Re:GIMP v. Photoshop (Score:1)
Re:i wish the gimp was more like psp (Score:1)
--
"Where, where is the town? Now, it's nothing but flowers!"
Re:Phil! (Score:1)
Re:How to Fix the GIMP User Interface (Score:1)
That xmms plugin you mentioned... (Score:1)
C.
Re:Advanced pointer support for Linux/.../GIMP? (Score:1)
1) Yes, X supports multiple inputs, I use the nipple pad on my IR keyboard and a mouse. Here's some relevant XF86Config lines:
Section "Xinput"
SubSection "Mouse"
Port "/dev/ttyS1"
DeviceName "Second Mouse"
Protocol "Microsoft"
AlwaysCore
EndSubSection
End Section
AlwaysCore lets it control the main mouse pointer (as per in the standard Pointer section of the config)
Ditto for stylus, the appropriate SubSections are probably commented out in your XF86Config already, if you use xf86config to generate it. I know Wacom has plenty of support, although I don't have one myself. I know GIMP has pressure sensitivity, I _think_ it has tilt/roll and erasing. I don't own one myself, but I know someone who does, and uses GIMP 1.2 prereleases with it.
Re:CMYK Color (Score:1)
1) Sketch [sourceforge.net]. It's been around a long time, and uses Python/Tk (Python/GTK in the unstable version). It has quite a few features, but the unstable version as a GIMP-like interface, and I know some people don't like that (personally, I love it). It does illustrator, svg, and it's own sk format for import and export.
2) Sodipodi [sourceforge.net]. It appears to be built on a slightly better designed codebase than Sketch. It uses SVG as a native format. Biggest thing it appears to have going for it is full 8 bit alpha channel.
3) KIllustrator. Part of KOffice, it has a crapload of import filters. Sketch outdoes it, IMO, but KDE always suprises me in one way or another.
Re:PNG and alpha transparency (Score:1)
Re:Question (maybe Troll) (Score:1)
one hope I have is that Alien Skin will eventually port to GIMP. that would just be amazing.
Fuzzy Select Tool (Score:1)
some of them pretty fast, and the fuzzy select
tool is so amazingly slow it is unusable.
Any work being done to address this?
Re:Sounds like.. (Score:1)
Throwing out your old nasty code so you can rewrite it isn't called "reinventing the wheel". It's called "throwing one away" [st-and.ac.uk]. Yes, GIMP 2.0 might take longer to be released. Provided they don't go crazy and decide to make an "application platform" instead of the thing they're supposed to be making, it could actually speed up development, because the architecture should be cleaner and easier to understand. Besides, the GIMP code isn't nearly as nasty as the Netscape code was.
Maybe you're referring to the fact that GIMP is an image manipulation/paint program, and there are lots of those out there. Not many of them are scriptable though. Very few run on Linux. Even less are open source, and let you make your own tweaks/bugfixes/improvements. Plus it's free (as in beer -- I covered the other free in the previous sentence). These attributes together make the GIMP useful and valuable to some people. If it had no unique qualities, then maybe it would be "reinventing the wheel". But that isn't the case here.
Re:Question - No, but it _should_ (Score:1)
As far as the list of features that you mention, I think someone else also made a good run-down of where they stand. I just want to point out that Photoshop did not have ANY of these features (except maybe magnetic selection) until version 5.0. That was just a year ago it came out. Now GIMP is in a similar in-between major revisions stage. As is usually the case, open-source trails slightly behind commercial products in some areas. But other features (multi-level undo) have been around for quite some time.
LoppEar
How bout a fricken line tool!!! (Score:1)
I'm probably out of touch cause I've only used 1.04 and earlier versions. If they haven't added such shape tools to the 1.1 or 1.2 then I hope they keep taking their blue matrix pills each night.
"I can only show you Linux... you're the one who has to read the man pages."
Pantone colour - Photoshop has it, Gimp doesn't (Score:1)
vectors (Score:1)
Re:How bout a fricken line tool!!! (Score:1)
Compare apples with apples (Score:1)
Web Page? (Score:1)
Re:Wavelet/Multiresolution Drawing Support (Score:1)
I think that you are confusing two things: wavelet coding of an image and hierarchical editing. Wavelets should can be useful for the final output (saving the final image as JPEG2000), but they should not be used as the internal representation while you are editing the image. You cannot (in most cases) mix wavelets and lossless editing.
On the other hand, some kind of hierarchical editing can be interesting if you are working on huge images. It could be implemented by extending the current concept of layers in the GIMP, and it would not even require a major re-write of the plug-ins and tools. If I have too much spare time (cough!), I may even consider implementing this for version 1.4 or 2.0.
The only thing that would have to be done is to allow the layers of an image to have different resolutions. So the background layer of the image could be stored at 300dpi while the other layers are stored at 2400dpi. Most of the plug-ins and tools work on one layer at a time and are independent of the resolution of the image, so they would not have to be modified. Some other operations such as "Merge visible layers" or "Bump Map" would have to be re-written, but it should not be that difficult.
But I am not sure if there would be a big advantage in doing that. You would save some memory, but several operations (including displaying the image) would be slowed down because it would be necessary to check the resolution of all layers and to re-scale them at the same resolution before merging them.
Re:Mixed vector/pixmap layers, non linear history? (Score:1)
Here are some answers to your suggestions:
Many things are already possible with the upcoming version 1.2 of the GIMP. I suggest that you have a look at the tips and on-line help that are distributed with the current version, or that you have a look at some of the recent books, such as Grokking the GIMP [gimp-savvy.com] or the GIMP handbook by Sven.
Re:A Sad Gimp Story (Score:1)
Hey Sven, it's better if you include a link to your great FreeType plug-in. :-) Here it is: http://freetype.gimp.org/ [gimp.org].
Re:For Web Use? (Score:1)
Some parts of the user interface should definitely be improved, and hopefully this will be easier to implement in version 2.0. I don't think that any of the current developers would implement the full range of features of "Save for Web" or ImageReady in version 1.x. However, some of the features that you are looking for are already there. For example:
These features could be integrated a bit better and presented in a way that even new users find them easily, but they exist already. One thing that could be improved in the future versions is the "Export" feature which could include some features of "Save for Web": for example, a preview for GIF and PNG (not only JPEG) allowing you to change the number of GIF colors easily and compare the results with the original.
It is already there: look for a file called ps-menurc in the top-level directory of the source distribution. If you install this file in your ~/.gimp directory, you will get the same keyboard mapping as PS.
Re:Mixed vector/pixmap layers, non linear history? (Score:1)
I see... What you want is the QuickMask feature that is available in the latest releases: by clicking on the little square buttons that are in the bottom left corner of the image, you can activate the quick mask which allows you to view your selection as a semi-transparent mask and to edit it with the usual painting tools. When you are satisfied with the result, you can click again to convert the mask back to a selection. I think that it does exactly what you want.
This has been discussed several times on the developers' mailing list. Unfortunately, some limitations of the X Servers make this feature much more difficult to implement than it seems. Basically, it is difficult to create a cursor that is larger than 16x16 pixels, which is obviously a problem for most of the brushes.
Yep, see www.cooltext.com (Score:1)
See www.cooltext.com [cooltext.com] for an example.
Re:vectors (Score:1)
-c
"Does GIMP currently have...?" Yes. (Score:1)
The thing is, it's not mostly the same people working on the plug-ins as are working on the core. A plug-in is relatively small and easy to control, so individuals can pick whatever effect they're interested and go do a plug-in for it. These are not usually the same people who have working knowledge of gimp's more complex internals...
Plug-ins: They make GIMP do stuff. http://gimp-plug-ins.sourceforge.net/ [sourceforge.net]
--
Filter Factory (Score:1)
Photoshop plug-ins like AlienSkin can't be used with gimp. However, the "Filter Factory" filters (.afs and .8bf) files can be used with the User Filter plug-in [geocities.com].
--
Plug-ins: They make GIMP do stuff. http://gimp-plug-ins.sourceforge.net/ [sourceforge.net]
--
Re:Benchmarks (Score:1)
Someone else started a SourceForge project with the intention of doing this. I haven't seen many signs of life from over there lately, but you could try waking them up...
I also think that rather argue about the video card, it would be more productive to come up with a benchmarking suite, to decide what and how the benchmark will measure instead of where.
--
Re:GIMP naming troubles? (Score:1)
Eek! This is not what GIMP expands to. Rather, it is the GNU Image Manipulation Program. In some times past, people have used the "G" for "Graphical", but the "P" has never been Photoshop.
Opinions on how to capitalize it [oberlin.edu] are varied.
--
the development team (Score:1)
The "how many people" question is answered by Sven in the interview, I think. As for the original creator, well, that's an interesting story [gimp.org]. And "will they hire a larger team"? Umm, AFAIK, no-one (including distributions and start-ups) has any programmers on payroll for GIMP at this time, so I'm not sure who would be doing the hiring...
--
Re:Pantone colour - Photoshop has it, Gimp doesn't (Score:1)
You are correct in thinking that such a thing would have to be licensed. The phrase I hear most often for Pantone support is "patent minefield". Such a thing would be pricey, and would require a commercial sponsor with deep pockets, and the resulting plug-in would be non-free... So far, no one's offered to sponsor this.
--
Straight Line Tutorial (Score:1)
--
Tile Cache Size (Score:1)
The Tile Cache Size is in the "Environment" section of the Preferences dialog. It should be set to about as much RAM you system is ready and willing to dedicate to GIMP.
--
Re:Question - No, but it _should_ (Score:1)
As has been answered above, the GIMP does not have all of that at all. It doesn't have in-layer text editing, magnetic selection tools, or optimising features (like FireWorks and ImageReady).
If it doesn't have these specific features, then it obviously can't do "a lot of that much better than Photoshop does".
A simple save of a PNG (or some other horrendously unsupported image format perhaps?) does not count as an optimising tool/feature.
Re:Question - No, but it _should_ (Score:1)
When I first saw The GIMP, I laughed at the number of filters - it was ridiculous.
More and more filters won't bring more people to the GIMP - if they won't use it, it's because it's just not Photoshop. The interface isn't the same. When I tried it briefly a few months ago, it felt flaky and I hated it.
That, coupled with the fact that every call for graphic designers in the employment pages asks for Photoshop knowledge, and the GIMP faces an incredibly hard battle to build acceptance amongst designers.
Does the GIMP currently have (or likely to add in the very near future): editable text layers, layer effects, in-layer text editing, magnetic selection tools, multiple-level undo, integration with optimising tools, etc?
Don't waste time with so many plug-ins and filters, and refine implementation of the fundamentals. The plug-ins should be a later priority.
Re:Training? (Score:1)
I have a few clients who USE this kind of software, and my point about commercially available training *IS* based in fact! The last person I setup I WANTED to setup with the GIMP, but she knew photoshop and didn't want SEVERAL more books! Not EVERYONE is a geek who can just "RTFM" and off they go! If I could have sent her to a CLASS in using the GIMP, then that would have been different - HOW is this observation over rated?!?!?!?!
Fawking Trolls! [slashdot.org]
Re:CMYK Color (Score:1)
Re:The Trashbin (Score:1)
Yeah. Sure. Lots of people, myself included, use the Gimp to create quality images. To say that the Gimp doesn't "remotely compete" is ridiculous.
I personally do not make use of Photoshop's higher-end capabilities, such as the prepress capabilities. But, for what I do (mostly creating graphics for web pages), the Gimp works just as well, or better than, Photoshop does.
I guess there is one area where the Gimp doesn't even remotely compete with Photoshop - price. The full version Photoshop, last time I checked, sold for well over $500. While the Gimp may not be able to do everything Photoshop can, it's available to anyone since it's free software. There's no "Limited Edition" of the Gimp - the one, full version is an excellent value at a price of absolutely nothing.
Re:Large image handling (Score:1)
If you can find it, you might want to crank it.
-Mike
Re:Benchmarks (Score:1)
Anyway off to see if I can eat an apple or a pear faster. . .
Re:Looks good so far (Score:1)
Re:Improvement (Score:1)
That sounds awesome! (Score:2)
Re:How to Fix the GIMP User Interface (Score:2)
You may be interested in a critique of the UI that I did:
http://www.snowdrift.org/computers/gimp-crit.ht
The response was not entirely hostile, but the fact remains that 'code it or go shut up' still rules. Programmers are not willing to see themselves as implementing a good idea they didn't think of, certainly not willing to implement a good idea they don't agree with.
This is why non-free software doesn't have too much to fear yet. Meanwhile I've started to join in with KImageShop in the hope I can talk them round to at least thinking hard about the UI with UI hats on and not programmer hats on.
Large image handling (Score:2)
Erdas Imagine can easily pan, zoom and manipulate an image this size - yet GIMP on the same hardware (SGI O200) becomes virtually unuseable.
Imagine does this by storing several copies of the same image at different screen display resolutions in it's proprietary image format. If the same thing was done with gimp and XCF files, it would make my life a hell of a lot easier.
Nick
Re:GIMP clumsy? (Score:2)
--
Re:UI (menu structure) (Score:2)
Context menus are great -- if they're short. Long lists there (especially with multiple levels of submenus) really slow things down. A better way to do it would be to use the context menu for a few common features, and put the rest on a menubar. An even better way to do it (in my humble non-mac opinion) would be to make the right mouse button do something related to the tool selected (like draw in the background color?).
--
CGI GIMP (Score:2)
ftp://ftp.gimp.org/pub/gimp/net-fu/
Some sites using the GIMP/net-fu as a backend are:
http://www.onlinephotolab.com/
http://www.cooltext.com/
--
"Where, where is the town? Now, it's nothing but flowers!"
Re:CMYK Color (Score:2)
No, it's not. There are some simple algorithms to give you an close approximation, but that's not good enough for prepress work. The conversion needs to take account of the characteristics of the output device, such as the gamut, amount of ink bleed and so on. Yes, you can do it without worrying about these things, but the colours won't look as good in the final printed image.
Re:Please merge that 16 bit branch back in! (Score:2)
An extra bit of resolution could be achieved by shifting away the sign bit before truncation. (negative colors are not needed).
Better dithering algorithims are much more important to getting a good representation than throwing more bits at it. The vast majority of popular image file formats are 8-bit only, so a good converter to 8 bits is more important than handling 16 bits. A 16-bit file is likely to be run through a bad 16->8 converter, resulting in a *worse* result than if Gimp produced 16 bits.
A png-like standard that saves the exponent with reasonable compression would allow "lossless" storage.
Gimp 2.0 will be a total rewrite... (Score:2)
This sounds like a good plan to me. It would be really nice to be able to write scripts that run GIMP and execute efficiently. For example, if you're making images for a website, you probably want your "source" images to be in xcf (gzipped or bzipped probably), but the "published" images need to be in GIF, JPEG, or PNG. Having a script (or Makefile...) that would tell GIMP to produce the published images whenever the "source" images change would be incredibly useful. This is somewhat possible today, but GIMP has a very long startup time (so invoking it once for each image is not a good idea), plus it seems to be really unstable when running in batch mode.
Doing a "complete rewrite" will also make it easier for more developers to get involved. It's always hard to get into the code of something that's been around a while and has accumulated significant bloat. (I'm not saying that GIMP is particularly bloated, but all projects tend to "fatten" with time)
BTW, has anyone else tried to get involved in GIMP development? Whenever I went to the GIMP IRC channel to ask some GIMP development questions, people always seemed really reluctant to talk about development, and instead just wanted to talk about random subjects. Where's the place to talk about GIMP development?
Re:Wavelet/Multiresolution Drawing Support (Score:2)
Re:UI (menu structure) (Score:2)
Question (mabey Troll) (Score:2)
I was wondering if one might be able to use photoshop plugins in the gimp if someone port like a wine wraper for certain files or even did something like what was done with xmps with the Windows DLL.
Re:UI (menu structure) (Score:2)
Re:Large image handling (Score:2)
What you want to do is to increase the "Tile Cache Size" (in File->Preferences/Environment) to a value that as large as possible. Set it to a value that is close to the amount of physical RAM available on your system and the GIMP should work much faster. The recent 1.1.x versions of the GIMP (soon to be 1.2) include a nice dialog box that pops up during the installation and explains how to set up this value.
But that would only solve a part of the problem: it would still take time to refresh the image during panning operations if your the factor is 1:8 or 1:16, because the GIMP has to fetch every 64th or 256th pixel in the original image before drawing it. This leads to cache misses in the CPU, and the coordinate scaling requires some additional operations for every pixels that is drawn. As explained in other comments, some programs are storing temporary copies of the image at various resolutions in order to speed up the panning operations on zoomed-out images. The advantage is that you can move around faster, the disadvantage is that these temporary views have to be re-computed every time you change the zoom factor. The GIMP is fast when zooming in/out but slow at redrawing large images. Other programs are fast when panning a zoomed-out image, but slow if you want to change the zoom factor.
As with many other things that involve a tradeoff between CPU cycles and memory, this should probably be configurable. Yet another idea for version 2.0...
Benchmarks (Score:2)
I'd reccomend, for example:
Test suite #1: Linux System:
Redhat 6.2 default installation (no tweaks)
Window System:
Windows 98 Second Edition default installation (no tweaks)
Hardware:
Sawmill window manager (small and fast) PIII dual 650 MHZ w/ 512 MB Ram (to avoid AMD windows issues [if any]) A good Gforce2 vid card.
Test Suite #2:
Same as above but with a PII350 w/ 128 MB RAM.
True, we'd never know if it was Windows vs. Linux or Gimp vs. Photoshop, but it'd certainly be fun. I, of course, would expect the Gimp to come out on top but ya never know
Cheers,
DranoK
That is not dead which can eternal lie, and with strange eons even death may die.
Re:CMYK Color (Score:2)
--Ben
info and downloads (Score:2)
Re:A PS Feature I'd Like To See (Score:2)
Windows version of GIMP (Score:2)
located at: http://www.gimp.org/~tml/gimp/win32/ [gimp.org]
most of it works, except for some random crashes
Mixed vector/pixmap layers, non linear history? (Score:2)
Reasons I don't use Gimp (Score:2)
A complete rewrite may fix these issues.
The second thing is that if I was to use Gimp there would be no reason for me not to use Linux which then causes a new issue; I don't know what it is maybe it's my settings but I can't work well with my mouse in a linux environment I think it has something to do with the refresh rate. Now why I use ImageMagick instead of gimp for web based is as simple as this.. ImageMagick gets to the point gimp on the other hand (as convenient as it may be for some people) has way to many advanced features which then makes it way more complicated than it needs to be or than I want it. Also the support for CMYK.
Advanced pointer support for Linux/.../GIMP? (Score:2)
I use Photoshop every day. It's a critical application for me, for pretty much any and all art tasks, both for fun and profit.
I pose the following as questions. Perhaps all of these are possible today in the open-source world.
In Windows and on Macs, if you leave the mouse alone, you can use the pen or puck to click. If you leave the pen or puck idle, you can move the mouse to click and drag around the filesystem quickly. You don't have to select anything to switch. (Some Windows laptops get confused between plugged mouse and touchpad, but pen tablets and mice have mastered this co-existance long ago.) You can't draw freehand with a mouse anywhere near as well as you can with a pen, and conversely, a pen is unwieldy when double-clicking small gui elements.
Pressure sensitivity is only the tip of the iceberg here, but it is a WORLD of difference over a fixed stroke. Press lightly, thin hairline. Press heavily, bold swath. All in one stroke. Modern pen tablets understand many variables and can forward them to any interested software: pressure, tilt, roll, and even a second round tip on the back of the pen for "erasing."
Not a flame. If Linux and GIMP cannot handle these (as well as the CMYK/halftoning/separation features needed by page printers), then the GIMP is sadly relegated to web banners, stock photography edits, and other simplistic work. ART needs an expressive tool set.
What to do with the Gimp? (Score:2)
Improvement (Score:2)
Please merge that 16 bit branch back in! (Score:2)
--
CMYK? Not on screen. (Score:2)
GIMP clumsy? (Score:2)
Re:Web Page? (Score:2)
Re:Training? (Score:2)
It's got a very steep learning curve, but that is no different than Photoshop. Most of what you don't know (well, what I didn't know) was what operations I wanted to apply, in other words: what I wanted to achieve in the first place. It is hard to wrap my mind around graphics design.
I would also expect that setting up a course in using the GIMP would be difficult because of this. Then again, I'm no course designer, so...
Looks good so far (Score:2)
I look forward to the day when schools start offering Gimp classes instead of Photoshop classes.
Re:Question - No, but it _should_ (Score:2)
Don't implement photoshop plug-ins and people who have invested in them (be it money or learning-curve time) will not move to GIMP, and GIMP development will be slowed as people waste their time re-inventing wheels that are freely availible as plug-ins, leaving less time to improve the fundamentals.
It's so rare to get a useful and functioning plug-in standards for graphics. Use it, whatever the difficulty.
UI (menu structure) (Score:3)
--
KDE integration. (Score:3)
The really cool thing about it is that it will work with Gimp plugins without them being modified in any way. For those new to image manipulation on Linux most of the Gimp's power is in those awesome plugins.
So yes. For all practical purposes the Gimp will soon have KDE integration with all the power that implies ( click image in KWord and edit it in place. yada yada )
Wavelet/Multiresolution Drawing Support (Score:3)
That is, images are represented at multiple resolutions. When you edit it at low resolution (zoomed out), only the low resolution representation needs to be modified. When you zoom in and edit details, only a small part of the high resolution representation needs to be modified. Global color adjustements and many kinds of other global image processing operations can also be done very fast.
This kind of representation would allow the GIMP to work fast for nearly arbitrarily large images and arbitrarily fine detail, since processing speed is determined by the part of the image that is actually displayed and being modified. It is also a good match to the upcoming JPEG2000 standard.
But this kind of support needs to be built in from the ground up, since filters and tools need to be coded differently.
A good introduction to the subject is the book "Wavelets for Computer Graphics" by Stollnitz, DeRose, and Salesin.
When will Gimp quit being a gimp? (Score:3)
However, this last "upgrade" was only 5.5 from 5.0 and had nothing new to offer (at least for us) In fact, the only really new thing to offer was another product they're "Kind-of" integrating, and won't actually be fully integrated till 6.0
With the recent story [slashdot.org] Slashdot ran about the Insider Mac web site running "secret" information about the new 6.0 release, there were a LOT of posts saying that 6.0 wouldn't have many new features either. Even saying that the only reason Adobe was so upset about the leak was that people would find out how featureless (and waste of money) the next release would be.
And with Adobe's marketing buzzwords like "Best Release Ever".... wait... I'm sorry. I just can't be as corny as them, so I won't list any more. --But they were good!!!!
So with Adobe running out of steam for interesting ideas... When will GIMP catch up? Can Gimp catch up? How many people are working on this thing. Is it just the original creator??? Will they have to hire a larger team when they hit the "releasable" 2.0?
I hear a lot of people saying the Photoshop will rule because of CMYK. However, I hear more and more people saying that the RGB is all they need. And it's true, if all you need is WEB-output!! And obviously web graphics are important now compared to the 80's when there was no such thing.
One last thing to point out. I'm amazed at what these graphic tools can do. But what is more amazing is that it takes 15,000 apes at Microsoft to release maggot feces (read: buggy shit), but yet it only takes Adobe an extremely small workforce. Adobe is practically at the TOP of the "Net-Income-Per-Number-Of-Employees" list.
So... If Adobe can push this kind of software with their "small" gropu, I'm sure Gimp can too. I can tell you what... that Adobe will never make a Linux version! If they had their way, it'd be MAC only. It still comes out Mac-platform first. (Not as bad as it used to be, though)
Rader
Re:A Sad Gimp Story (Score:3)
GIMP FreeType, our freetype plug-in is on its best way to support multibyte fonts.
I know this isn't exactly on topic... (Score:3)
Re:How to Fix the GIMP User Interface (Score:3)
Yep, that would go a long way towards fixing it. However we are up against something bigger here. As an artist (specialising in computer work) it is becoming painfully obvious that the entire open source movement is still largely "by techies, for techies". And as long as this remains the case, any software that requires expertise outside that narrow range (such as graphics apps, games, 3d animation, possibly even word processing) is crippled by the nature of the open source movement.
A while back, I had the time to contribute to the movement. I couldn't find any projects that were looking for such help. Perhaps this was because you had to be a techie to know where to look to find such a project, or perhaps it was because many techies simply don't realise how crucial the non-programming parts are if you're trying to make a fully functional product that can compare to normal commercial software.
Hell, remember when /. reported that id Software had fired one of their developers, Paul Steed, allegely out of spite? I saw _multiple_ replies stating "Uh - Paul Steed isn't a developer, he does 3d models and art". What?!?
If this thinking is symptomatic of a significant portion of linux developers, linux ain't going anywhere beyond servers and enthusiest machines anytime soon. Windows shall forever reign supreme.
Programming is only one part of good software, and now that everyone is an artist (because they can operate GIMP or PS), everyone is a designer (because they can write html), everyone is a UI developer (because they can write code), we're going to have to deal with the fact that these beliefs are simply false. Flawless html doesn't make flawless design, flawless programming doesn't make a useful UI, flawless pixel manupulation doesn't ensure flawless communication of a concept. These are different skills, and the sooner this is widely understood and accomodated, the sooner open source becomes a genuine alternative.
GIMP v. Photoshop (Score:3)
CMYK support would be a big thing. Asides from it's print advantages (most printing is not done RGB), CMYK allows for some effective touch up. Took the pictures in a photosensitive area of a clean room (you know, the yellow light)? Convert the image to CMYK, chuck the yellow, adjust the cyan and, poof! No more yellow. The image looks normal.
However many features you give and/or take with GIMP, the reason I still will use Photoshop is just how it feels. It's sad, but GIMP may never get to that point due to the platform it's being developed on. I started using Photoshop seven years ago, and I use GIMP to play around on my Linux box, but I just don't see the two converging. Maybe that's a good thing.
How to Fix the GIMP User Interface (Score:3)
I am disheartened to read that attention is not being paid to the GIMP UI.
The GIMP has 1st class, state of the art capabilities, but it's user interface is terrible.
Believe me; I Love the GIMP, but I just had my first fight ever with my girlfriend of 3-months; it started when she said, "I don't ever use the GIMP; I will only use Corel Photoworks (or whatever it was). The $500 I paid for it was worth every penny." After sitting down with my girlfriend for about an hour with the GIMP, I had to agree that the UI was bad.
Unfortunately, I cannot "just go into the GIMP source code and fix it", the problem is larger than one lone volunteer can solve.
The UI is a traditional Achilles Heel of Free and Open Source Software. Fortunately, there is a traditional solution to the problem as well, namely embedded scripting languages and extensive customizability.
The GIMP will take off when the UI is fully customizable; Making the UI maximally customizable should become the GIMPs next great goal.
This is how to fix the UI for the GIMP.
This is how ALL OpenSource UIs have been fixed- By giving the users an easy way to customize their environment.
Okay, that's enough for now... =^_^= . o O ( Phew! )
A Sad Gimp Story (Score:4)
Development was to be Microsoft-centric. Coming from a strong Unix background, I decided to use whatever familiar Unix tools I could to get the job done in record time. Central to my strategy was Perl-Fu for Gimp. I would use it to automate the localization of the images in the product.
It worked fabulously until Korean came along. I abruptly learned that the Gimp is incapable of rendering multibyte fonts. I suppose I should have checked that feature before I started, but the point is that I ended up having the company buy a copy of Macromedia Fireworks and scripting the enxtensions in JavaScript on Microsoft. What a pity.
Anyway, I sure would like to see multibyte support in the Gimp someday.
CMYK Color (Score:4)
Re:CMYK Color (Score:4)
There is a great book you should pick up, Programming Web Graphics with Perl and GNU software, from O'reilly. This goes into detail about scripting the Gimp with Perl. You also learn about ImageMagick and other image scripting utilities.