FEB
12
2004

Digikam 0.6 Released

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)
  • XML is used for saving the comments
  • Four different thumbnail sizes
  • EXIF information viewer
  • Lossless JPEG rotation support
  • Fast photo viewer/editor with keyboard shortcuts and basic image editing features like rotation, cropping, gamma/brightness/contrast correction (all without losing EXIF information)

Comments

export to HTML gallery feature? easy way of renaming all the pics (eg: picture1.jpg, picture2.jpg) or keeping the original camera filenames if wanted?

hot stuff!


By ac at Thu, 2004/02/12 - 6:00am

Maybe the renaming could be done trough KRename integration, like it is done in showimg. Would be really cool.


By dom at Fri, 2004/02/13 - 6:00am

Nothing much works here at all as far as digital cameras are concerned.


By More-OSX_KDE_In... at Thu, 2004/02/12 - 6:00am

I access my Canon S300 using Digikam 0.6, with Gphoto2 and the 2.6.2 kernel without any problems.


By Deleon at Thu, 2004/02/12 - 6:00am

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.


By Helge Øyvind Hoel at Thu, 2004/02/12 - 6:00am

Works perfectly with my Fuji 602
you must be doing somrthing wrong!!


By vernr at Sat, 2004/02/14 - 6:00am

Hi,

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

cu


By Andreas Zickner at Fri, 2004/02/27 - 6:00am

not for me.
It worked fine with 2.4.x and know (same syntax) it doesn't
I've got this :
gp_port_read: Connection timed out
IO error


By max_cqft at Mon, 2004/03/22 - 6:00am

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.


By anon at Thu, 2004/02/12 - 6:00am

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

Thankfully, it's called camera now. A little easier for new users to discover, and a little more professional name :).


By Matthew Kay at Thu, 2004/02/12 - 6:00am

There were nice digital photo management tools for a long time now. Check out gThumb, for example of one.


By anon2 at Fri, 2004/02/13 - 6:00am

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


By Kurt Pfeifle at Thu, 2004/02/12 - 6:00am

> Is it that the maintainer can't go with KDE release dates?

kde-extra-gear is cool for stuff like that.


By anon at Thu, 2004/02/12 - 6:00am

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


By Nick Shafff at Thu, 2004/02/12 - 6:00am

The admins don't do anything against the will of the apps' developers.


By Anonymous at Thu, 2004/02/12 - 6:00am

Ie, if I go the analog route and digitalize my pictures with a scanner, can I use digiKam for archiving them on my computer?


By he-sk at Thu, 2004/02/12 - 6:00am

yes,

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

pahli_bar


By pahli_bar at Thu, 2004/02/12 - 6:00am

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.


By Ralf at Thu, 2004/02/12 - 6:00am

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.

Apart from that, Kudos to the team for a great app!


By Dirk at Thu, 2004/02/12 - 6:00am

this feature is planned as a plugin. expect it to be present in 0.7 release
pahli_bar


By pahli_bar at Thu, 2004/02/12 - 6:00am

Please conform to expected standards and see to it that BSD will have a red-eye enhancer. Likewise, the removal should not be available on said machine. :)


By a.c. at Sun, 2004/02/15 - 6:00am

My killer plugin would be (purple) chromatic fringing removal. I've got the steps to remove it in gimp down pat, but having it automated would be nice.


By Corrin at Fri, 2004/02/13 - 6:00am

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!

Ciao,

Wim


By Wim Coulier at Sat, 2004/07/24 - 5:00am

Red Eye removal is now in the CVS version of digikam, along with a ton of other great features.


By Ralf at Sat, 2004/07/24 - 5:00am

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.


By Eric Laffoon at Thu, 2004/02/12 - 6:00am

> 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


By pahli_bar at Thu, 2004/02/12 - 6:00am

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


By Eric Laffoon at Sat, 2004/02/14 - 6:00am

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


By djay at Fri, 2004/02/13 - 6:00am

Yeah, the button order was one of the reasons I switched from GNOME pre-2.0 to KDE pre-3.0 (I was a diehard GNOME 1.0/1.2/1.4 user). I stayed with KDE for it's own merits.


By fault at Fri, 2004/02/13 - 6:00am

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.


By Paulo Eduardo Neves at Thu, 2004/02/12 - 6:00am

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


By pahli_bar at Thu, 2004/02/12 - 6:00am

Thank you for this great app. Would it be possible to create a plugin for balance correction, like this this one for the gimp?

http://www.geocities.com/lasm.rm/wb2.html


By AC at Thu, 2004/02/12 - 6:00am

added to my TODO list :)
pahli_bar


By pahli_bar at Fri, 2004/02/13 - 6:00am


By Ruediger Knoerig at Thu, 2004/02/12 - 6:00am

KDevelop has refactoring facilities ? :-)

(get real : kdevelop is a good IDE, but from the previous generation - compared to Eclipse or Intellij Idea, it's obsolete).


By Guillaume Laurent at Fri, 2004/02/13 - 6:00am

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.


By Ruediger Knoerig at Fri, 2004/02/13 - 6:00am

You're seeing this from the hobbyist point of view. In the office, you just give 1Gig of RAM to your Java devs and off they go. The time gain recoups the investment after a week.


By Guillaume Laurent at Fri, 2004/02/13 - 6:00am

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


By Ruediger Knoerig at Sat, 2004/02/14 - 6:00am

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


By Guillaume Laurent at Sat, 2004/02/14 - 6:00am

We're developing under XP for XP,Linux,Irix :-)
Java's bad performance and memory consumption isn't bound to a plattform or a VM, its bound to the very basic principles of Java itself :-)


By Ruediger Knoerig at Sat, 2004/02/14 - 6:00am

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


By Guillaume Laurent at Sat, 2004/02/14 - 6:00am

Again: we're developing under XP!!!
(At home I've running and developing for Linux pure!)


By Ruediger Knoerig at Sat, 2004/02/14 - 6:00am

I understood you the 1st time.

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.


By Guillaume Laurent at Sat, 2004/02/14 - 6:00am

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.


By Ruediger Knoerig at Sat, 2004/02/14 - 6:00am

> 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 ?


By Guillaume Laurent at Sat, 2004/02/14 - 6:00am

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.


By Ruediger Knoerig at Sat, 2004/02/14 - 6:00am

> 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?

Completely wrong. First of all it means that you're assuming valgrind catches everything - it doesn't. Second, you're forgetting CPU specificities. Third, the OSes and libs are different too.

> Important for us are heavenly fast and powerful libraries as the Blitz++

Then you indeed couldn't have picked a worse choice than Java for your app. At best you could have tried a Java GUI over a C++ core, but with Qt that would not really have been worth the hassle.


By Guillaume Laurent at Sat, 2004/02/14 - 6:00am

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

--> http://www.kdevelop.org/index.html?filename=features.html

(get real: you should do some research before you call something obsolete)


By Christian Loose at Fri, 2004/02/13 - 6:00am

yes.. but kdevelop still doesn't have refactoring :(


By fault at Fri, 2004/02/13 - 6:00am

Why didn't you write one? :(


By Christian Loose at Fri, 2004/02/13 - 6:00am

Pages