Fwd: Re: Batch import of images

[Per Funke]

The basis which decided the structure:
=============================

   1.

   I do not write a diary, I photograph, images are my diary. This is how
   my brain works.
   2.

   nobody else but me will ever add things. When I die, the project’s
   development and expansion dies. It’s my legacy. Yeah, I'm that old.
   3.

   This means I can create a rigid structure. What’s entered, stays. There
   is no delete function.
   4.

   There is no database “language”, like SQL.
   5.

   It’s web based. I can use Apache or the inbuilt development web server
   in PHP


Usage:
=====

Once a year I import all images taken the year before. This creates all
records needed, as the images are loaded..
There are many external tools created for this purpose.


Structure:
=======

   1.

   There is one file for exif data, “data”
   2.

   There are three files for tags called “what”,”when” and “where”
   3.

   To connect “data” with the tag files there is an index called “datab”
   4.

   The record id of the datab records are hashed, creating a file structure
   called “more_txt”. An empty file is created for each record when imported.
   Annotating will later fill these already existing records with text. The
   hashing mechanism means there is no index to the texts.
   5.

   For searching purposes there is a index connecting all existing tags
   (tags that are used, not empty ones) to the “datab” file’s record(s) where
   that tag is used..
   6.

   All images directories are named as the current date when created.
   This means the dir contains images from the name (date) of the dir
   before it, up to the date that constitutes it’s own name.
   When you know the name of the dir where an image resides you also know
   the approximate date of it's creation.


Searching:
========

There exists a search function. This loads all meta data (only some the
exif fields) into the “memcached” cache to minimize execution time.

The records are presented via a relevance filter. If you search, let’s say
with two tags, the most relevant images will be those tagged with both
tags. They are shown in rows until the end. Then there will be a vertical
space and the next section will contain the ones tagged with only  the
first tag you entered, followed by a new vertical space and the section of
images tagged only with the other tag, the second one.
Etc. etc.

Hovering over images, (some) exif data, image file location and more_txt
file location and comments are available in a separate window, making
editing by external means possible.


The rigidity
========

All addresses to data of any kind (with the exeption of the images’
comments) are relative file positions. There is no searching in tables,
everything is pointed to by the exact location in the files. Horrible,
isn’t it!? Move/delete something and the house of cards goes down. Whump!

My input app looks like the image below.
Unfortunately I can't show my search form since I'm still fighting type
errors after upgrading to PHP 8.1. They seem to have screwed up their line
number reporting which really doesn't help. Arrghh!
But, it's like in KPA, the entry form is mirrored in the search form for
natural reasons.


As you see, importing from this troglodyte of a database can only be done
by an expert! Me!
If I were employed, this would have created my total job security. I'm like
Sid in User Friendly, though not quite so skilled.
Also I do not use punch cards since my last university course where I
programmed in Cobol.

It was kind of fun doing this description. That's something I've never
done, ever. I had it all in my head from the beginning. Now it's in writing.
I think I'll go and buy a fat trappist beer, I'm worth it!
:0)

Cheers,

Per

On Sun, Oct 30, 2022 at 11:15 PM Johannes Zarl-Zierl <johannes at zarl-zierl.at>
wrote:

> Hi Per,
>
>
> Am Samstag, 29. Oktober 2022, 16:28:53 CET schrieb Per Funke:
> > Perfect!
> > Thanks, that's what I needed to make sure!
> > My images, scanned from 7000+ b/w paper photos and diafilm, are stored
> in a
> > selfmade database. That project started in 2011 and was finished in 2020.
>
> Ok, so that rules out putting the date into the exif data.
>
> There are two ways to achieve what you want:
> 1. Create a .kim file
> 2. Directly write the index.xml file
>
> Regarding 1.: .kim files are the "official" import files for kphotoalbum.
> You can
> export a subset of your database as a .kim file and import it somewhere
> else
> (all within the regular GUI). This way also presents you with the tag data
> and
> lets you map categories/tags upon existing ones.
> AFAIK there is no documentation of the .kim file format yet (although it
> is
> relatively simple and very similar to the index.xml file format).
>
> Regarding 2.: If you only do the import once, it may be quicker to
> directly
> write the data into the index.xml file. The file format is fairly
> straightforward, and is described here:
>
> https://invent.kde.org/graphics/kphotoalbum/-/blob/master/dev/documentation/
> database-layout.md
> <https://invent.kde.org/graphics/kphotoalbum/-/blob/master/dev/documentation/database-layout.md>
>
> Of course with alternative 2., kphotoalbum can't really protect you
> against
> errors.
>
> > Is fun to see that the structure in KPA is very similar to my project but
> > the UX is much better in KPA. That's the reason for the need to import.
>
> May I ask how your current setup works / how the data is set up?
>
> Cheers,
>   Johannes
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20221031/46a4169b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_20221031_140523__01.jpg
Type: image/jpeg
Size: 1966468 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20221031/46a4169b/attachment-0001.jpg>