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."

Re:Duplicated Effort?

[Fafhrd]

KDE used CORBA first, worked with multiple languages first, etc, etc.

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++...

Re:Imlib 2.0

[raster]

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.

Re:Are you high?

[gavinhall]

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!

Imlib equiv?

[Mawbid]

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 [redhat.com] for more info.
--

Database tools...

[RPoet]

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).

Re:imlib?

[Dion]

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.

Why??

[Bwah]

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

Collaboration or permission?

[cjr]

From the announcement it seems more like a certain developer got permission to use ImageMagick code for KDE extensions. Good thing as it prevents another "kimp" affair.

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.

Re:Duplicated Effort?

[Anonymous Coward]

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.

Re:Why?? NIH

[Anonymous Coward]

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.

Re:Duplicated Effort?

[wimpy]

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.

Duplicated Effort?

[Outlyer]

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.

Imagemagick a technically good choice?

[Florian]

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.

Re:Because ImageMagick != Imlib

[Millennium]

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.

S&P Quick Gimp?

[Anonymous Coward]

S&P worked on GIMP for 9-10 months before releasing thier first bit to the public. And if you'll think back a bit, 0.54 was pretty buggy.

For this and more facinanating early history tidbits, see my gimp history page [gimp.org]. I should probably update that some day :)

Seth
[e-mail]

Re:Duplicated Effort?

[Alex Zepeda]

What? When was this opinion expressed on the kde-devel mailing list? Oh yes, I remember. When the topic of Gnome was brought up. This is *not* a duplication of effort at all, as it extends the kimageio class to more image formats than were previously available. This provides a nice clean extensible inteface for displaying graphics. This means one can inline all sorts of weird formats in HTML and Konqy will be able to display it.

Sure imlib does bunches more, that will likely be integrated. But keep in mind that the Gimp team as a whole has been very anti-Qt and in general inflexible when dealing with Qt (kimp comes to mind).

You may call it duplication of effort, but I call it diversity. What's so wrong with a little friendly competition for Gimp. Is the Gimp devel team afraid of another OpenSource image manipulation tool? Hmm.

For the most part, no, I'm not interested in Gimp at all. I'm interested in something that works, not something that makes a knee-jerk political statement.

Good.....

[Jonathan Hamilton]

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.

Re:argh.

[Anonymous Coward]

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.

Corrections

[Anonymous Coward]

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
[e-mail]

Re:Duplicated Effort?

[HiThere]

What you pay for commercial packages is $$. And a lack of choice about which features are available (except to the extent that you can choose among packages).
What you pay for GPL packages is time. BUT, to the extent that you can use it, you can use it WITHOUT having to buy it. If it does what you want, great! If not, then use something else, wait, or fix it yourself. Things available in beta are actually there, but they've got problems. You can usually get the beta if you want to, but it may have danger warnings painted all over it.

Re:Duplicated Effort?

[Alex Zepeda]

Gee where have I heard this before? Oh yeah, have you heard of Gnome? Oh please don't tell me how Gnome actually offers something KDE doesn't. KDE used CORBA first, worked with multiple languages first, etc, etc.

However, unlike you sir Anonymous Coward, the ImageMagick integration is far from a "widget-wars" response. KDE lacks image manipulation classes, and ImageMagick can provide them. Why should we be stuck with only one set of im classes? I thought that the whole Linux mentality (besides egoism) was diversity? Oh yeah, diversity as long as it's Linux, x86, Gtk+, GNU, etc. Hrm. Gee why does that sound so familiar? Bill Gates perhaps? Nahhhh.

Clarifications

[Anonymous Coward]

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
[e-mail]

Re:imlib?

[jamie32]

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.

Re:Imagemagick a technically good choice?

[Yarn]

personally I like imagemagick because it has lots of CLI utilities, tie em together with scripts and you can do *lots* of useful stuff. It's frontends are less inspiring (I always use gimp for that), but its the old unix "small programs glued together" methodology that I like.

Re:Duplicated Effort?

[AmJur2d]

But keep in mind that the Gimp team as a whole has been very anti-Qt and in general inflexible when dealing with Qt (kimp comes to mind).

The GIMP team is only anti-Qt to the extent that Qt's license is incompatible with GIMPs.

KDE is free to burn resources rewriting GIMP; nobody (and I do mean nobody) on the GIMP team will care.

Well that is part of the problem

[Anonymous Coward]

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.

argh.

[Anonymous Coward]

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.

Re:argh.

[mill]

Umm, which interpretation is the right one? Yours? If they had chosen your's, for example, it would be their's too, so in the end the only one that matters is their own.

Easy to ammend IF all authors agree and are available.

/mill

Imlib 2.0

[Iggy]

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, :)

Re:License (get a clue please)

[Anonymous Coward]

It's artistic, and will probably end up being the KDE artistic license.

[e-mail]

imlib?

[Anonymous Coward]

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.

Why was this moderated? I was wondering the same

[Anonymous Coward]

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.

Re:argh.

[AmJur2d]

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.

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.

Re:argh.

[Anonymous Coward]

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
[e-mail]

Re:Duplicated Effort?

[Alex Zepeda]

There are none. Demand is the driving force behind bindings for these extraneous languages, if enough people want them, someone has enough desire to create one. Hell if you pay me to learn ObjC I'd write the bindings.

Re:Imagemagick a technically good choice?

[drunken monkey]

I'm using ImageMagick in some Per/CGI work. It's really cool. I can read one format of image, resize and save it as another in 3 lines of code.

narbey

Re:Good.....

[Anonymous Coward]

KDE 2.0 does not integrate with WindowMaker code or WindowMaker concepts which I think is a shame. Combined with Mac OS 7/8 borders, boxes, look and an interface that looks unlike Windows 98 for me that would be interesting, and I guess if people could try they might appreciate something that does not look like Windows 98 first and only. Even KDE 1.1.1 can only configure to 'look' like Mac OS, many parts were missed, look at them

OpenStep
Mac OS 7.6
Mac OS 8.5

in terms of what is displayed on screen and what mouse and keyboard interaction is available..

I guess I miss that old Mac after all ;-)

Again, imlib is not anything like ImageMagick

[Anonymous Coward]

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.
[e-mail]

Re:Imlib 2.0

[Anonymous Coward]

(please ignore the problems generated by the
f'ed right shift key on this keyboard :-)

Bear in mind that imlib uses Imagemagick as
a fall back -- the latter is more complese.

Imlib is LGPL, not GPL -- though if it were
to become an X extension, then it would
realistically have to change license to the
mIt X license.

So far as the teaming up on object technology
goes, the GNOME project really need to dump
baboon, and work with the KDe project on their
object model (it is more mature, and is
designed in the image of openDOC rather
than OLE/COM)

n.b. the language binding MUST have a license
no stronger than Lgpl. (the danger in liberally
using GPL is that it forces duplication of
effort by those that support free software,
but not the extremist anti-proprietary stance
that the GPL represents)