[KimDaBa] Next release one week, then what?!
will at willholland.co.uk
Thu Apr 28 20:41:56 BST 2005
Firstly, I should say, keep the name the same. It's simple, effective, and
people know it.
On Monday 25 April 2005 06:57, Eivind wrote:
> On Saturday 23 April 2005 17:44, Jesper K. Pedersen wrote:
> > A N D T H E N W H A T ???
> 1) Exif.
Definitely need at least the ability to view the exif data! I really like
option 'c' (extract stuff automagically from exif to categories)
> 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.
Maybe I've missed something, but I would also like to be able to click and
drag on the timeline to select images... or double click.
> 3) Database
Yes and no. Separate the backend, but keep it as one app, so a new user (I
was put off many apps by db backends) can just compile and go. That is a
real strength. I looked through about 15-20 different apps over a year or so
before finding kimdaba. I wrote my own (but ran out of spare time), but am
happy now. Thinking about it I would move to a db now (15K images), but I
wouldn't have to start with.
> 4) Metadata.
As I see it that should go with the item below.
> 5) Multiple formats.
> Make it possible to indicate that multiple image-files represent the "same"
> image. I might have XXX.raw, XXX.jpg and XXX_scaled_down.jpg They're all
> the same image though, which means they're taken with the same camera, in
> the same location, containing the same persons etc. It also probably means
> I only need to be shown one of them when I search. (possible with some
> indication overlayed that multiple versions exist)
There was a thread about this type of thing a while ago, and in general it was
going to cause a re-structure of the db.
I still think that it would be worth it.
I think that it would be worth having some sort of plugin facility that would
allow thumbnails to be produces from any format. (jpg/raw/mov/etc) It could
be left upto us to write the plugin if we want it (and share it with the rest
of the world). Obviously? Jesper should maintain the Jpg one, so that
someone picking up kimdaba for the first time should be able to generate
thumbnails from the images. There should also be some sort of config to
allow opening that file in an external app. This could get messy, but as
long as the core is kept within kimdaba this allows 'extensions' for free.
An extension to this would be a conversion from any format to any other format
(ie reduced size/raw->jpg/etc).
The final part to this would be to give the user rules to associate files
together (There is no way that I want to manually associate my thumbnails
with the original images). The obvious version to this is X.jpg associates
with X.raw and X_thumbnail.jpg or
/photos/originals/X.raw associates with /photos/viewing/X.jpg
Next, on a different topic,
when I show pictures fullscreen, it takes an age to load them (unless
pre-loaded), and if there are several that I want to skip past I have to wait
for the full images to load. Is it possible to thread (I can't rember the
word, but basically show a 1/8 res image that gradually gets finer) these
images, and allow more user responce.
And a bug I've noticed... probably my shaky hand/kde/something I've not
noticed, but when hitting page up/down, it sometimes doubleclicks and I miss
an image... I'll try and track it down some more.
Finally I should say,
Please Please Please can we have the feature that:
when I select multiple images for edit, I get Bold/grey/white backgrounds to
indicate if all/some/none are selected. (and the 3 stage cycle when I click
Also can the highlighted options be at the top of the list (unless it's done
Cheers for a great App!
Oh and also, I just rembered, if I only select one image, can the viewer think
I've selected them all :)
More information about the Kphotoalbum