Re: f-spot to f-spot

["Mathieu Avoine" <avoinemt gmail com>]

Steve,

I think your idea of the export/import function is the best approach as it is non intrusive, does not pose a threat to "break" the image file nor does it alter the file in any way (so other programs see the original image and the exported one as "the same file") and it lets other program to import the files without having to deal with extra metadata that could break the import.

I would see it as either a 1 kb file per exported image file containing all its metadata (tags, comments, [insert idea here]) that would be named by the image file name with a different extension, or a single file which f-spot would prompt for upon import.

Also, this approach leaves room for other photo organizers to eventually support the metadata file so that the metadata could be shared among different programs.

My 2 cents!
Math

On 7/4/07, Steve Herber <herber thing com> wrote:

Embedding extra metadata in an image has problems.

I would propose a new export function and the corresponding import
function.  The export function would put the images and the metadata from
the sqlite database into a format that would be easy for others to import.
The import function would do the import of such a collection.

Such functions would allow easy movement of f-spot collections from one
computer to another.

One final option might be to make the import temporary.  I could send
someone a CD of my images, they could 'import' them into their F-Spot
system, search for the images they want and mark those to keep, and drop
the rest of the images.  Or, I could see splitting my images into yearly
chunks for archival and other purposes.  Or imagine some sort of picture
mash-up after an event of some sort.


Cheers!

Steve Herber    herber thing com                work: 206-221-7262
Security Engineer, UW Medicine, IT Services     home: 425-454-2399

On Wed, 4 Jul 2007, Alexandre Prokoudine wrote:

> On 7/4/07, Constantin Maslov wrote:
>
>>> Patience is a virtue. Writing sidecar files will eventually come.
>> Sidecar is just sidecar, they are always lost and corrupted.
>
> Which means they are not handled properly ;-)
>
> A user should never see or touch sidecar files directly. They should
> be read/written and moved transparently.
>
> I don't quite understand what you mean with "internal place", but if
> mean database, that you is probably not the best idea because when
> data storage is taken out of system (USB/Firewire hard drive etc.),
> all the changes you applied are useless.
>
> Alexandre
> _______________________________________________
> F-spot-list mailing list
> F-spot-list gnome org
> http://mail.gnome.org/mailman/listinfo/f-spot-list
>
_______________________________________________
F-spot-list mailing list
F-spot-list gnome org
http://mail.gnome.org/mailman/listinfo/f-spot-list