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)
It's not up to date with the very latest, but it's not bad.
Brian
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!
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: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.
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.
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
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
You can download it here.
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.
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.
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.