Re: [Tracker] nikon project

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

Am Dienstag, den 23.03.2010, 17:00 +0100 schrieb Adrien Bustany:
> On Tue, 23 Mar 2010 17:14:30 +0200, Alexey Fisher
> <bug-track 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