Posted by
ryuzaki0
on from the merry-christmas-to-all dept.
&& writes was the first to tell us that The Gimp has now reached v1.2.0. Congratulations
to all the hackers that made it happen. I couldn't live without my gimp! (God I love saying that)
"anyone implementing software according to the description available in this FCD, risks not being compliant with the final JPEG2000 International Standard (IS), which is due to be published some time in 2001 as IS15444-1.
So don't expect any projects either to implement JPEG2000 yet or to be able to get JPEG2000 patent licenses (see below) to do so yet.
2. Another important issue (stated here) is that the royalty-free fee-free JPEG2000 patent licenses may apply only to conforming implementations. One such requirement of conforming implementations is to have copy control implemented including methods
1) To protect access to the image
2) To
identify the image, source or owner in a secure way that cannot be removed by unauthorised parties.
3) To indicate integrity (images that are not allowed to be edited).
It is not clear how the patent holders will interpret these requirements for open-source implementations that want to use a GPL license (as for Gimp) which requires the whole software to be modifiablefor any purpose, potentially in ways which could violate the conformance requirements.
Why is everyone comparing this with Windows?
by
bl
·
· Score: 2
Having worked in software, hardware, networking, AND graphic design/layout for many years, I would like to ask one question of those of you who've submitted posts comparing gimp on linux with Photoshop on Windows. Do you know anyone that uses Photoshop on Windows? All the designers I know (myself included) would always use Mac OS (given the choice). While the gimp is a good option, a powerful program, it's not designed for Mac OS. Since professional printers want files submitted on HFS format disks, generated using the AdobePS driver on Mac OS (if this combination is possible), it just makes sense to do it that way. Unless you have personally experienced the headache of trying to create files in Gimp's native format, then export them to tiff, then ftp them to a Mac, then import them into Photoshop-native format, make any necessary corrections, and export them again to.eps (if you use PageMaker, not necessary for InDesign), you'll realize that it's just so much easier to make your file in photoshop and place it into a publication. When gimp makes it to the platform that a majority of graphic designers use (Mac OS), is stable, and has the support of Adobe programs, I would pay as much for it as I pay for Photoshop (which is a lot). I don't see that day coming any sooner than I see Microsoft throwing Windows away, shipping a $200 version of Linux to the OEMs, and porting all their software to Linux. The gimp does, have a distinct advantage over Photoshop in one regard: since thousands of people bootleg Photoshop every day, they have another option where they can give away as many copies as they like without breaking any agreemets!
Happy holidays all.
Brandon
Re:great program, but it isn't keeping up
by
Bruce+Perens
·
· Score: 2
No. First, doing image processing the way he suggests has been tried by a number of others (me included). It's so much simpler to operate directly on a raster that the users themselves have abandoned this sort of program as they've gained access to machines that can handle the full resolution image.
Second, listening to the customer on design decisions this is unfortunately a way to be a follower, not a leader, because the customer doesn't know what they want until it's too late. In the case of this idea, much too late.
Third, that's just not the way Free Software works. Coders do what they want to do, and the user's needs are a distant second to those of the developer. A very large and healthy commercial market exists if you want things the ohter way around.
I'd also like to have 'live effects' (essentially effects like drop shadow, etc. that can be applied, removed, and modified at will without making a permanent change to the image). I find that I use this feature a lot with Photoshop. Support for vector types would be good too. The best overall image editor that I've been using lately is Fireworks 3. It can do much of what both Photoshop and Illustrator can do, has a superior scripting capability, and is much cheaper. Each editor has it's strong points, but I could have only one, Fireworks would be it. If Gimp is going to pick a direction to go in, aiming to reproduce the Fireworks feature set would be a good start.
Re:Please improve the documentation
by
johnnyb
·
· Score: 2
Re:Who was complaining the other day...
by
ikekrull
·
· Score: 2
To a large degree, 'multiresolution editing' can be achieved by specifying the resolution of everything - brushes, filter parameters, selections etc. in some kind of global coordinate system, instead of being pixel-based.
So, when applied to a 100x100 pixel image, a blur filter with a radius of '2' has an effective radius of 2 pixels, but on a 1000x1000 image, has an effective radius of 20 pixels. This may or may not be the effect you desire, but a toggle between pixel and global coordinates shouldn't be a major.
However, since bitmaps are necessarily pixel-based, you run into problems when you try and duplicate the effect of a 16x16 pixel brush to a 32x32 pixel image on a 3200x3200 pixel image.
You either end up with an extremely pixelated brush, or you specify the brush in terms of a clipping path and a fill-pattern.. Nasty.
You could also simply scale up the brush and apply a vector clipping path, but youd end up with a hopelessly pixellated brush with perfectly smooth edges.
Either way, you might as well use a vector drawing program, or create your images at the largest possible size and invest in a supercomputer to render your edits in close-to-real-time.
Image pyramids and wavelet/progessively encoded images have their uses, but i think most professional designers would rather stick with the tried-and-true Photoshop, working on fat machines with lots of RAM than work with these unconventional technologies.
Thats not to say I don't think it will happen, but rather that these things take a lot of time to mature.
-- I gots ta ding a ding dang my dang a long ling long
Re:great program, but it isn't keeping up
by
johnnyb
·
· Score: 3
A few things:
1) Doing things automatically, like image-type conversions for saving, is _not_ user-friendly. That's a terrible interface, because the user just thinks he's saving, when in fact, he is both saving and converting. That is very, very bad. File formats are more than just internal representation differences. The differences show up on the outside, too.
2) In GIMP 1.2, for most conversions, it will actually notify you of the problem, and pop up a new window to show you what the preview of the saved version will look like. That is a _great_ design. You are both notified of the problem, and started into the process of fixing it. It works wonderfully.
3) I actually prefer GIMP's user interface to most others I've seen. It doesn't take a lot of screen space, everything is easy to get to, and it just works really well. For newbies, having to right-click on the image sometimes takes getting used to, but once you tell them about it, within a day they love it!
Live effects are spiffy at first, and for some things they work okay. The problem I, and most other perfectionists have with them though is a lack of flexability. It is just as easy to make drop shadows without 'effecting the image' on grouped layers that you have TONS of control over. I'm the type that goes and airbrushes variations into my artwork. Stock shadows and such just don't cut it.
Now though, they do have their place in scripting. If you want a bunch of cheaply made web images with drop shadows you can really smash them out with an "action." In general though I don't like them enough to ever use them. Something I would much rather see in Gimp now is a freakin' VISABLE BRUSH EDGE.
Now for those of us stuck in the windows world, the wait begins for it to be ported to the Windoze C Libraries and recompiled. I hope I can have my GIMP up and running in the next week.
Secret windows code
-- Clinton made me a Republican.
Bush made me a Libertarian.
Trump is making me question reality.
GIMP 1.2.0 works ok on my machine (Solaris 8, SPARC). I don't know if Solaris 8 and Solaris 7 packages are compatible or whatever (I've never built a package before), but I can try to build a binary package if you need one.
Re:Why would anyone bother with PhotoShop now ???
by
robertchin
·
· Score: 2
It should be fairly easy to run X applets on OS X if you have the proper libraries installed. Since XFree86 now runs on OS X, all you need to do is to write a simple app to watch the X11 port and display the application, just like what you're able to do with X Servers for windows.
As of v1.1.31 up to 1.2.0, something broke along the way that causes serious (fatal) problems on Solaris 7 on SPARC hardware. GTK, Glib, etc. all up-to-date.
Gimp-WARNING **: module load error:/opt/gnome/lib/gimp/1.2/modules/libcolorsel_gtk.so : ld.so.1: gimp: fatal:/opt/gnome/lib/gimp/1.2/modules/libcolorsel_gtk.so : open failed: No such file or directory
Gimp-WARNING **: Failed to open palette file/RAID/home/michael/.gimp-1.2/palettes/Bears: can't happen?
Fun stuff like that. v1.1.30 was the last known to work. With v1.1.31, SMP support broke and was quickly fixed in v1.1.32 so that it would at least compile again, but something is still wrong. Possibly something in the code re-organiation...
great program, but it isn't keeping up
by
q000921
·
· Score: 5
The Gimp is a great program, well written, and very useful. But I'm afraid it isn't keeping up with technology.
One area is probably fairly easy to address: photo manipulation programs are used more and more for web design and page layout, and for that, they need features like better vector drawing support, page layout and text support, and output plugins for formats like Flash.
Another area is more fundamental. The Gimp right now uses bitmaps as its fundamental data representation. That makes even simple operations very compute intensive, and even simple operations take up a lot of resources to undo. Combining wavelet-based and multiresolution editing with edit lists provides a way out: it allows the results of operations to be displayed quickly, operations can be undone quickly, and often images (e.g., JPEG2000 compressed images) don't even have to be decompressed fully to be displayed or manipulated. I think addressing this issue will require a fundamental rewrite.
Anyway, for now, I'm really grateful to have the Gimp available: it's a reliable workhorse, and even most commercial programs are still behind the state of the art.
Re:great program, but it isn't keeping up
by
Bruce+Perens
·
· Score: 2
GNUmed is an interesting example. It's a vertical-market application. I'm not sure that's near the bottom of the list of things we do best so far, but it's not at the top. For better or worse, we seem to do systems programming best so far.
In their place, I would be writing grant applications right now. Having written those before, I can tell you it's a distinct possibility to get grant funding for this sort of application.
Whether or not it succeeds depends on their finding programmers to do it while being paid, or (and this would be worse) volunteers willing to do it for the cause. Grad students on a grant will be willing to do it to an external specification. Volunteers? They will want to have a lot to do with the design, and will leave doors open for implementing those features they aren't interested in, but will they do them? That's a very chancy thing.
Re:great program, but it isn't keeping up
by
q000921
·
· Score: 2
First, doing image processing the way he suggests has been tried by a number of others (me included). It's so
much simpler to operate directly on a raster that the users themselves have abandoned this sort of program as
they've gained access to machines that can handle the full resolution image.
Well, I have implemented image processing routines of both types myself. Yes, implementing filters on the full resolution image is simple and well understood. It is also the most general, and you can implement a great variety of filters easily that way.
But the most common operations can be implemented in a pretty straightforward way in a compressed multiresolution representation as well. I'm pretty sure that a system that performs such operations would help a great number of people doing day-to-day operations much more efficiently. I also think that it is possible (with on-the-fly decompression) to reuse many of the full resolution filters in such a system without rewrite (but also without the associated performance gain).
Third, that's just not the way Free Software works. Coders do what they want to do, and the user's needs are a
distant second to those of the developer. A very large and healthy commercial market exists if you want things the
ohter way around.
Speaking as a user, I think there is nothing wrong for the authors of free software to be aware of what users think and what limits they hit. The Gimp is really hitting its limits for me, and I suspect for many other users as well, when it comes to dealing with the kind of data digital cameras and scanners spit out these days.
Now, let me emphasize again that I think the Gimp authors have been doing and are doing a great job, they are under no obligation to even consider this issue.
But even as the step towards a new free software project, talking about the limits of existing systems and possible new approaches in the context of an excellent and established free software system like the Gimp seems like the right place to start: that's where people with similar interests are likely to be found, after all.
This probably doesn't matter to most people, but The GIMP is open source.
If over the course of your life you've grown frustrated and irritated with companies' lack of support and care, then you might come to appreciate open source for its own sake.
While a proffesional graphics designed should use whatever tool best does the job, someone who only uses Photoshop casually might decide to use The GIMP even if it lacks a feature or two, just because it's open source.
I don't know much about GIMP's technical superiority(if any) over Photoshop, but I use it because a) it runs on my machine, and b) it's open source.
That's enough for me(but I don't make my money off it, either:).
Dave
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
--
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Re:Why would anyone bother with PhotoShop now ???
by
BPFH
·
· Score: 2
How about proper CMYK support? Colour management profiles?
As much as I dig the GIMP, it unfortunately does not do very well as a prepress tool yet.
-- -BPFH
Re:Why would anyone bother with PhotoShop now ???
by
johnnyb
·
· Score: 2
Gimp 1.2 lets you later change type after its been typed in. However, it does not let you change type after it has been put through effects.
Re:Why would anyone bother with PhotoShop now ???
by
cduffy
·
· Score: 2
No duotones or pantones, and furthermore they never will happen due to legal issues. CMYK is only sorta supported -- you can decompose your image into CMYK, edit the layers and recompose, but it's a far cry than the seamless RGB support.
Editable type is available via "Dynamic Text" support (a plugin?). Kerning (and possible leading) is available via the FreeType plugin. However, I don't know whether it works simultaniously with Dynamic Text (or reimpliments its features).
No commercial color management systems are supported, or will be, due to licensing issues. Sucks, no?
As many levels of undo are supported as you need.
Not sure 'bout recordable history.
Re:Who was complaining the other day...
by
ianezz
·
· Score: 2
I say I'm not exactly sure what you mean when you say "multiresolution editing"
Probably he means the image you are manipulating is only a preview of the image (smaller resolution), while editing operations on the "real" image are queued, so they can be performed later on the real image.
This would let you quickly edit an image using a lower resolution, and when you are satisfied with the result you could reapply the same operations on the final image (and go for a coffee or two).
This could be implemented using scripting, of course. Basically, what is needed is a way for the Gimp to record macros and then apply them on another versione of the same image (with more resolution).
Another possiblity would be to have the queued operations be performed in background while you are still editing.
In any case, it should be really useful:
if your machine is not fast enough:-)
if the images are really huge, so working on a preview is OK.
AFAIK, there is some work going on to separate the GIMP rendering engine from the GUI, so it can be integrated/reused in other programs). As a side effect, it could also allow doing this.
Why would anyone bother with PhotoShop now ???
by
Flabdabb+Hubbard
·
· Score: 2
I really think its amazing. The Gimp now provides us with every feature that Photoshop does, and then some. Why would anyone PAY for Photoshop now it defies belief.
I honestly think that Gimp is the best advertisment for Open Source we could wish for, and now that PhotoShop is redundant, I look forward to the death of 3DStudioMax !!!:-)
Re:Why would anyone bother with PhotoShop now ???
by
bolouie
·
· Score: 2
The only problem is that it doesn't run under Mac OS X. You forget the Photoshop revenue for Adobe is still split ruffly 55/45 in favor of the Mac.
Someone needs to spend a weekend porting over GDK in GTK+.
The reason you wont see GIMP in more places is because most newspapers use Apple Script. A very powerfull scripting language that automates there work flow. Also I haven't seen Quark, or InDesign importing GIMP files as of late.
"How The Gimp Stole Adobe's Employees' Christmas Bonuses".
'nuff said:)
- Rei
-- "Are you hungry? I haven't eaten since later this afternoon." -- Primer
Re:Who was complaining the other day...
by
q000921
·
· Score: 2
Well, recording and replaying is one approach to getting some of the benefits. But it isn't quite what I mean.
If multiresolution representations are implemented well, you perform the image processing operations directly in the compressed domain and often never have to touch most of the coefficients in the image. Many forms of color adjustments (with or without masks), sharpening, smoothing, and painting fall into that domain. There is no need to replay anything, and you can inspect full resolution results instantly.
Re:Who was complaining the other day...
by
q000921
·
· Score: 3
Those are good and valid questions. Let me provide a bit more information.
It seems like there may be a paper that you should have provided a link to...
A readable reference is Stollnitz, DeRose, and Salesin: "Wavelets for Computer Graphics".
First question: why isn't Moore's promise of faster processors+more RAM sufficient for the GIMP (I've only used it casually, so I may have not noticed it as being as slow as other people...)
Depends on what you want to do with it, how much time you have, and how much you are willing to pay for the hardware. You can edit a single 2000x3000x8 image on a PentiumIII with a few hundred megabytes just fine. If you want to composite six of those images, it's going to be painful. If you want to color correct a hundred of them, it's going to be painful as well. If you want to edit a 600dpi 16 bit scan, you are talking 210Mbytes just for a single image: a lot of data to move around, and a big chunk of address space.
Second question: if the GIMP isn't keeping up, and other commercial programers aren't keeping up.... then who is?
And even if these hypothetically Jonses do exist, what is the quality of images using their edit-while-compressed
technology? Who said it was commercial quality? The computer scientist who invented it... or a professional graphic
artist?
Done right, there should be no difference in quality. Not all operations can be done fast in the compressed domain, but enough common ones can be to make this useful.
Who is doing it? I think you are going to see a lot more of that coming pretty soon in systems like Photoshop. In part, they are probably waiting for JPEG2000. There are also a number of research packages (downloadable) that do wavelet-based image processing, although often with different applications in mind.
Incidentally, the fact that the commercial market hasn't picked it up doesn't mean it isn't mature. Photoshop users for years thought that "scripting" was an obscure and advanced functionality.
Third question: I beleive I'm not alone when I say I'm not exactly sure what you mean when you say "multiresolution
editing"... at least not in a way that would require a total rewrite of a program... care to elaborate?
See my other response; basically, what I mean by it here is being able to perform many image operations without touching every pixel (I should perhaps have said more properly "compressed domain editing" or "wavelet-based editing", but those terms have their own problems).
Let me emphasize again that I'm not complaining about the Gimp: I think it's a great and useful program and its developers have done a terrific job. However, I regularly hit its limits and there aren't any good commercial alternatives out there either. I think this is a good opportunity to start applying some pretty well understood computer graphics technology in an open source project.
Who was complaining the other day...
by
adubey
·
· Score: 2
...that faster processors are useless and dammit what we need is more bandwidth?
Hmm.... in light your post, I want a recount!
On a more serious note, I have some questions for you;)
First question: why isn't Moore's promise of faster processors+more RAM sufficient for the GIMP (I've only used it casually, so I may have not noticed it as being as slow as other people...)
Second question: if the GIMP isn't keeping up, and other commercial programers aren't keeping up.... then who is? And even if these hypothetically Jonses do exist, what is the quality of images using their edit-while-compressed technology? Who said it was commercial quality? The computer scientist who invented it... or a professional graphic artist?
Third question: I beleive I'm not alone when I say I'm not exactly sure what you mean when you say "multiresolution editing"... at least not in a way that would require a total rewrite of a program... care to elaborate?
(It seems like there may be a paper that you should have provided a link to...;)
Slashdot Mirror
Hmmm... does it do CMYK, duotones, or Pantone colors yet?
How about editable type? With kerning and leading controls?
Support any color management systems, or is it just for low-end web only graphics?
How many levels of undo?
Recordable history?
REally, i'd like to know that. I just went to their site, and i can't find any specific document outline the features of the current release.
1. It's too early to criticise The Gimp for not supporting JPEG2000 because the JPEG2000 image standard has not been finalised. To quote the Final CD from the official JPEG2000 website,
- "anyone implementing software according to the description available in this FCD, risks not being compliant with the final JPEG2000 International Standard (IS), which is due to be published some time in 2001 as IS15444-1.
So don't expect any projects either to implement JPEG2000 yet or to be able to get JPEG2000 patent licenses (see below) to do so yet.2. Another important issue (stated here) is that the royalty-free fee-free JPEG2000 patent licenses may apply only to conforming implementations. One such requirement of conforming implementations is to have copy control implemented including methods
It is not clear how the patent holders will interpret these requirements for open-source implementations that want to use a GPL license (as for Gimp) which requires the whole software to be modifiablefor any purpose, potentially in ways which could violate the conformance requirements.
--William
Scroogle
Having worked in software, hardware, networking, AND graphic design/layout for many years, I would like to ask one question of those of you who've submitted posts comparing gimp on linux with Photoshop on Windows. Do you know anyone that uses Photoshop on Windows? All the designers I know (myself included) would always use Mac OS (given the choice). While the gimp is a good option, a powerful program, it's not designed for Mac OS. Since professional printers want files submitted on HFS format disks, generated using the AdobePS driver on Mac OS (if this combination is possible), it just makes sense to do it that way. Unless you have personally experienced the headache of trying to create files in Gimp's native format, then export them to tiff, then ftp them to a Mac, then import them into Photoshop-native format, make any necessary corrections, and export them again to .eps (if you use PageMaker, not necessary for InDesign), you'll realize that it's just so much easier to make your file in photoshop and place it into a publication. When gimp makes it to the platform that a majority of graphic designers use (Mac OS), is stable, and has the support of Adobe programs, I would pay as much for it as I pay for Photoshop (which is a lot). I don't see that day coming any sooner than I see Microsoft throwing Windows away, shipping a $200 version of Linux to the OEMs, and porting all their software to Linux. The gimp does, have a distinct advantage over Photoshop in one regard: since thousands of people bootleg Photoshop every day, they have another option where they can give away as many copies as they like without breaking any agreemets!
Happy holidays all.
Brandon
Second, listening to the customer on design decisions this is unfortunately a way to be a follower, not a leader, because the customer doesn't know what they want until it's too late. In the case of this idea, much too late.
Third, that's just not the way Free Software works. Coders do what they want to do, and the user's needs are a distant second to those of the developer. A very large and healthy commercial market exists if you want things the ohter way around.
Thanks
Bruce
Bruce Perens.
That should read "design decisions this big".
Bruce Perens.
There is a Win32 port:
http://user.sgic.fi/~tml/gimp/win32/
It's not up to date with the very latest, but it's not bad.
Brian
I'd also like to have 'live effects' (essentially effects like drop shadow, etc. that can be applied, removed, and modified at will without making a permanent change to the image). I find that I use this feature a lot with Photoshop. Support for vector types would be good too. The best overall image editor that I've been using lately is Fireworks 3. It can do much of what both Photoshop and Illustrator can do, has a superior scripting capability, and is much cheaper. Each editor has it's strong points, but I could have only one, Fireworks would be it. If Gimp is going to pick a direction to go in, aiming to reproduce the Fireworks feature set would be a good start.
http://manual.gimp.org/
Engineering and the Ultimate
No.
How about editable type?
Yes!
With kerning and leading controls?
Don't know enough about these
Support any color management systems, or is it just for low-end web only graphics?
Don't know enough about it
How many levels of undo?
Not sure exactly, but I've never hit it before
Recordable history?
Like macros? No, but it does have _very_ good scripting support. Check out http://www.cooltext.com/ to see what can be done with a little scripting.
Engineering and the Ultimate
To a large degree, 'multiresolution editing' can be achieved by specifying the resolution of everything - brushes, filter parameters, selections etc. in some kind of global coordinate system, instead of being pixel-based.
So, when applied to a 100x100 pixel image, a blur filter with a radius of '2' has an effective radius of 2 pixels, but on a 1000x1000 image, has an effective radius of 20 pixels. This may or may not be the effect you desire, but a toggle between pixel and global coordinates shouldn't be a major.
However, since bitmaps are necessarily pixel-based, you run into problems when you try and duplicate the effect of a 16x16 pixel brush to a 32x32 pixel image on a 3200x3200 pixel image.
You either end up with an extremely pixelated brush, or you specify the brush in terms of a clipping path and a fill-pattern.. Nasty.
You could also simply scale up the brush and apply a vector clipping path, but youd end up with a hopelessly pixellated brush with perfectly smooth edges.
Either way, you might as well use a vector drawing program, or create your images at the largest possible size and invest in a supercomputer to render your edits in close-to-real-time.
Image pyramids and wavelet/progessively encoded images have their uses, but i think most professional designers would rather stick with the tried-and-true Photoshop, working on fat machines with lots of RAM than work with these unconventional technologies.
Thats not to say I don't think it will happen, but rather that these things take a lot of time to mature.
I gots ta ding a ding dang my dang a long ling long
A few things:
1) Doing things automatically, like image-type conversions for saving, is _not_ user-friendly. That's a terrible interface, because the user just thinks he's saving, when in fact, he is both saving and converting. That is very, very bad. File formats are more than just internal representation differences. The differences show up on the outside, too.
2) In GIMP 1.2, for most conversions, it will actually notify you of the problem, and pop up a new window to show you what the preview of the saved version will look like. That is a _great_ design. You are both notified of the problem, and started into the process of fixing it. It works wonderfully.
3) I actually prefer GIMP's user interface to most others I've seen. It doesn't take a lot of screen space, everything is easy to get to, and it just works really well. For newbies, having to right-click on the image sometimes takes getting used to, but once you tell them about it, within a day they love it!
Engineering and the Ultimate
Now though, they do have their place in scripting. If you want a bunch of cheaply made web images with drop shadows you can really smash them out with an "action." In general though I don't like them enough to ever use them. Something I would much rather see in Gimp now is a freakin' VISABLE BRUSH EDGE.
V
Now for those of us stuck in the windows world, the wait begins for it to be ported to the Windoze C Libraries and recompiled. I hope I can have my GIMP up and running in the next week.
Secret windows code
Clinton made me a Republican. Bush made me a Libertarian. Trump is making me question reality.
You can download it here.
GIMP 1.2.0 works ok on my machine (Solaris 8, SPARC). I don't know if Solaris 8 and Solaris 7 packages are compatible or whatever (I've never built a package before), but I can try to build a binary package if you need one.
It should be fairly easy to run X applets on OS X if you have the proper libraries installed. Since XFree86 now runs on OS X, all you need to do is to write a simple app to watch the X11 port and display the application, just like what you're able to do with X Servers for windows.
US Mirrors:
ftp://ftp.insync.net/pub/mirrors/ftp.gimp.org/
ftp://ftp.cs.umn.edu/pub/gimp/
ftp://froody.res.cmu.edu/pub/gimp/
ftp://gimp.cs.stevens-tech.edu/mirrors/gimp/
ftp://ftp.ameth.org/pub/mirrors/ftp.gimp.org/
Thank you.
--
The World is Yours.
Gimp-WARNING **: module load error: /opt/gnome/lib/gimp/1.2/modules/libcolorsel_gtk.so : ld.so.1: gimp: fatal: /opt/gnome/lib/gimp/1.2/modules/libcolorsel_gtk.so : open failed: No such file or directory
Gimp-WARNING **: Failed to open palette file /RAID/home/michael/.gimp-1.2/palettes/Bears: can't happen?
Fun stuff like that. v1.1.30 was the last known to work. With v1.1.31, SMP support broke and was quickly fixed in v1.1.32 so that it would at least compile again, but something is still wrong. Possibly something in the code re-organiation...
One area is probably fairly easy to address: photo manipulation programs are used more and more for web design and page layout, and for that, they need features like better vector drawing support, page layout and text support, and output plugins for formats like Flash.
Another area is more fundamental. The Gimp right now uses bitmaps as its fundamental data representation. That makes even simple operations very compute intensive, and even simple operations take up a lot of resources to undo. Combining wavelet-based and multiresolution editing with edit lists provides a way out: it allows the results of operations to be displayed quickly, operations can be undone quickly, and often images (e.g., JPEG2000 compressed images) don't even have to be decompressed fully to be displayed or manipulated. I think addressing this issue will require a fundamental rewrite.
Anyway, for now, I'm really grateful to have the Gimp available: it's a reliable workhorse, and even most commercial programs are still behind the state of the art.
This probably doesn't matter to most people, but The GIMP is open source.
:).
If over the course of your life you've grown frustrated and irritated with companies' lack of support and care, then you might come to appreciate open source for its own sake.
While a proffesional graphics designed should use whatever tool best does the job, someone who only uses Photoshop casually might decide to use The GIMP even if it lacks a feature or two, just because it's open source.
I don't know much about GIMP's technical superiority(if any) over Photoshop, but I use it because a) it runs on my machine, and b) it's open source.
That's enough for me(but I don't make my money off it, either
Dave
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
How about proper CMYK support? Colour management profiles?
As much as I dig the GIMP, it unfortunately does not do very well as a prepress tool yet.
-BPFH
Gimp 1.2 lets you later change type after its been typed in. However, it does not let you change type after it has been put through effects.
Engineering and the Ultimate
Check out the Gimp Splash Screen History, funny stuff. Wonder what the splash for 1.2 looks like....
No duotones or pantones, and furthermore they never will happen due to legal issues. CMYK is only sorta supported -- you can decompose your image into CMYK, edit the layers and recompose, but it's a far cry than the seamless RGB support.
Editable type is available via "Dynamic Text" support (a plugin?). Kerning (and possible leading) is available via the FreeType plugin. However, I don't know whether it works simultaniously with Dynamic Text (or reimpliments its features).
No commercial color management systems are supported, or will be, due to licensing issues. Sucks, no?
As many levels of undo are supported as you need.
Not sure 'bout recordable history.
Probably he means the image you are manipulating is only a preview of the image (smaller resolution), while editing operations on the "real" image are queued, so they can be performed later on the real image.
This would let you quickly edit an image using a lower resolution, and when you are satisfied with the result you could reapply the same operations on the final image (and go for a coffee or two).
This could be implemented using scripting, of course. Basically, what is needed is a way for the Gimp to record macros and then apply them on another versione of the same image (with more resolution).
Another possiblity would be to have the queued operations be performed in background while you are still editing.
In any case, it should be really useful:
AFAIK, there is some work going on to separate the GIMP rendering engine from the GUI, so it can be integrated/reused in other programs). As a side effect, it could also allow doing this.
I honestly think that Gimp is the best advertisment for Open Source we could wish for, and now that PhotoShop is redundant, I look forward to the death of 3DStudioMax !!! :-)
"How The Gimp Stole Adobe's Employees' Christmas Bonuses".
:)
'nuff said
- Rei
"Are you hungry? I haven't eaten since later this afternoon." -- Primer
If multiresolution representations are implemented well, you perform the image processing operations directly in the compressed domain and often never have to touch most of the coefficients in the image. Many forms of color adjustments (with or without masks), sharpening, smoothing, and painting fall into that domain. There is no need to replay anything, and you can inspect full resolution results instantly.
A readable reference is Stollnitz, DeRose, and Salesin: "Wavelets for Computer Graphics".
Depends on what you want to do with it, how much time you have, and how much you are willing to pay for the hardware. You can edit a single 2000x3000x8 image on a PentiumIII with a few hundred megabytes just fine. If you want to composite six of those images, it's going to be painful. If you want to color correct a hundred of them, it's going to be painful as well. If you want to edit a 600dpi 16 bit scan, you are talking 210Mbytes just for a single image: a lot of data to move around, and a big chunk of address space.
Done right, there should be no difference in quality. Not all operations can be done fast in the compressed domain, but enough common ones can be to make this useful.
Who is doing it? I think you are going to see a lot more of that coming pretty soon in systems like Photoshop. In part, they are probably waiting for JPEG2000. There are also a number of research packages (downloadable) that do wavelet-based image processing, although often with different applications in mind.
Incidentally, the fact that the commercial market hasn't picked it up doesn't mean it isn't mature. Photoshop users for years thought that "scripting" was an obscure and advanced functionality.
See my other response; basically, what I mean by it here is being able to perform many image operations without touching every pixel (I should perhaps have said more properly "compressed domain editing" or "wavelet-based editing", but those terms have their own problems).
Let me emphasize again that I'm not complaining about the Gimp: I think it's a great and useful program and its developers have done a terrific job. However, I regularly hit its limits and there aren't any good commercial alternatives out there either. I think this is a good opportunity to start applying some pretty well understood computer graphics technology in an open source project.
...that faster processors are useless and dammit what we need is more bandwidth?
;)
;)
Hmm.... in light your post, I want a recount!
On a more serious note, I have some questions for you
First question: why isn't Moore's promise of faster processors+more RAM sufficient for the GIMP (I've only used it casually, so I may have not noticed it as being as slow as other people...)
Second question: if the GIMP isn't keeping up, and other commercial programers aren't keeping up.... then who is? And even if these hypothetically Jonses do exist, what is the quality of images using their edit-while-compressed technology? Who said it was commercial quality? The computer scientist who invented it... or a professional graphic artist?
Third question: I beleive I'm not alone when I say I'm not exactly sure what you mean when you say "multiresolution editing"... at least not in a way that would require a total rewrite of a program... care to elaborate?
(It seems like there may be a paper that you should have provided a link to...