[KimDaBa] Next release one week, then what?!

[Eivind]

On Sunday 08 May 2005 14:13, Jesper K. Pedersen wrote:
> On Monday 25 April 2005 07:57, Eivind wrote:

> | 1b) Better yet: Make it possibe to add new Categories, and indicate
> | that they should be auto-filled from exif-field so and so. (So I could
> | make a new Category "Cameras", and indicate that it should be
> | auto-filled from the Exif-field "Camera-Model"
> |
> | 1c) Even more flexible alternative: Make it possible to add new
> | Categories which initial value is the output of a freely choosable
> | shell-command. That way I could create "Cameras" and indicate that the
> | initial value should be the output of the command:
> |
> | jhead %image | grep "Camera model" | cut -d: -f2
> |
> | Yes, this is only really useful for power-users, but it gives
> | extraordinarily flexibility. I can have Kimdaba automatically
> | recognize *any* aspect of an image for which I am capable of writing a
> | shell-script.
>
> Two nice suggestion, but it would really not get us much further would
> it, I mean we would still not be able to search for shutter time between
> 1/300 and 1/500.

But that doesn't work today either, not even if I enter the shutter-times 
manually. I think you're confusing two different ideas here:

1) What information does Kimdaba automatically recognize from images ? Or 
what information is it *capable* of recognizing, with the rigth 
configurations. My ideas where in this category.

2) What can it *do* with information, once it has it ? For example, if 
Kimdaba *does* know that "Shutter-speed" for this image is "300", is it 
then capable of searching for "Shutter-speed" between 200 and 500 ?

I don't really see what the two has to do with eachothers. The second would 
possibly require Kimdaba to have an idea of the "type" of a tag, i.e 
"String" "Numeric" "Date" rather than just as today considering everything 
except the one Date a "String"

>| 2) Time
>| -------
>| Be more flexible in the use of time-information. Make it possible for
>| me to search for images that are taken between 18 and 24 in the
>| evening. Or make it possible to search for images taken in the
>| weekend. Yes, I realize this is more tricky than simply restricting to
>| a range as is possible now.
>
> Would that be something that is really usefull?

To me, yes. But I may be having weird usage-patterns. I find myself 
searching for that image from that party. I know that the party was some 
friday evening. Kimdaba knows the date and time of all my images, but 
still, currently it's impossible to ask Kimdaba to actually show images 
taken friday evenings.

Kimdaba knows the day and time. I know which day and time I'm interested 
in, yet I cannot communicate this to Kimdaba.

Or I know that I took a picture of a nice sunset at Cyprus. I also know 
that when I was at Cyprus, sunset was like at 1830. Still, I can't ask 
Kimdaba to show me images from Cyprus, taken between 18 and 1900.

O I'm searching for an image from some Christmas, only I don't remember 
precisely which. So I'd like Kimdaba to show me all images taken on 24th 
of december, any year. Also currently impossible.

How useful it would be to others I can't say, for me it'd be quite 
practical.

> | 4) Metadata.
> | ------------
> |
> | Make it possible to associate any file with one or more images. Many
> | digicams can record sound. Why can't I use that to record comments to
> | images, and then somehow indicate that tierpark_comments.mp3 is
> | associated with images DCP_0375 - DCP_0415 ?
>
> Sounds like a good idea, though it would require some way of invoking
> the external media file. I'll think about it.

It'll probably require the same as my 2) above: Recognising that tags have 
a "type" and allow the user, when creating new tag-categories to indicate 
what "type" they are. "file" could be one such type.

"When:" is a 'date'
"Persons:" is a 'string'
"Shutter:" is a 'number'
"Commentary:" is a 'file'

> I installed a new Suse just yesterday, and I found kimdaba in the
> installer, it was not installed by default. How would I know that
> kimdaba was this cool application to use, thats why we need a more
> descriptive name, perhaps even chaning to KImageDatabase would solve
> things, I dont know.

Yes. But how would you know, from the name alone, that Gimp, Firefox, 
Konqueror, Emacs, or for that matter KDE was a good thing to have ?

I dunno, I see the point of a obviosly-descriptive name. On the other hand 
those names tend to be dull as hell. There's *WAY* to many apple-products 
that are basically named I-descriptive. (iphoto, imusic, idinner, ibutton) 
And there are really plenty of programs in KDE named K-descriptive, one 
could even argue that Kimdaba is already like that, even though the step 
from im-da-ba to image-data-base is nonobvious.

In Mandriva (formerly Mandrake) the Packages are presented with name and 
description, so it's not really a problem:

Gimp [ ]
	The GIMP is an image manipulation program suitable for photo retouching,
	image composition and image authoring.
Mozilla-firefox [ ]
	The Mozilla Firefox project aims to build the most useful web browser
	for all platforms.
Kimdaba [ ]
	Kimdaba is the KDE Image Database. It allows you to easily sort and refind
	your pictures and images.

Somehow I don't think changing the name makes much difference in a list 
like this. (kimdaba isn't included in base Mandrake, I built that package 
myself, the point is, _if_ it was included it'd be displayed something 
like that.)


	Eivind Kjørstad