Re: [Tracker] nikon project
- From: Alexey Fisher <bug-track fisher-privat net>
- To: Adrien Bustany <abustany gnome org>
- Cc: Tracker list <tracker-list gnome org>
- Subject: Re: [Tracker] nikon project
- Date: Wed, 24 Mar 2010 16:29:06 +0200
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
or in photo downloader. It seems like it will be better than
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
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.
That is, it would be a regular binary (invoked by the desktop
when a camera device is detected) which would import the photos to a
standard location (presumably the XDG dir), and insert
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:
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:
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
3) combined. mix of old name and date:
is better but it seems to be too long.
May be some thing like this:
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
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
about the same subject...
ok, no problem.
Here is my thoughts about GUI and what should an camera importer do:
Comments are welcome.
] [Thread Prev