I have been running a reasonably large f-spot database for a while myself, running on 192920 photos (app 2tb) at the moment. So I have been spending some time waiting for photos to import during the years.
I also have been wondering why it uses so much CPU power to import files. Also one practical thing I have been wondering: when i import a bigger batch of photos, I first choose import but when all files are ready I have to press import again. So if I leave my computer to import stuff for the night, I will not get to use it in the morning, since I have to press the Import button and wait for quite some time before I actually can do anything. And since I will have to also merge the raw files, it takes me a really long time before I can actually start doing anything. If there were some commandline tools, I could make a script that would import photos and merge the raws, so if I leave the computer to do it for the night, everything would be ready in the morning. Still I am not entirely against the import with preview. If it would have more options: like full screen preview, more versatility in tagging, delete/remove from catalog option and so, I would get most of the things done at importing stage I need to do. -Antti On Sat, May 15, 2010 at 10:43 PM, Robert Latest <[email protected]>wrote: > On Sat, May 15, 2010 at 9:08 PM, Ruben Vermeersch <[email protected]> > wrote: > > Import is quite problematic right now (and needs to be replaced). I've > > just reworked part of it, to make it somewhat better, but it's a known > > fact that it tends to swallow memory on import. > > Hi Ruben, > > thanks for the reply. Having done some work on exactly this kind of > stuff I know that it can be done much more efficiently. In fact I'd > really like to modify my GUI-less import tool so it can quickly scan > the entire directory tree and add new pictures. > > Looking at the source, however, I saw that f-spot's MD5 sum generation > depends on the availability of thumbnails in gdk-pixbuf format, which > sadly locks the entire database<->file interface into an (in my eyes > unneccessary) dependency on the GUI. > > In order to faciliate interfacing to non-GUI and/or non-GTK tools I > would propose to base the MD5 sum generation on the file contents > alone. I would also lose the thumbnail display on import, therefore > making the whole procedure a lot less ressource hungry. Like I stated > above, I can MD5 hash my entire photo dirtree (44GB/20k photos) in > just a few minutes and file the hashes as well as lots of EXIF > metatdate in a sqlite db in just a few minutes. > > I'm too geeky and know too much about what's neccessary and what isn't > (or at least I think I do) in order to tolerate this. > > Keep in mind that the first thing an f-spot newbie (like me) wants to > do is to import his entire photo collection into the new exciting > software. He doesn't want to see the machine grind to a halt while > looking at a screenful of well-known thumbnails! > > But enough rants for now: Thanks for the great work, keep it up! > > > That being said, we do have users with over 30k photos, so it is > > possible. Fixing the problems with memory is a high priority task. Hang > > on. > > Scanning a directory tree and evaluating files one-by-one is extremely > easy on memory. I really would like to contribute a non-GUI import > tool (in pure C, I know nothing about C#), but that would require the > possibility of creating the MD5 sum without GTK dependency. > > Regards, > robert > _______________________________________________ > f-spot-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/f-spot-list >
_______________________________________________ f-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
