Re: [Tracker] nikon project

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

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


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

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:

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]