Re: [Tracker] nikon project

[Alexey Fisher <bug-track fisher-privat net>]

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).