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."
hmmm... I wonder how ImageMagick will compare on a 4096x4096 film image compared to the tile swapping in Gimp?
Then you know the answer to a question that's been bugging me for a long time: Where are the Objective-C bindings for Qt/KDE? I'll never develop for KDE if I have to work in C++...
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" --------------------
Posted by Moritz Moeller - Herrmann:
Koffice works fine. It's just difficult as hell to install the current version. You need QT2 beta and KDE2.0-libs from CVS and you need the newest mico2.2.6 and you need luck to get it all compiled with a decent compiler.
But who ever said koffice was vapourware? Just because Gnumeric or Abiword are easy to install doesn't mean they have the same functionality. Dos might be easier to install than Linux!
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.
Get a grip, imlib is tied to X, you can't use it if you're just a console app, imho that sucks, I'd like to be able to do my routine image processing without X.
-- To dream a dream is grand, but to live it is divine. -- Leto ][
Ummm ... what's so bad about imlib? I kind of liked it actually ... why reinvent the wheel? (not that I pretend to know anything about the other libs ...)
/dev
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
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.
Kif KOffice Kand KOM Kis Kjust Kamazing Kwhy Knot Kport Kit Kto GNOME? Kit Kis Ktime Kto Kjoin Kthe Ktwo Kefforts Kand Kmerge GNOME Kand KDE.
No, not exactly. After GPLing their code, the gimp developers howled loudly that Kimp violated the GPL, based on *their* interpretation.
Additionally, the idea that the authors of a program lack legal capacity to ammend the the license under which their code is released is ludicrous.
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.
(*sigh)
Why is it 'vaporware' when a big commercial company talks about what they'll have out in a year, but it's completely acceptable to dismiss an Open Source product's real, current problems with 'wait for the next version?'
Gimp has some genuine issues with large images, meaning you couldn't do professional print work to save your life, even _IF_ there were CMYK support, which there's not. As an example.
Gimp is really really neato, probably the best app out there, for Web graphics, but still can't play in the big leagues on any other turf.
And putting our fingers in our ears and chanting 'next version, next version' won't fix that.
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.
They do not do the same thing whatsoever
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 -------------------
Because you want to get KDE 1.1.2!
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
Looking at the code there is no obscene memory allocations. It may be an issue with the display app?
Daniel M. Duley
mosfet@kde.org
I apologize if I appear to have moderated this article too hastily. It just appeared redundant to me after there were at least 2 high-scoring articles already explaining the difference between Imlib and ImageMagick.
For this and more facinanating early history tidbits, see my gimp history page. I should probably update that some day :)
Seth
sjburges@gimp.org
Maybe after KDE starts to look a little better I will think about using it. Right now it looks worse then Windows 3.1. This is a good step in the right direction.
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.
Imlib was able to use ImageMagick for file conversions, that is all. Imlib does not do effects like "oil painting" for example. They are two completely different libraries for two different functions.
Daniel M. Duley
mosfet@kde.org
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.
I'll ignore your imlib comment because it's been said 180 times that imlib and ImageMagick are two totally different things. But the part that gets me is you said KDE developers have a NIH complex.
:)
I would say it's quite the opposite. GNOME has suffered from NIH far more than KDE. Look at the whole CORBA thing..."MICO sucks we're not going to make it better, we'll just write a new ORB from scratch." If the two camps would just start looking at the parts that makes each of them good and work together on standardizing on a few things (KOM vs bonobo) comes to mind we'd all be better off. KOM is great and has a much better groundwork layed than bonobo, this would be a prime place to colaborate. Look at KOffice vs. "GNOME Office", why the duplicate effort??? I would say KOffice is light years ahead right now, especially when it comes to KOM and CORBA implimentations, but noooo everyone has try and reinvent the wheel. If any one thing will hold Linux back from world domination it's lack of long term planning. Yeah it's great we have 40 different WindowManagers but gee couldn't someone's time have better served the community if they wrote project management software, or a business accounting package? I guess those just aren't sexy enough
And see how fast the Gnome Nazi moderators here at Slashdot moderate your post down.
I sent you emails but you never replied. If you are still interested email me.
mosfet@kde.org
The GPL has no definitive interpretation. It has not been tested legally whatsoever. Many people don't even know if it would hold up in court, much less how it really legally applies to software.
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.
Yepp !!!
Yet another license in KDE !!!
Great(BS)...
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,
It's artistic, and will probably end up being the KDE artistic license.
mosfet@kde.org
;-) ... you already know when!
Hope to get your KDE&GNOME - background - tile
with those gears and feet soon and for free!
Torsten
torsten@kde.org
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.
Thats good news and all.. but when will they start using PROPAGANDA? ;)
Bowie J. Poag
I was wondering why KDE couldn't just use imlib myself. I don't know anything about those libraries so that may be a dumb question.
It means Image library and is a replacement for things like libxpm, not a library to do effects.
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