After nearly one and half years of development Digikam 0.6 and its plugin package have been released. Digikam is a simple digital photo management application which makes importing and organizing digital photos a "snap". The photos can be organized in albums which are automatically sorted chronologically. An easy to use interface is provided to connect to your camera and preview images and download and/or delete them. Behind the scenes Digikam utilizes gPhoto2 to access your camera if it has no normal file system.

Other new features of this version are:

Simple Plugin architecture so that new plugins can be written for added functionality

Comments can be added for photos which are shown in the thumbnail display (along with file size and file modification date)

My Canon EOS 10D is doing fine in Linux :) Haven't exactly tested it with Gphoto, cause the cam itself (believe it or not) only have a USB-1.1 interface. But I'm using a highspeed USB-2.0 card-reader for dumping the pictures. And mass-storge-units like card-readers are supported by gphoto (and by regular mount/umount for the sake of the matter). DigiKam-0.6 was _TRULY_ a great release. Go on and download, it's about _THIIIIIIIIIIIIS_ much better than 0.5 was.

I can use gphoto2 with 2.6.2, .... but it is very strange. As soon as I call gphoto2 to list the camera files the kernel starts again in 'autodetecting' the USB device (It calls the binary configured in /proc/sys/kernel/hotplug). This is very anoying as it costs a lot of performance. Up to now I can not explain why this is the case ......

A few months ago I discovered digikam, and I've found it a very nice tool. I remember I was talking to a friend about how digital camera tools weren't very good on Linux (mostly because of the shoddyness of gtkam), and now I can't say thats the case anymore :)

Oh yeah, whatever happened to the kamera ioslave? I rememeber than in kde 2.

Why isn't Digikam in KDE yet? Why is it hosted on sourceforge? Is it that the
maintainer doesn't want or can't go with KDE release dates? Or is it that he
has not been invited to join into the project?

Advantages for digikam if hosted in KDE CVS: no need to look for translators
of this fine software. It will be picked up automatically by the translation
teams. It will be in 60 languages soonish, instead of 7 only...

btw, kdeextragear has many dead apps - kreatecd, kchat, smssend, kaudiocreator (even if its in kdemultimedia - it sucks coz it cant grab on-the-fly - so people rather use audiocd:/ or cdparanoia | lame)
i can't understand why they don't get removed

instead admins should add to it such apps as
digikam, kmymoney2, filelight

the digital camera interface is just an addon. there was a time when digikam used to be only a gphoto2 frontend. now its goals are ambitious and it strives to be a complete photo management application

I looked through the plugins to see if any of them can do red eye removal, but couldn't find anything. This would be a really great feature. The only tool for this on Linux that I have found so far, is a plugin for the Gimp that doesn't work very well.

I can only second that. IMHO Red Eye Removal is _the_ killer feature for any private user who mainly uses it for his private digital pictures. It's the _only_ reason I still process digital stills on a Windoze(tm) OS.

I couldn't agree more. There are two features that I as a home user with a digital photo camera really need:
1. easy renaming of a bunch of files such as present in gthumb and (as I recently learned) via the krename plugin.
2. red eye removal (found no easy linux way to do this so far).

Would be really great if Digikam would implement these features by default!

I have an older digital camera, a Kodak DC 215 Zoom. (I'll probably get a newer one soon.) Oddly it was well supported under gphoto but not ghpoto2. I just got the latest gphoto2 and built Digikam. Previously I had to load a program with a rather clumsy interface to download the images from a serial port. Because I didn't particularly like the image editing it provided and images often needed a little work I would then open Gimp, which drives me insane when I go to edit 20+ photos and my screen fills up with images. I just got the new Gimp and while it's improved it also switches all the dialog buttons around... so now I'm constantly cancelling operations and wondering why they didn't happen. (Right or left isn't as much right as playing three card monty with the ok and cancel buttons is just wrong.) Photos have been a lot less fun than they should be, and to top it all off I'm glad I only have an 8 MB memory card because gphoto is such a memory hog it can bring my system to it's knees and I can't even imagine 100 gimp windows open.

Digikam to the rescue! Not only did it provide a lot more and work with my organized photo directories, it download and deleted images and did an excellent job of basic photo editing with a decent interface... all without screen clutter, excessive system load or other annoyances. Now it's time to try out the plugins. Even cooler... the plugins are kparts... I'm interested to see if I can run them in Quanta for web work too. ;-) My only dissapointment is that it downloaded images slower than gphoto.

Hats off to the digikam developers! This is an excellent program! BTW I agree with Kurt. This should be in KDE. Also, as a note to the developers, it's really great when you do a CVS update and find that one of the really sharp people in KDE has come through and cleaned up a spelling error or fixed some little thing before it even became a problem.

> Even cooler... the plugins are kparts... I'm interested to see if I can run them > in Quanta for web work too. ;-)
the plugins are not exactly kparts (even though digikam uses the kparts interface to load and merge the plugins). so don't expect to be able to embed it in any application.

> My only dissapointment is that it downloaded images slower than gphoto.
digikam is as fast as the commandline gphoto2 at downloading/deleting pictures from the camera, since both of them depend on the libgphoto2 library. i'm assuming you are comparing it to the gphoto1.
pahli_bar

>> My only dissapointment is that it downloaded images slower than gphoto.
> digikam is as fast as the commandline gphoto2 at downloading/deleting pictures from the camera, since both of them depend on the libgphoto2 library. i'm assuming you are comparing it to the gphoto1.

That's correct, and I might add a bit weird. However since I'm not worried any more about my system getting sluggish from excessive memory usage it's less of an issue. I can go do something else while I wait. I'll have a card reader probably soon and the additional support in digikam is great.

If I could make one request... I shoot my catnip under high pressure sodium lighting and it comes off yellow. I have a system of filtering I do with gimp to offset the discoloration. If you guys have filtering like this in digikam at sometime you will be my heros.

I hate the flipping around of buttons in gnome.
And you just can't talk about that with gnome people, they have this mantra that people read from left to right, so buttons should be from left to right in order of importance. It comes frm so called gui experts.

The thing that annoy me a lot is that:
1/ I'm a personn of habits, like everybody is. So respect my habits, please.
2/ I don't use my reading faculties to find a button, I use my geographical search habilities. Which means I look for a visual point to stop my gaze, and search for the button from here. Buttons being in the lower right part of the windows, i use the lower right corner of the window, and search buttons from here, meaning I look from right to left.
3/ they keep on saying that persons with no computer use prefer that. Who in the western world is still a "person with no prior computer use", and is going to be on gnome first? This lack of pragmatism is incredible!

The thing that infuriates me the most is that whenever i try to just explain that to a gnome developper, he justs keeps on repeating the mantra that gui experts say it's best, without listening to me, a user. It infuriates me to the point that I havent even installed gnome on my desktop for one year.
And, no, I havent ever been part of the kde/gnome trollwars. I used gnome till kde2, and switched on a pragmatical basis, just like I was using gnome during kde1 on a pragmatical basis (it kept crashing on my pc, I hadnt the skill at that time to find what could be wrong).

I've used digikam some time, till I discoved that I had just to (after a quick configuration at the control center) access the url camera:/ to see my photos in konqueror. Drag'n drop them to another konqueror window. Now with some cool plugins like "batch renaming" and "html album" I'll take a look at it again.

if all you want to do is access the pictures from the camera, then camera:/, gphoto2 or gtkam might be a better option. digikam provides an integrated interface to address most of the needs of digital camera owners: organizing photos as albums, adding comments, setting dates, rotating images, raw image conversion, ..., well you get the idea.
pahli_bar

I'm real - is it necessary for a modern IDE to consume more then 240 Mb of RAM on Standby? Thus it makes real development impossible since there is no space left for helper apps or even the app you develop on. In addition its too slow for real fun. And considering the good, clean framework of kdevelop it's not impossible to see the missing features soon - in KDevelop.

No I'm seeing it from a software engineer's point of view. We switched a project from Java/AWT to C++/Qt since Java's performance and memory consumption is quite horrible and on the other hand programming with Qt is quite more productive than programming with Java. And our customers like to have their RAM for their data and not for the program alone too...

> We switched a project from Java/AWT to C++/Qt since Java's performance and memory consumption is quite horrible and on the other hand programming with Qt is quite more productive than programming with Java.

For GUIs, yes. Otherwise, no (and on WinXP Java GUIs run fine, it's only on Linux that they suck so badly - though that doesn't remove the fact that designing a GUI is easier with Qt than with Swing).

I'm the only developer using Linux in the project, all my colleagues are running XP. We all have similar configurations. I can see the difference when they start Idea or Eclipse compared to my machine. Memory consumption is relatively identical (around 240Mb for Idea), but the reactivity difference is like night and day. Of course Java is much more resource hungry than C++, nobody disputes that. XP just copes with it better, UI-wise (or the Windows version of the JDK is better implemented, whatever).

Try running one of the Swing samples on Linux and XP, if you can't see the difference then you've got a problem with your setup.

That doesn't mean a large image processing Java app will fly on XP and crawl on Linux, there are other factors in that case, like huge mem consumption or programming mistakes. One of the main problems of Java, shared with C and C++, is that the obvious way of doing some things is rarely the right one.

To make it clear: we switched an XP java project to C++/Qt despite of the poor performance. Having experiences in both languages now I can state that programming C++ in a modern way is at least as safe as programming in Java. Taking the good template support (we need fast templates, such the Generics introduced with Java1.5 aren't an acceptable solution) and valgrind into account we can deliver safer binaries as class files since you don't know what bugs the VM or HoSpot may introduce.

> Having experiences in both languages now I can state that programming C++ in a modern way is at least as safe as programming in Java.

Then you need more experience :-).

I'm sorry, but again you're considering only your own special case here. Statistically, programmers are way more productive in Java than they are in C++. That's a fact. You may be an exception (I am too, given that I'm much more familiar with C++/Qt than with Java's libraries), but I think your apparent dislike of Java prevents you from being objective. What you say is, basically, that "programming in C++ while making no mistakes is at least as safe as programming in Java".

Of course you can reduce the risk of mem leaks and corruptions if you use the right data structures. The problem with C++ is that you have to build these structures first. Qt and the STL give you quite a bunch of them, but in any project you'll still have to add your own at some point. That won't replace a GC, and that's only one aspect of the overall problem.

(and yes, generics in JDK 1.5 are a joke, everybody knows that)

> we can deliver safer binaries as class files since you don't know what bugs the VM or HoSpot may introduce.

Oh, because you know what kind of bugs a compiler or a lib may introduce ? And valgrind works on SGI hardware too ?

Is it wrong to assume that a program which is clean (from valgrinds viewpoint) on a x86 wouldn't be clean on the Irix too?
Important for us are heavenly fast and powerful libraries as the Blitz++, especially with the integrated asserts for the debug version of our programs.
And yes, I'm a bit annoyed from Java. Personal experience, I admit.

The current Eclipse C++ plugin has refactoring facilities?
You can program in pascal, ada, ruby, python, bash, etc with Eclipse?
Eclipse ships with support for subversion, cvs, clearcase, perforce?
Code completion with support for Qt signals and slots?
...and, and, and...