[Digikam-users] Using digikam on two computers?

Heiner Lamprecht heiner at heiner-lamprecht.net
Sat Jun 17 12:28:05 BST 2006


On Saturday 17 June 2006 02:52, Arnd Baecker wrote:
> On Fri, 16 Jun 2006, Turgut Durduran wrote:
> >
> > > Yes, but maybe if one does an "intelligent" syncing
> > > procedure it  might work.
> >
> > I was thinking of "unison"
> > (http://www.cis.upenn.edu/~bcpierce/unison/) or some
> > script based on rsync. What you describe below is
> > doable if the users are careful.
>
> Whatever the technical solution is, I think it is absolutely
> necessary that this works without the two computers being
> connected all the time.
> of tags (which might still be ok, actually).

Full ACK.

> > > (4) Adding the changes back to the main computer:
> > >
> > >     (a) First add all additional tags into the main
> > > digikam3.db        database
> >
> > If we make one further assumption that there will not
> > be any changes on the main computer while the "laptop
> > is in the field" , then we can just copy back the
> > digikam3.db , is that correct?
>
> yes - that should work, at
> least I cannot see any problem at the moment
> (maybe one could add some protection methods
> which make sure that indeed no changes have been applied,
> e.g. by an md5 checksum of the original database
> which is compared before copying the new one over
> the old one on the main computer)

I think, some export / import mechanism would be better than just 
copying the whole database.  In my opinion, it's not necessary to 
copy all images (even resized) to the laptop.  When I'm on a trip, 
I don't need all photos of all previous trips.  It would be fine to 
just have the tags available, and maybe a subset of the images, if 
I'm in a region I have been before.

If you just copy the database, this will only work with sqlite.  But 
maybe in the future, we have a different backend, that is 
independent from the db.  Qt4 offers a lot in this field.

> > > Some problems/points:
> > > ad (1):
> > >    * Presently I only implemented something like
> > > this for jpg
> > >      - what about raw files?
> > >      - what about tiff/png/...
> >
> > What is the problem with these? Resizing? I can write
> > a script to resize most formats. I am not entirely
> > sure but I think we can turn the raw files to "preview
> > only" (the little tiff file attached to raw files).
>
> No problem for tiff/png (more a reminder
> to myself that I did not take care of them in my script yet)
> For raw your suggestion sounds good: but the file
> should have the same name as before the rescaling,
> right? (otherwise we would become inconsistent
> with the entries in the sqlite database)
> Is this doable?

If you think of an export and you're sure, that you will do no 
changes to the images itself, than there is no need to stick to the 
fileformat.  As far as I understand, you will use the resized 
images on the laptop as a reminder.  Just to see, what you already 
have.  But not for really working on the images.  For this, jpg or 
png would be fully sufficient.


Cheers,


    Heiner

-- 
    heiner at heiner-lamprecht dot net    GnuPG - Key: 9859E373
  Fingerprint:  3770 7947 F917 94EF 8717 BADB 0139 7554 9859 E373



More information about the Digikam-users mailing list