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."
Yes I am infact doing Imlib2.0
I already have a bunch of code and am working on it to get it to a usable state asa library so I can actually start using it in Enlightenment for testing.
I have played with some code to have a modular loader system similar to that of the Amigas Datatypes - loaders are just dlopen()'d loadrs with a standard API (allowing for multiple loading phases - I have to finalise this but it will mean easily codable loaders - anyone can then extend the loading ability of their apps by dropping a file in a directory. The rest is simply magick.
As for the rest I have been working on optimised rendering and scaling routines - I have full anti-aliased scaling down and up happening (it defintiely is faster than imagemagicks' scaling.. and that is with the program rendering to the display AND dithering as well). The internals now use RGBA instead of RGB and I have on my list to add alpha blending when drawing an image to a drawable (I have previous code that did this before). When I add caching back in (easy) and actually finalise the loader api I'll start having something that can be used. After it all works client-side I do most defintiely plan on working on putting a lot of the core of this into the server for sheer speed reasons. This should mean even more speedups.
So the rumors are corect - I'm working on it.. just haven't had too much time of late... but now I have piles of time to make this happen and happen fast and well... so expect something in the near future.
I will add more image processing functions too once the base loading and rendering is done and works well.
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
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.
Brace yourself. The KOffice team is working on Katabase, which seems to me like more or less an Access clone (and it won't be backed by any existing database servers I think).
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
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.
KDE developers just seem to suffer from a bad case of NIH syndrome, especially when it comes to software that is closely associated with gnome (note that imlib does not depend on gtk+ or gnome in any way). Plus clever marketing, announcing this as if it were some ground shattering event seems hardly necessary.
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.
The point being that unless the Gimp developers give their permission, linking Gimp (or a hacked version) with QT with the old QT license would violate the license of Gimp.
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.
Dude, where do you get this stuff? Yes, it is a collaboration between developers.
And what exactly do you mean by "kimp" affair? All that happened is that Matthias hacked Gimp for a couple of hours to show how Qt and GTK code can be intermingled for a presentation he was giving. After there was tremendous interest shown in the new funky interface he had come up with, he presented the patch to the Gimp developers and was silently ignored. That's it.
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.
From the imlib home page:
"Imlib is a replacement for libXpm"
It is an abstraction layer for X11. It is *not* an effects library like ImageMagick. Two totally different functions.
I must have said this like 5 times already. What is the part that is so confusing? The two packages do two totally different things.
mosfet@jorsm.com