Am Dienstag, den 23.03.2010, 17:00 +0100 schrieb Adrien Bustany: > On Tue, 23 Mar 2010 17:14:30 +0200, Alexey Fisher > <bug-tr...@fisher-privat.net> wrote: > > Am Dienstag, den 23.03.2010, 15:20 +0200 schrieb Debarshi Ray: > >> >> Before i start actual coding i need to know what is where located. I > >> >> mean if do DCIM interpreter, should it be located in > tracker-extractor > >> >> or in photo downloader. It seems like it will be better than > >> >> interpreter > >> >> will be inside of the tracker and downloader should only update file > >> >> paths in tracker database. > >> > >> > I think Debarshi thinks about a stand alone, tracker enabled photo > >> > importer. > >> > >> Yes, a tracker enabled photo importer looks a better idea to me. > > > > Ok, i agree. DCIM used only on camera and make sense only on import. > > So probably there is no need to integrate it to tracker (hallo tracker > > people, what do you thing?) > > > >> A DCIM filesystem is not going to be around as long as a normal > >> filesystem. The user will plugin in the camera copy the files to some > >> other storage and then unplug it a few minutes later. So if Tracker is > >> going to mine the DCIM filesystem it will have to update itself again > >> when the files are moved. To avoid this, we can just ask the camera > >> importer to do the job of extracting the DCIM information. > >> > >> Moreover the camera importer should also allow the user to attach tags > >> to the files being imported. > > > > yes > > > >> > That is, it would be a regular binary (invoked by the desktop > >> > environment > >> > when a camera device is detected) which would import the photos to a > >> > standard location (presumably the XDG dir), and insert > >> > extracted/inferred metadata > >> > into Tracker. > >> > >> Exactly. > >> > >> We might have to figure out how to avoid overwriting other files when > >> importing a new set of photos. (It would be good to avoid asking the > >> user to create and specify a unique location.) > > > > Yeah, this is a problem. Independent of the way i choice. For example: > > > > 1) If use the way F-Spot do: > > Photos/Year/Mont/day/not_changed_image_names.jpg > > will fail on Nikon. Because it use same image names in different > > DCIM/dirs. Some times it will go in conflict. > > > > 2) If i rename to date format: > > Photos/Year/Month/Day/2009-12-25_09-49-50.jpg > > will fail because my other cam can make more than one photo in a second. > > And if I'm correct EXIF do not support milliseconds. At leas not in my > > cam. > > > > 3) combined. mix of old name and date: > > Photos/Year/Month/Day/20091225_094950_IMG_0540.jpg > > is better but it seems to be too long. > > May be some thing like this: > > Photos/Year/Month/Day/20091225_094950_0540.jpg > > > > Other problem is checking for duplicates. > > F-Spot use md5sum hashes. It i really secure but take long time to > > generate hashes and i will need to store hashes some were. > > Other thing will be just to check if file exist before i copy it and if > > is, i will compare some exif info, like manufacture and iso settings... > > You could also emulate the concept of "sequence" found in many RDBMS, ie a > global counter that you increment for each photo. Not sure it's the best > solution though.
We do not need to emulate. Every file on DCIM has sequence number. It will be good idea to use it :) > BTW, maybe we could join your two threads ? In the end they're more or > less > about the same subject... > ok, no problem. Here is my thoughts about GUI and what should an camera importer do: http://docs.google.com/View?id=d57752n_34gfbp27cn Comments are welcome. Regards, Alexey _______________________________________________ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
