KDE Image Database 1.0 Released

Wednesday, 3 December 2003 | Jpedersen

After exactly one year of coding, several months of bothering people with demos, and 2 long holidays (also used for coding), I've finally gotten my act together enough to make a public release of KimDaBa. If you have a large pile of digital images and need a sane solution for managing them, KimDaBa could well be the answer to your prayers.

When I got my first digital camera a year ago, several image managers already existed, so I had a hard time choosing the right one. It was especially hard because I had serious doubts that any of the existing applications would scale up very well, up to say, tens of thousands of images with hundreds of new images coming in each month.

Taking my ignorance to the limit, I decided to develop the desired application myself. Suffice it to say, if you have a large pile of digital images, and cannot answer yes to all of these points, then be sure to take a look at KimDaBa:

It's easy to index your images -- "Label these 10 images as pictures of my girlfriend."
Within a few seconds you can find a given image you have in mind -- "Locate that image of my girlfriend from the holiday on Mallorca in 1998", or "Get me that photo with both my girlfriend and my father."
You have all the tools needed to set up a slide show of a given subset of your images.
When browsing through your images, it's easy to switch category -- One moment you are looking at images of your girlfriend, the next you are looking at images from your trip to Mallorca.
It's easy to make your images available on the net in different resolutions -- Make it easy for your mother on a 32Kb modem to see them in the right resolution, and for your brother on a 2Mb line to get images in a resolution high enough for printing.

Comments:

Modifying meta info on multiple files in konqueror - JohnFlux - 2003-12-03

I tend to dislike using dot.kde.org as a bug.kde.org but this seems just so relevant... In konqueror, you can right click on an image, and add meta info for description. This is really cool to use to store info about the picture. However I can't select multiple pictures, and edit the meta info for all of them at once - I can't think of a nice way to do this.

Re: Modifying meta info on multiple files in konqueror - JohnFlux - 2003-12-03

Reply to my own post... just wanted to clarify that this was in response to: >>It's easy to index your images -- "Label these 10 images as pictures of my girlfriend." Another quick point: >>Within a few seconds you can find a given image you have in mind -- "Locate that image of my girlfriend from the holiday on Mallorca in 1998", or "Get me that photo with both my girlfriend and my father." This seems again like something konqueror (or friends) should be able to do. Perhaps it already can - search for files for text in meta info? The gnome storage stuff seems perfect for this kind of thing.. P.s. I'm not knocking the app - it looks cool :)

Re: Modifying meta info on multiple files in konqueror - Aaron J. Seigo - 2003-12-03

fire up the Find File util (or go under the Tools menu in Konqueror) and on the Contents tabs there is a metainfo search option. it works rather well. for images, I select All Images from the file type drop down menu and then go crazy with the metainfo search =) this may be new in 3.2, i don't remember what it looked like in 3.1 anymore

Re: Modifying meta info on multiple files in konqueror - Andreas Pietzowski - 2003-12-03

But not for PNG-images. They don't have a meta-field...

EXIF? - Photographer - 2003-12-03

It does not support EXIF information and so it is useless for me. :( As a hobbyist photographer, *what I need to switch my photo db on Linux* is something like this: >>> "( http://www.iview-multimedia.com/products/mediapro/index.html ) iView MediaPro</A> is essential for creative and media professionals who need to organize, view, annotate, print, backup and repurpose media, as well as automate workflows. With iView MediaPro, you can make the most of your media to create flexible slide show presentations, QuickTime movies, theme-based web pages, print multi-image reports, and custom PDF layouts. You can also enhance the color, brightness and other visual characteristics of photographs. Version 2.0 comes with its new cross-platform Catalog Reader for free distribution. Share iView catalogs and slide shows with clients, colleagues, friends and families who do not own an iView program. Organizing your media into catalogs allows you to instantly search, annotate and classify media with unlimited criteria across large volumes of mounted or unmounted media files using the drag-and-drop organizer. MediaPro supports IPTC, EXIF and QuickTime annotation standards, user defined annotations and128 file formats, including popular image, audio/video, and digital camera raw formats. It also converts media into a variety of formats and supports AppleScript. Creates media catalogs containing thumbnails and annotations that can be viewed even when the original files are no longer on a mounted drive. iView MediaPro allows you to import photos direct from a digital camera and burn media onto a CD-ROM or backup media to a removable volume." <<< And of course, I need 16bit per channel support on Gimp. And then I can switch on Unix/Linux with all my gear. But such support ain't there yet for pros or for serious hobbyists.

Re: EXIF? - anonymous - 2003-12-03

That's a good point. There is an "exif" command line utility for Linux/Unix so it should be *very* easy for Jesper to add this to KimDaBa in the next release. Stay tuned!

Re: EXIF? - Jesper Pedersen - 2003-12-03

And indeed the next version will have EXIF support. I had a hard time discarding it for version 1.0, but I had been working on it for almost a year, without a single release, so I had to cut somewhere. I've already started working on what will be version 1.1 (no 1-year development period again). 1.1 will likely be out just after next holiday - which will be XMas ;-)

Re: EXIF? - Eric Laffoon - 2003-12-03

> As a hobbyist photographer, *what I need to switch my photo db on Linux* is something like this: Wow! That's a lot of "hobbyist" features. What do you bet they had more than one guy working on it for a year? ;-) Let poor Jesper have a little glory before pointing out all that is not in his initial release. ;-) Actually I looked at a previous version of KimDaBa and it is very cool, though it's obvious it doesn't have some features that could be useful at this time. It is a very slick application that will be useful to me. > And of course, I need 16bit per channel support on Gimp. And then I can switch on Unix/Linux with all my gear. But such support ain't there yet for pros or for serious hobbyists. Why don't you have a look at Cinipaint? It's good enough for films like "2 Fast 2 Furious", "Scooby-Doo", "Harry Potter", "Stuart Little" and more. It's also GPL'd and of Gimp heritage. While you're at it if you don't mind shelling out the bucks and want to produce movies there's other cool software like Maya, but it's about the same price as a new car to set up that Linux gear. ;-) Clearly adding a lot of other features like you mentioned would take some work but there are image gallery creation programs like Kallery by Andras Mantia and other programs that do tasks similar to things you mentioned. To actually make them useful in an integrated set up would take some work and use of DCOP, perhaps kparts and could even be made to interact with programs like Kommander or KJSEmbed. So while it may not be an easy rival to the software you mentioned it's closer than you may think. One important factor is it doesn't have to all live in one application if the various programs can interact well.

Re: EXIF? - Photographer - 2003-12-03

>Why don't you have a look at Cineipaint? Cinepaint does have 16bit support but is not as good as the new Gimp 1.3.x for photo retouching and editing. But the Gimp again, doesn't have 16bit. It is a bad cycle.

Re: EXIF?--Cinepaint was FILM GIMP - Marc J. Driftmeyer - 2003-12-03

Film Gimp has 16 bit support. "..The extended dynamic range of CinePaint appeals not just to 35mm cinematographers, but to 35mm still photographers as well. Still photographers can think of CinePaint as having many more F-stops of range, of being capable of capturing much more subtle nuances of color in a vast blue sky for instance. CinePaint handles 8-bit, 16-bit linear, and 16-bit float images." http://cinepaint.sourceforge.net/docs/features.html I must be missing by what support it doesn't have that you need.

Re: EXIF?--Cinepaint was FILM GIMP - Photographer - 2003-12-03

You did not read my reply before you reply! I said that CinePaint DOES have 16bit support, but is not suitable for photo work as much as Gimp 1.3x is. They have removed a number of Gimp features in order to make it more suitable for movies instead. Gimp 1.3x is way better for photography work, but it does not have 16bit support.

Re: EXIF?--Cinepaint was FILM GIMP - LaNcom - 2003-12-03

1. If you really care for your pictures you would never, ever, use jpeg, so exif should be an non-issue... 2. If you don't care to spend money on a Linux retouche app with 16bit support, check Amazon Sweet16 ( http://www.ifx.com - _very_ expensive), or Photogenics HDR ( http://www.idruna.com - not as expensive as Photoshop).

Re: EXIF?--Cinepaint was FILM GIMP - anon - 2003-12-05

Do you know how to get Nikon Coolpix 2100/2500/3100 to take pictures without saving them in JPG format?

Re: EXIF?--Cinepaint was FILM GIMP - Tim Middleton - 2004-10-04

EXIF can be used with TIFF images as well as JPEG. (But anyhow I disagree with the assertion that if one cares "never, ever" use JPEG. One may care, but there sometimes have to be trade-offs between file size and quality).

Coolness - Ian Reinhart Geiser - 2003-12-03

I've always wondered what this bugger did. Hope to see more apps here :) Cheers -ian reinhart geiser

Re: Coolness - Jesper Pedersen - 2003-12-03

Ian! How did you manage to talk to me for more than an hour in total at the Kastle without getting a demo ;-)

Fixed Properties - Anonymous - 2003-12-03

> KimDaba offers to describe images with a number of properties. These includes date, persons on image, location of image, plus a keyword field This sounds only useful for people taking photographs of persons at locations with no need for more than one own property. Why not make this full configurable or possible to add/search for unlimited property|content pairs?

Re: Fixed Properties - Jesper Pedersen - 2003-12-03

Hey mate, did you expect me to include a complete feature description in this short announcement? Of course you can configure the categories to your hearts content. So you may include categories for pet, things, buildings, sex toys, you name it ;-) Cheers Jesper.

This sounds great - Mario - 2003-12-03

After Mosfet's PixiePlus ended up dying with him, I thought I would never have a good image manager again, this sounds like it will fill its role for me =)

Re: This sounds great - Khtml bug #1 - 2003-12-03

Mosfet died?

Mosfet? - wilbert - 2003-12-03

Really, where is Mosfet?? btw this app looks nice. Maybe some functionality could also be in Konqueror, and maybe even using the underlying filesystem's extended attributes (like reiser 4). Then you could burn your collections on CD and browse and search them just as easy.

Re: Mosfet? - Scott Wheeler - 2003-12-03

Mosfet comes and goes, for this is his way. He'll be back at some point. There are a lot of "disappearing hackers" in Open Source. KDE has a number of guys that show up for a while and then mysteriously disappear again to later resurface. I think Mosfet is just a bit louder about it. :-)

KimDaBa - cypherz - 2003-12-03

>>It's easy to index your images -- "Label these 10 images..." etc This is exactly what I've been looking for! Kewl! thanks x 10e6!

F-Spot comparison? - Photographer - 2003-12-03

How is this app compares to GTK#'s upcoming F-SPOT, feature-wise? More info here: http://perazzoli.org/blog.php

Its been dotkded - Ian Monroe - 2003-12-03

Downloading at about 2 kilobyte/sec, just like in the bad old days. I'm off to bed now, I'll mirror it on my university space when I get up. From the screen shots, it looks interesting. Currently I have all my photos in chronological order in folders based on when I downloaded them. I imagine thats just going to get more unwieldy the longer I own the digital camera though.

Re: Its been dotkded - Jesper Pedersen - 2003-12-03

Indeed it has ;-) I've never seen my 512K line so hot! All please be patient, I'm moving as we speak, so things so be much better in less than an hour ;-)

Re: Its been dotkded - Ian Monroe - 2003-12-03

http://www2.truman.edu/~iam504/kimdaba-1.0.tar.bz2

Re: Its been dotkded - Jesper Pedersen - 2003-12-03

Its at ktown now, os there should be more enought bandwidth now ;-) Thanks though.

Looks very cool ! - quarus - 2003-12-03

Can't wait to try it !

GREAT! - Dani - 2003-12-03

Just about 4 weeks ago I discussed with a friend about such an app and our needs. I'll give it a try asap, because there are about 14'000 Digitalfotos on my disk, and I can order it how I want - it's a chaos...

Re: GREAT! - Jesper Pedersen - 2003-12-03

Dani. Personally I have approax 3.500 images managed by KimDaBa, and I do indeed expect that it scales to a much larger number, afterall that is the whole idea with KimDaBa. So please get in contact with me once you have started using KimDaBa, so we can profile any bottlenecks that might be left.

Re: GREAT! - Dani - 2003-12-03

I think a db(mysql) backend could be good. This should be relative easy with kioslaves, not? I'm not a KDE Developer... (only java+php) And if the data's in a db, it would be possible to build a webfrontent via php. I'll get in contact with you when KimDaBa is up and running.. Oh, and yes, exif extraction would be very cool. "search all images width flash enabled" ;-) "search all images with exposure time greater than 1 sec" are wishlist and buglist on the web accessible?

Re: GREAT! - Jesper Pedersen - 2003-12-03

I did consider putting it into a db from the beginning, but decided to see how a plain file would do, so far the loading time of the 3500 images is not significant. If it should turn out to get to slow I'll consider write db support. As long as its fast enough a plain XML file is much easier to maintain than a db. You may still write php code that access the XML file. wishlist, buglist: see bugs.kde.org.

Re: GREAT! - sqlite - 2003-12-03

For projects where it's just a little bit too big for a file, and too small for a database, it might be worth having a look at sqlite. btw, it's not entirely clear. Do you use the meta information in the actual images at all? (I often store the descriptions of my photos in there)

Re: GREAT! - Jesper Pedersen - 2003-12-03

Are you referring to the EXIF info? No I dont use that currently, but next version will include support for it.

Re: GREAT! - sqlite - 2003-12-03

/me checks in konqueror.. Ah yeah it is exif - that makes other comments make more sense now.. thanks. Btw when I right click on a png, it doesn't offer me a chance to add a comment or anything about the image. But I thought png allowed arbitrary key-value pairs? Is this just a case of the gui not supporting it yet, or that it isn't EXIF, or something?

PNG - Ian Monroe - 2003-12-04

PNG doesn't have EXIF (its a standard limited to JPEG I think). Konqueror shows comments on the PNG on the Meta-Info tab but doesn't have a way to add any.

Seems very good so... - LC - 2003-12-03

What about adding this app to the future KDE 3.3 ? There is no app like this in the official release and it would be a good improvement.

Re: Seems very good so... - Jesper Pedersen - 2003-12-03

Getting applications into the KDE release doesn't seem to be that easy, and I'm for sure no politician (Dont use this agains me if I ever choose to go into politics ;-) I did ask some people at Kastle if there was interest in getting KimDaBa in there, but people wasn't exactly exited, so lets see. Feel free to add presure whereever you find it appropriate if you want it in there. I'd be happy to support whatever actions technically needed to get it in there.

Re: Seems very good so... - Morty - 2003-12-03

Personaly I don't see any compelling reasons why KimDaBa should go into the main release of KDE. But it's a perfect app to put under the extragear umbrella. And with some planning there are no problems to time your releases to the main KDE ones. And then you don't have to play with politics, just bribe the release dude to add a couple of lines and a link in the release anoncement.

Re: Seems very good so... - anonymous - 2003-12-03

Of course, you already know that it *is* under the extragear umbrella, right?! ;-) (See http://extragear.kde.org/apps/kimdaba.php)

imgSeek - Tobias - 2003-12-03

If you add some imgSeek.sf.net search features, I will be happy. ;-)

Re: imgSeek - Jesper Pedersen - 2003-12-03

I'm wondering if you are capable of drawing your girlfriend so well that it finds her rather than your mother ;-) Nice idea, and I've put it on my wish list, but not exactly at the top. Thanks Jesper.

Re: imgSeek - J. And - 2003-12-04

HejJesper It would certainly be a good idea to be able to group lots og images automagically like imgSeek does. Please give it a try - the algorithm used is described somewhere at imgseek.sf.net and if i remenber correctly not to difficult to implement - the result is a hash value.

Brings order into chaos - Robert - 2003-12-03

Wow! This thingy is cool! I'm currently hooked on Windoze but am planning to convert to Linux on XMas. One of the several pieces of data that i will have to "convert" is a moderately large collection of digicam images, which i previously looked at with a horribly stupid digicam browsing tool plus a simple folder structure. KimDaBa gives me categories and free associations to introduce some order into the chaos ;-)) I will *definitely* use it around christmas, expect feedback from me then

Gallery Remote Protocol support?? - Sander - 2003-12-03

Will KimDaBa support the remote protocol of Gallery in a next version? ( http://tinyurl.com/xjli )

Re: Gallery Remote Protocol support?? - Jesper Pedersen - 2003-12-03

The next release (for January) is already stuffed with other features I want in, so no - not unless someone else joins the project and implements it (hint hint) I've bookmarked your page, so maybe someday. If the database you refer to is capable of storing all the data KimDaBa has, then it sounds like a good idea to me.

KDE already has Kmrml - John the anonymous - 2003-12-03

There is an application included in KDE since a long time (however I never had luck to get it work) called Kmrml. Is a client for GIFT, a image indexing server with manages to clasificate images similar to an example proposed by the user; it uses an xml based protocol so it can be used in a distributed way over internet. I think it would be interesting to make both applications work together (a possible backend for KimDaBa??). However I have no the time to work on this :-(

digikam and KimDaBa - Thorsten Schnebeck - 2003-12-03

I have tested both programs and digikam 0.6.0pre is sooo sweet especially with its plugin mechanism. But KimDaBa has the far better features to organize my pictures. <dream> KimDaBa as a digikam-plugin! </dream> Working with a good digicam (EOS300d) and Linux is quite ok. When somebody wants to work on a kde imaging program _please_ use 16bit RGB and colormanagement. You need this today! Scanner and RAW formats use more than 8 bit per channel. There is only CinePaint today for Linux so there is a deep need for a good (=KDE) image manipulation program. And don't underestimate the size of a picture. Kuickshow can't show http://www.tawbaware.com/maxlyons/gigapixel_strip.jpg (40786x100 pixel) (gimp works) Oh, and a kde-tool (like PTassembler or better than Hugin) for the panotools would also a nice addon ;-) Bye Thorsten

Re: digikam and KimDaBa - Aurélien Gâteau - 2003-12-05

Warning: this post contains shameless self-promotion :-> > Kuickshow can't show > http://www.tawbaware.com/maxlyons/gigapixel_strip.jpg > (40786x100 pixel) Gwenview can view it. Have a look at it: http://gwenview.sf.net

Looks fascinating! - Adam Foster - 2003-12-03

Downloading it right now. I've got (quick check) 1987 photos from my camera in a single directory, and Konqueror's thumbnails were getting a bit unwieldy. This looks like a perfect tool for sorting stuff properly, without lots of complicated directories clouding the issue. Looks like it's time to get compiling...

Anyone else seeing compilation errors? - cm - 2003-12-04

Does anyone else see linker errors for the CVS version in kdeextragear-2? kimdaba hasn't been building here for quite some time, but I didn't bother because I thought "It's still in development and will eventually be fixed...". Now that it's released but with the error still there I think I might have some problems that are specific to my installation. There are several errors like this. imageconfigui.moc.o(.gnu.linkonce.d._ZTV13ImageConfigUI+0x20): undefined reference to `ImageConfigUI::~ImageConfigUI [in-charge]()' So, does the CVS version build for all of you who have tried?

Re: Anyone else seeing compilation errors? - jsa - 2003-12-06

Yes I got several build errors from the csv version. (Why would a programmer put code into csv for the world to view that did not even compile?) So I backed off the the released version. Only to fine that it requires unsermake, which to the best of my knowledge no distro has yet included. So I started searching for that, and realized it was a fools errand to start whacking my system to compile this thing. I'd like to use this software, but two hours of downloading and building give me the impression its not ready for beta testing yet.

Re: Anyone else seeing compilation errors? - Jesper Pedersen - 2003-12-07

The CVS version compiles just fine for me, but if you do not use KDE Head you might be in trouble with it. (I'll backport it to 3.1.x when releasing) Regarding unsermake, it was indeed not my intend that the release should contain that code, but as I use unsermake myself, obviously that got into the release. This does however not mean that you need unsermake! so if unsermake is required for you, it is either a bug in unsermake or a time stamps problems on your system. Regarding the software not being ready for beta testing: Please be reasonable now, any release will have problem on some system, and obviously you were the unlucking one. But starting shouting out that it is not even ready for beta testing, is at best not fair.

Re: Anyone else seeing compilation errors? - cm - 2003-12-08

> The CVS version compiles just fine for me, but if you do not use KDE Head > you might be in trouble with it. (I'll backport it to 3.1.x when releasing) Well, I do have CVS HEAD, both of KDE and kimdaba. And the rest of the KDE source compiles, so I don't think my system is broken. Should I report a bug somewhere with the complete error output? If so, where? I haven't found it as category at bugs.kde.org...

Re: Anyone else seeing compilation errors? - Jesper Pedersen - 2003-12-08

Yes, please do send me the error message blackie@kde.org KimDaBa does actually exists in bugs.kde.org.

Re: Anyone else seeing compilation errors? - cm - 2003-12-08

For the record: I sent the email and Jesper Pedersen suggested to remove the complete directory and do a new checkout to cleanup stale files. That did the trick. (The standard "make clean" I do regularly hadn't helped.) Thanks to him for the quick and competent help.

Re: Anyone else seeing compilation errors? - jsa - 2003-12-08

Well you are probably right when you say that I was being a bit unfair. It was late, I was frustrated, and I appologixe. Lets just say its obviously not yet time for ME to be beta testing since it won't build on my machine. Not the CSV or the released version. I note that others are having problems with the usermake issue (on the mailing list). To them you suggested (as you did to me) that there is a time stamp problem, and on the mailing list you said they should check their system clock. My clock is set with ntp to one of the US Government clocks so I'm pretty sure thats not the problem. Why would a time stamp cause the make process to try to invoke usermake when usermake is not even installed on my system. (Indeed, SuSE has never included it). My system is SuSE 8.2, running a late smp kernel, and kde 3.1.4 and reciently updated source tree for same. I also note that after running ./configure and waiting for that to get done, (successfully) I start make, and it goes thru configure again. That may have been your intent, but I've never seen it with other packages I've built from source.

Re: Anyone else seeing compilation errors? - Jesper Pedersen - 2003-12-08

As I said, it was not intended to release with unsermake enabled. I'm currently at a company meeting where we work 18 hours a day, so please allow me till Wednesday, where I'll release a 1.0.1 without unsermake, and with bugfixes for two crashes reported. Cheers Jesper

Lossless jpeg rotation? - Anony Guy - 2003-12-04

Looks pretty cool. One feature that I must have in such a program is the ability to quickly select and (losslessly) rotate pictures. Reading through the documentation I saw a picture that suggests you can rotate for viewing, but it wasn't clear if this rotated the actual picture. Looks like a cool App! I'll download and play with it tonight. John

Re: Lossless jpeg rotation? - Jesper Pedersen - 2003-12-05

No modifications are done to the images at all. You can store in the database that the image should be rotated, but it will never be written to the actual image. Thats a feature not a bug ;-)

Re: Lossless jpeg rotation? - Anony Guy - 2003-12-05

Yeah, I understand where you are coming from...not quite the intended use of your tool. Does anyone know of a good KDE tool for doing this sort of thing? Right now the best thing I've found is some clunky X program (maybe GTK based? maybe not) that mandrake includes.

Re: Lossless jpeg rotation? - Lubos Lunak - 2003-12-05

Maybe the Gwenview image viewer can be what you're looking for.

Re: Lossless jpeg rotation? - Thorsten Schnebeck - 2003-12-05

digikam 0.6.0-CVS has a lossless-JPEG-plugin http://digikam.sourceforge.net/plugins.html#p8 Bye Thorsten