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... > >>> I don't think it is a good idea to have a 'camera importer' inbuilt in > >>> Solang. We used to have this earlier, but it is much better to have a > >>> stand alone application (not tied to a particular photo manager) that > >>> benefits the entire desktop. > >> > >> No no, i'm not about 'camera importer' here. Please take a look at the > >> screenshots at this page: > >> http://docs.google.com/View?id=d57752n_27ddtp6qzj > > Displaying the information that has already been inserted into Tracker > from the DCIM filesystem is one thing, and inserting the information > into Tracker is another different thing. My idea is to have a separate > program do the DCIM to Tracker, and let the photo managers and other > programs handle presenting this information to the user. Ohh... some times i think my english is really worse than i think. I never mixed importer and photo manager! From the beginning i talked about different apps. OK. current state: 1) DCIM should be interpreted outside of tracker. 2) at leas for Panasonic i need to extract metadata before i interpret DCIM 3) In current state i can't use gstraemer and tracker to extract metadata. No support for EXIF inside of RIFF and no support for RAW. 4) I do not have all DCIM patterns, so the code should be flexible. 5) Import in standard location, using XDG. 6) What about Gnome vs KDE? backend<>frontend 7) Generate new names for files. What kind of names? is this ok: Photos/Year/Month/Day/20091225_094950_0540.jpg ? 8) give user choice what to import? (i never use it...). Choice to tag before import (List of tags known in tracker). _______________________________________________ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
