Slashdot Mirror
KDE / ImageMagick Colaboration
kwak writes "Looks
like KDE is getting an Imlib equivalence in the just announced
collaboration with the ImageMagick team. This brings
improved graphical effects and conversions to the ever expanding
KDE code base."
This article describes ImageMagic both as an Imlib-equivalent and something that brings "improved graphical effects" to KDE. Imlib doesn't do anything I'd call graphical effects. It basically just frees you from having to deal with different file formats, visuals, colour depths, gamma values etc. and provides some basic functionality like scaling, flipping and right-angle rotation. See the Imlib tutorial for more info.
--
Fuck the system? Nah, you might catch something.
It makes good sense to me to have programs like ImageMagick and, yes, the gimp, fit in the different desktop projects we have now.
If the effort is to be no more than porting, it is worth it. If it is more, and developers of, in this case, ImageMagick and KDE, find a way to work together to create new functionality, it would be even better.
Good luck to all involved developers.
-cjr
This is essentially the view expressed on the KDE-devel list.
It's wrong of course, but they're free to spend six months or so finding out just how much Gimp already does. If they put their best people on it (which would be a really stupid thing to do) they might have something comparable to Gimp 1.0.0 some time in 2000.
Meanwhile the Gimp will continue to improve at it's own pace, and will have most/all of the PS5 features by the same time.
Anyway, although I respect PS5 (try loading the libtiff test images into any other Windows package - Boom!) it has very poor scripting, and the Gimp is destined for greater things.
If you're interested, and haven't already - check out the devel versions from CVS to see where we're going, and make suggestions to the gimp-devel list.
The Gimp in it's current form has fallen a bit behind the times
when compared to for example Photoshop 5. it's one or two
orders of magnitude slower when dealing with large images
like hires scans, and it lacks 16 bit color while even the
cheapest scanners nowadays provide >8 bit accuracy.
I think a complete reimplementation using the KDE methodology could
be actually easier and less work then to try to bring the current
Gimp codebase to contemporary levels.
So consequently, KDE is going to use developers who could be doing something new, to rewrite Gimp using QT? Sounds like a waste of valuable resources. I suppose it's really up to the developers what they do, but if they're compentent enough programmers to rewrite the Gimp from scratch, there are a lot of areas where their type would be better spent.
It's too bad that 'widget-wars' are resulting in many developers writing the same applications in QT and GTK.
Don't flame, I did specifically say that it is up to the developers.
----------------- "I have a bone to pick, and a few to break." - Refused -------------------
One of the major improvements of The Gimp vs. Imagemagick IMHO was resource-friendliness. I like Imagemagick, but it eats enormous amounts of RAM and thus easily chokes on big images (hi-res scans). The Gimp has a couple of shortcomings in its user interface (non-tearable menus...), but seems very good as a back-end application. It would be a pity if "KImageshop" had the better interface with worse core functionality.
Another point (irrelevant perhaps because I don't code software, so don't misread it as a complaint): I see a stronger need for a fully GUI-based database application like FileMaker or Access which would use PostgreSQL or MySQL as a backend than for yet another image processing tool.
gopher://cramer.plaintext.cc http://cramer.plaintext.cc:70
I remember that Imlib used to require ImageMagick, and I think it still uses it if available. This being the case, I'm still not totally sure why it doesn't just use Imlib with ImageMagick and get the best of both.
Honestly, these two DE's are getting a little bit crazy. Neither will admit where the other is ahead, so they use different stuff just to be different, at least at this point (there were genuine reasons to do this with toolkits and ORBs, but this?) It's ridiculous.
Hi, first of all Imlib and ImageMagick are not equivalent at all. Imlib is more or less a abstraction layer while ImageMagick is a general set of image manipulation routines. I think people got confused because they both start with an "I" and have an "M" ;-)
Second, the ImageMagick is not all switching to KDE or anything. I have just got an agreement to use the code with other KDE developers as a base library and to modify it as I see fit. This code will form the basis of a core KDE image manipulation system usable by all apps interested (our effects will not be limited to one app). The collaboration comes from the sharing of code, ImageMagick will still remain what it is today.
Daniel M. Duley
mosfet@kde.org
Fair enough. I was about to make a criticism on
the pointlessness of this project; We already *have* ImLib -
sure, having alternatives is A Good Thing(TM) but it seems a bit
pointless writing two libraries to do exactly the same thing, under
exactly the same license. Here's hoping they'll at least
use the same base libraries (e.g. libMagick, libgr etc.) so we don't
have another 30 libraries to install next time we want to use a K app under Enlightenment.
If i understand it correctly Raster talked about imlib 2.0 possibly being much more intergrated with the X server. ImageMagick, at the moment, doesn't offer, then i suppose neither does imlib at the moment.
:))
:)
The point is that if imlib does become an X server extension, wouldn't this be much more sensible to use than a set of add on libraries like ImageMagick.
Also, imlib is all GPL, thereby removing all the previous hassle about licenses. Wouldn't it make more sense for those people working on KDE image projects to help out with getting an imlib X extension package together, which i would guess would give much improved performance, rather than trying to add another license, learn yet another API etc.
If the KDE guys and the GNOME guys could REALLY get together and talk, the stuff they could come up with would be WAY kewl, like a singular GPL multiple language binding, fast CORBA ORB, universal X server imaging extension package, universal embedded object model to allow KWord documents to be embedded within Gnumeric spreadsheets and vice versa.
Guess i'm just dreaming of a better way of life
Just my 0.02 worth.
P,S I'm not trying to start a flame war by the way, so please don't take it that way,
I would say it's closer to getting generalized routines comparable to the Gimp. Of course the intent of all this is to make KImageShop, KPaint II and other graphic manipulation programs possible. I don't think Imlib allows any of this.
Correction. What happened was several KDE bigshots demanded that the GIMP developers grant them an exception to GIMP's GPL licensure so kimp could be distributed. The GIMP developers refused, on the basis that they lacked legal capacity to do so. No patch was ever offered.
Just to correct you a bit, no patch was ever distributed to the gimp developers, much less ignored by them. It was a demonstration of technology, and not something meant to be used appearently.
For what its worth, as a gimp developer I wish the KDE team all the best in any graphics manipulation programs they do. Having more programs, espeically where specialization and/or user preference is so applicable, is a good thing!
Regards,
Seth
sjburges@gimp.org