You are not logged in.
Hello,
after all the aKonadi related mess I've finally left KDE - now I'm a very happy Awesome user, wondering why I had not discovered it earlier.
So far I've replaced most of my 'unreplaceable' stuff, like kmail, kile and k3b. The last and only thing that forces me to use kdelibs with all the dependencies is Digikam.
I use it, hovewer, in a very narrow way - only to tag images and (later) search them. As I work only with RAWs, my workhorse is RawTherapee, which - unortunately - has no database features.
So I'm looking for an application which could replace Digikam in its tagging-and-searching role. It doesn't need to have any photo importing/editing/exporting features, but it should be able to manage the tags database well, as my way of organizing photos is tag-centered.
Does such application exist? I've done some searching, but so far the only one that seems to fit my needs is... Digikam
I'm stuck with this problem, so all hints will be very appreciated
greetings,
Paweł
Offline
Mapivi (http://mapivi.sourceforge.net/mapivi.shtml)
F-Spot (http://f-spot.org/)
Shotwell (http://yorba.org/shotwell/)
Offline
Shotwell has almost non-existent advanced tag searching support and F-Spot has similar weakness to DigiKam - it's big and has dependencies that I want to avoid.
Mapivi looks promising, I'd give it a try, but it seems that its development had stopped some time ago
Thanks for those, anyway, but I'd still be thankful for any more hints.
Update:
Ive just tried mapivi and it's usability is very very far from optimal. It also has some probems with tiling WM and multihead support... So certainly not an app for efficient work with thousands of photos.
From those three Shotwell seems to be mature and fast enough, but I can't even search more than one tag simultaneously, not mentioning making a good tag hierarchy and so on...
Last edited by gorky (2010-08-29 15:05:39)
Offline
When it comes to tagging, nothing beats KPhotoAlbum IMHO. Of course KDElibs dependent. What is wrong with that?
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
Nothing serious - besides the fact that it is somehow irritating to have such a big library (and its dependencies) installed just to tag photo files.
IMVHO Digikam has really perfect tag support, but I just don't need all the bundled features - pure tagging and tag searching application is all I'm looking for.
It's the same reason why I use zathura and jumanji instead of acroread and firefox
Last edited by gorky (2010-08-29 17:27:11)
Offline
I wrote for myself a python script for tagging. It uses pygtk and pyexiv2 to tag with IPTC keywords. It just shows a text box where you put tags, comma-separated. Can also operate on multiple files. Works pretty well for me. Calling it from gwenview/gqview/geeqie.
Unfortunately, I haven't written the companion script that searches. So right now I have 3GB of tagged pics that I can't search. I can still view the tags with digikam/gwenview/geeqie.
So this script does tagging, if you want it. But not searching (yet).
There are two types of people in this world - those who can count to 10 by using their fingers, and those who can count to 1023.
Offline
Yeah, searching is the big thing here. Telling the truth, I doubt it can be done effectively only with EXIF/IPTC, without the use of a real database. Obvoiusly the main problem is speed, which is unacceptable when dealing with thousands of photos.
Geeqie is my main image browser - it's the fastest one with colour management. Unfortunately it also has very poor tag searching support - no external database (problem stated above)...
I found a project called BlueMarine, which seemed to be VERY promising, but unfortunately it's dead now. There's also an application named Chhobi, but it's probably also abandoned.
In fact I'm shocked that there is no alternative to Digikam, especially after I found plenty of Windows applications that would fit my needs if only I used that OS.
I also found a similar (albeit Windows-oriented) thread on pentaxforums: http://www.pentaxforums.com/forums/digi … 010-a.html
Last edited by gorky (2010-09-04 13:45:54)
Offline
The problem is just, we live in 2010
nobody will write something like digikam completely from scratch without a library. It would take a lot of time and it woulnd´t have any advantage to other applications...
even my EeePC with 4GB of Harddisk runs digiKam, you can´t seriously tell me that KDElibs is a too big dependency.
When you decidie to use a lightweight environment you also have to accept that you dont have much features.
Just take the question. When F-Spot, digiKam, KPhotoAlbum and so on exist, why should someone waste developing time to write a new one instead to increase the useability of the existing one? Just that people get a wood with getting there environments as light as possible? Is it that erotic to have TB of unused Harddisk space?
btw. the applications you found for windows are all using (i bet) the Win API or even .NET
.NET is larger than a full operating system so you cant blame and the Win API is a full operating system
You cant say "On windows i have no problems with 5GB of dependencys (already installed on my system) but on Linux 300mb is just too much"
And the most applications you´ll find will either be written in GTK+ or Qt/KDElibs so either you install GTK+ as dependency or Qt/KDElibs but you cant live without them.
Last edited by Vamp898 (2010-09-05 07:24:27)
Offline
Well, I won't say you're totally wrong, because I can agree with your argumentation in some points.
From my point of view, however, you made wrong assumptions.
When F-Spot, digiKam, KPhotoAlbum and so on exist, why should someone waste developing time to write a new one instead to increase the usability of the existing one?
1) F-Spot and Digikam are big applications, with image importing, editing and exporting features. I don't need this functionality. Tagging and searching is everything I am looking for.
A GTK+ version of KPhotoAlbum - that's my target, I think. And I'm very surprised that it doesn't yet exist.
If I used all features of Digikam, I'd probably won cry about it's dependencies.
2) People do really write new applications similar to those which exist. Look how many window managers, image viewers, web browsers - and even programming languages! - we have now. If you had been right, we would still be using Mosaic 19 or Netscape Navigator 11 to browse the web.
And the web browsers are good example I think. We already had Firefox and Opera, but then Chromium arised, and many people found it to be better. And I personally use jumanji.
It's all about having the choice.
When you decide to use a lightweight environment you also have to accept that you dont have much features.
3) In fact I use this light environment (Awesome) because it better fits to my needs. It is extremely fast, it has proper multihead implementation, it supports tiling perfectly, it is easy scriptable with lua... Neither KDE nor Gnome can compete in these categories.
I'm not a kind of person who likes to complicate his life, but after transition from KDE i clearly see that I have more important features here, and my environment is closer to perfect now.
And in my search of purity, simplicity, but also usability I currently have only one, last obstacle - the photo tagging application
Last edited by gorky (2010-09-05 11:52:45)
Offline
Point second is just nonsense
The most new "Webbrowsers" in fact are just new GUIs to already existing Engines.
You can write a completele new Webbrowser in Qt with about 5 lines of code
Midori, Jumanji, Epiphany; all those are written in these way. They create a cheap and small GTK+ GUI and they dont write any single line of code what a web-browser is about. They just use GTKs libwebkit and with 10-20 lines of code BABAM a new browser is born
also image viewers are very very easy to write... just take a look at the code of ristretto
A GTK+ version of KPhotoAlbum
GTK+ isn´t that notable smaller than Qt so i think we´re talking again about principles
People think GTK+ is smaller cause the stuff written in GTK+ is smaller but in fact its just illusion.
Last edited by Vamp898 (2010-09-05 12:22:50)
Offline
Point second is just nonsense
The most new "Webbrowsers" in fact are just new GUIs to already existing Engines.
Can you see any difference between something as light as webkit, the dedicated html rendering engine, and the whole set of desktop libraries?
BTW, all of the big ones (Explorer, Firefox, Opera, Chromium) use different engines.
A GTK+ version of KPhotoAlbum
GTK+ isn´t that notable smaller than Qt so i think we´re talking again about principles
It was just a mental leap - I meant something not KDE-dependent.
Last edited by gorky (2010-09-05 12:24:45)
Offline
Chromium uses Safaris Engine and Safari uses a changed Version of KHTML which is Webkit
And the beginning of Opera, Firefox and Internet Explorer are long long ago... back in the times were not that much libs existed. They didn´t had a choose and was forced to write from scratch. Thats why it tooked so many years that we have the status we have now.
The KDElibs are 66mb..... really thats nothing!
The main problem here is that Arch is simple AND lightweight
a lot of people think that simple == lightweight but thats not the fact
Gentoo for example is the opposite of simple, but the existing system is (in the most cases) smaller and with less unused stuff than an Archlinux system.
If you choose a simple distribution with a simple package manager like pacman you have to take the disadvantages that pacman brings. That are for example that you can´t choose with which options your applications is compiled.
If you compile KPhotoAlbum yourself you can go with about 60-100mb of dependencys but on Archlinux the packages are compiled in one way! And thats the way that most people want and the most people want a full KDE Integration. So KPhotoAlbum installs a lot of KDE stuff.
A really lot of GTK+ Applications install the half of GNOME too, just becease they are compiled like then. They can work without the half GNOME but than you have to compile it yourself without all the GNOME support a non-gnome user dont want.
So not KPhotoAlbum is fat and have fat dependencys. The way it is compiled (which you cant change (except you do it by hand) because you use a simple distribution) is fat and designed for a KDE Environment.
Arch is designed to install the packages in a way that the most users want.
The problem is right now that you dont want to use KPhotoAlbum/digiKam in the way that the most users wants to use. You want to use it without KDE.
What we´re talking here is more a fundamental problem about simplicity.
Last edited by Vamp898 (2010-09-05 12:41:36)
Offline
Well, it's not so easy
I use Gentoo, but found Arch forums more active - so I decided to ask here. Neverthless - it's all about linux applications, not distrowars - isn't it?
And it's not exactly that I
dont want to use KPhotoAlbum/digiKam in the way that the most users wants to use
- I just don't want to use them at all looking for a lightweight alternative.
Maybe it's the fact that after many, many years with opensource software I learned that many of its power comes from having the choice. I can choose from many distros, DE's, viewers, browsers etc.
And now it seems that I have only one proper choice when it comes to photo tagging.
I suspect this may be the thing that makes me so unconvinced...
P.S.
I accidentaly found two more similar topics - the problem really seems to be difficult to solve
https://bbs.archlinux.org/viewtopic.php?pid=685323
https://bbs.archlinux.org/viewtopic.php?pid=518538
Last edited by gorky (2010-09-05 13:44:08)
Offline
First of all, its no problem. 66mb as dependency is no problem except your harddisk is limited to 150mb of size
second, you have the choose
F-Spot, KPhotoAlbum, digiKam
There are minimum three applications that all work very good without problems in every Desktop Environment.
As Richard Stallman said. The Power of Choose is about the application and not if its written in Qt or GTK+ or whatever.
You dont want a alternative to KPhotoAlbum
You want KPhotoAlbum without K
Why should people do the work to write an already existing application again just without Qt/KDE Dependency? That have nothing to do with choose and Richard Stallman agrees me with that (and if he dont have knowledge about Free-Software, who then?)
People have a Movie in size of 700-4400mb on there harddisk which they maybe never watch again but care about 66mb of dependency of a very good app.
We dont talk about a problem here, we talk about principles
Last edited by Vamp898 (2010-09-05 15:53:30)
Offline
Gorky, don't feed the trolls.
Offline
Yeah, I'm quite new here, just discovered the thread about tiling which clarfies that some of my argumentation could have been pointless
Anyway I'm still open to any sugestions about photo management, otherwise EOT...
Offline
did you tried gthumb?
extra/gthumb 2.10.12-1
Image browser and viewer for the GNOME Desktop
i dont know if he supports tagging but on screenshots he looks more/less like f-spot
Last edited by Vamp898 (2010-09-08 10:29:00)
Offline
Tagging support is poor with gthumb.
Currently I'm paying very close attention to the development of shotwell.
The developers promised to implement nested tag hierarchy in one of the future versions.
When it is done, the program will probably suit my needs, as it is really fast and quite simple.
Last edited by gorky (2010-09-08 11:33:03)
Offline
Offline
I've been meaning to give jBrout a try but haven't had the time/need to.
I've tried it (the cvs version). The ideas behind the project seem to be OK, but it is still far from optimal when it comes to implementation.
Not very intuitive and almost no customization is possible. I've experienced crashes quite often, too.
Using ang helping to develop it may be a good exercise, but it's certainly not a workhorse which I need.
gorky wrote:As I work only with RAWs, my workhorse is RawTherapee, which - unortunately - has no database features.
Darktable's a great alternative and has tagging support.
Wow, looks VERY impressive!
I'd certainly try it ASAP.
Offline
OK, I've just tried darktable, so here go pros and cons after a short rendez vous
+ really well designed UI, for me it obviously beats RawTherapee
+ RAW-oriented workflow is really very intuitive
+ did I mention one of the best UI's I've ever seen?
- slooooooow (when compared to UFRaw/RT)
- not as stable as RT (I managed to crash it after 5 minutes of work)
- some minor UI annoyances (but fully understadable in development version)
- but the thing that makes it unusable is the lack of monitor profile support
The processed image quality also seems to be worse when compared to one produced with RT, but I don't want to judge this after such a short play.
What about tags? Hmmm... The are But the implementation is quite primitive - obviously it's better than nothing, but still far away from perfect.
To sum up - darktable seem to have great potential, but needs a lot of engine tuning and polishing - the outer layer is good enough. But without full ICC support it is unusable, which is really sad.
If there was an application with darktable's UI and Rawtherapee's engine it would certainly be a killer. And tag support could be improved, for sure
Last edited by gorky (2010-09-08 22:25:39)
Offline
Already tried this?
aur/digikam-slim 0.10.0-1 (7)
Digital photo management application for kde
aur/kipi-plugins-slim 0.3.0-1 (6)
kipi plugins for digikam-slim and kde apps
afaik they should have much less dependencys (but less features too) than the standard digikam.
Last edited by Vamp898 (2010-09-09 08:49:24)
Offline
- slooooooow (when compared to UFRaw/RT)
If you have a multi core system be sure to compile with --enable-openmp.
- not as stable as RT (I managed to crash it after 5 minutes of work)
Well if you can find the time to report the issues the devs are very active.
- but the thing that makes it unusable is the lack of monitor profile support
I'm guess the following should work: load your profile with xcalib (or what ever) and use system display profile in the output color profile plug-in.
Anyway I just came across another program for you to try out (if you haven't already): GTKRawGallery.
Offline
gorky wrote:- slooooooow (when compared to UFRaw/RT)
If you have a multi core system be sure to compile with --enable-openmp.
Unfortunately no multicore (yet) - currently having an old Athlon, I'm still waiting for Sandy Bridge, which should have better IGP than current generation of Intel processors.
gorky wrote:- not as stable as RT (I managed to crash it after 5 minutes of work)
Well if you can find the time to report the issues the devs are very active.
Surely I will
gorky wrote:- but the thing that makes it unusable is the lack of monitor profile support
I'm guess the following should work: load your profile with xcalib (or what ever) and use system display profile in the output color profile plug-in.
I guess that 'output profile' is the profile attached to the photo, not the one used to send it to display. At least this is how it is called in other applications.
Anyway I just came across another program for you to try out (if you haven't already): GTKRawGallery.
I'll certainly try this one And thank you for all the response!
Offline