multiple sidecar files vs. combined database

16 views
Skip to first unread message

Ty Mayn

unread,
Dec 15, 2018, 12:13:36 PM12/15/18
to JPhotoTagger Users English

 I am a newbie wanting to understand the architecture chosen for Jphototagger
  Elmar explained in a recent post that the default choice is
"To write sidecar files is a key concept and will not be changed."
  I like  emphatic rules but
could Elmar give more detail about the choice
1.  Is there a new sidecar file generated for any photo file accessed or
      only a new sidecar when a tag is actually created for a given photo file?
     Does 2000 photos  accessed equal 2000 sidecar files

2. Where do the sidecar files live  and how large are they and how do they influence access speed as they grow in number

3. In creating the software was there study towards  using a database instead of sidecar files for separated metadata?
    What factors led to sidecar design?

I appreciate the rich collection of posts and also welcome link to my type of question in past posts
  Ty


Elmar Baumann

unread,
Dec 15, 2018, 1:35:04 PM12/15/18
to jphototagger-...@googlegroups.com, Ty Mayn
Am 15.12.18 um 18:13 schrieb Ty Mayn:
> 1.  Is there a new sidecar file generated for any photo file accessed or
>     only a new sidecar when a tag is actually created for a given
> photo file?
>     Does 2000 photos  accessed equal 2000 sidecar files

A sidecar file will be created only, when an image was tagged. This can
be done manually by the user or via importing embedded XMP or IPTC.

> 2. Where do the sidecar files live  and how large are they and how do
> they influence access speed as they grow in number

The sidecar file is in the same folder as the image - thus the name
"sidecar", because it's side by side with an image. It's very small
compared to the image, usually a few Kilobytes (regarding my images: 1
to 5 Kilobytes). The speed is not a known issue: Only when changes were
made externally to the XMP file, it's contents will be re-read by
JPhotoTagger (Comparison via file date and/or file size). Otherwise the
XMP files remain untouched. On the other side, the speed is always an
issue, when images are on a slow NAS (not recommended, especially when a
huge number is displayed at the same time).

> 3. In creating the software was there study towards  using a database
> instead of sidecar files for separated metadata?
>     What factors led to sidecar design?

A database is practically always a proprietary solution. It's useless
when you switch to another program. The XMP format of the sidecar files
is a largely known standard since more than two decades and supported by
other software products. An XMP file also very small. When changing or
adding tags, a backup will be much faster (thousand and more times) than
embedded metadata such as IPTC or embedded XMP. It also does not damage
an image, which is possible when modifying the image file through
editing embedded XMP or IPTC. If necessary, it can be embedded into an
image e.g. external with ExifTool or in JPhotoTagger using ExifTool. The
contents (tags) of a XMP file can be viewed with every operating system
either on command line or with an text editor (saves your work for a
long time). And last not least, if the database gets damaged - and this
is not a very rare case - JPhotoTagger automatically grabs the XMP file
contents and updates it's database. All metadata applied to an image is
side by side with the image. With a database only solution, all your
work will be lost, when the database is corrupted, if you don't have a
functionally database backup.

Regards,
Elmar
Reply all
Reply to author
Forward
0 new messages