<div dir="ltr">
<span></span>
<p style="line-height:115%;margin-bottom:0in;background:transparent">
The basis which decided the structure:<br>=============================<br></p>
<ol><li><p style="line-height:115%;margin-bottom:0in;background:transparent">I do not write
a diary, I photograph, images are my diary. This is how my brain
works.</p>
</li><li><p style="line-height:115%;margin-bottom:0in;background:transparent">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.<br></p>
</li><li><p style="line-height:115%;margin-bottom:0in;background:transparent">This means I
can create a rigid structure. What’s entered, stays. There is no
delete function.</p>
</li><li><p style="line-height:115%;margin-bottom:0in;background:transparent">There is no
database “language”, like SQL.<br></p>
</li><li><p style="line-height:115%;margin-bottom:0in;background:transparent">It’s web
based. I can use Apache or the inbuilt development web server in PHP</p>
</li></ol>
<p style="line-height:115%;margin-bottom:0in;background:transparent"><br>
</p>
<p style="line-height:115%;margin-bottom:0in;background:transparent">Usage:<br>=====<br></p>
<p style="line-height:115%;margin-bottom:0in;background:transparent">Once a year I import
all images taken the year before. This creates all records needed, as
the images are loaded.. <br>There are many external tools created for this purpose.<br></p>
<p style="line-height:115%;margin-bottom:0in;background:transparent"><br></p><p style="line-height:115%;margin-bottom:0in;background:transparent">Structure:<br>=======<br>
</p>
<ol><li><p style="line-height:115%;margin-bottom:0in;background:transparent">There is one
file for exif data, “data”</p>
</li><li><p style="line-height:115%;margin-bottom:0in;background:transparent">There are three
files for tags called “what”,”when” and “where”</p>
</li><li><p style="line-height:115%;margin-bottom:0in;background:transparent">To connect
“data” with the tag files there is an index called “datab”</p>
</li><li><p style="line-height:115%;margin-bottom:0in;background:transparent">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.
<br>Annotating will later fill these already existing records with text. The
hashing mechanism means there is no index to the texts.</p>
</li><li><p style="line-height:115%;margin-bottom:0in;background:transparent">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..</p>
</li><li><p style="line-height:115%;margin-bottom:0in;background:transparent">All images directories are named as the current date when created. <br>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.<br>When you know the name of the dir where an image resides you also know the approximate date of it's creation.<br></p>
</li></ol>
<p style="line-height:115%;margin-bottom:0in;background:transparent"><br></p><p style="line-height:115%;margin-bottom:0in;background:transparent">Searching:<br>========<br></p>
<p style="line-height:115%;margin-bottom:0in;background:transparent">There exists a
search function. This loads all meta data (only some the exif fields)
into the “memcached” cache to minimize execution time.</p>
<p style="line-height:115%;margin-bottom:0in;background:transparent">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.<br>Etc. etc.<br></p>
<p style="line-height:115%;margin-bottom:0in;background:transparent">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.</p><p style="line-height:115%;margin-bottom:0in;background:transparent"><br></p>
<p style="line-height:115%;margin-bottom:0in;background:transparent">The rigidity<br>========<br></p><p style="line-height:115%;margin-bottom:0in;background:transparent">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!<br></p>
<p style="line-height:100%;margin-bottom:0in;background:transparent">My input app looks like the image below.<br>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!<br>But, it's like in KPA, the entry form is mirrored in the search form for natural reasons.</p><p style="line-height:100%;margin-bottom:0in;background:transparent"><br></p>
<p style="line-height:100%;margin-bottom:0in;background:transparent">As you see, importing from this troglodyte of a database can only be done by an expert! Me!<br>If I were employed, this would have created my total job security. I'm like Sid in User Friendly, though not quite so skilled. <br>Also I do not use punch cards since my last university course where I programmed in Cobol.<br></p><p style="line-height:100%;margin-bottom:0in;background:transparent">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.<br>I think I'll go and buy a fat trappist beer, I'm worth it! <br>:0)<br></p><p style="line-height:100%;margin-bottom:0in;background:transparent">Cheers,</p><p style="line-height:100%;margin-bottom:0in;background:transparent">Per<br></p>
</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 30, 2022 at 11:15 PM Johannes Zarl-Zierl <<a href="mailto:johannes@zarl-zierl.at">johannes@zarl-zierl.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Per,<br>
<br>
<br>
Am Samstag, 29. Oktober 2022, 16:28:53 CET schrieb Per Funke:<br>
> Perfect!<br>
> Thanks, that's what I needed to make sure!<br>
> My images, scanned from 7000+ b/w paper photos and diafilm, are stored in a<br>
> selfmade database. That project started in 2011 and was finished in 2020.<br>
<br>
Ok, so that rules out putting the date into the exif data.<br>
<br>
There are two ways to achieve what you want:<br>
1. Create a .kim file<br>
2. Directly write the index.xml file<br>
<br>
Regarding 1.: .kim files are the "official" import files for kphotoalbum. You can <br>
export a subset of your database as a .kim file and import it somewhere else <br>
(all within the regular GUI). This way also presents you with the tag data and <br>
lets you map categories/tags upon existing ones.<br>
AFAIK there is no documentation of the .kim file format yet (although it is <br>
relatively simple and very similar to the index.xml file format).<br>
<br>
Regarding 2.: If you only do the import once, it may be quicker to directly <br>
write the data into the index.xml file. The file format is fairly <br>
straightforward, and is described here:<br>
<a href="https://invent.kde.org/graphics/kphotoalbum/-/blob/master/dev/documentation/database-layout.md" rel="noreferrer" target="_blank">https://invent.kde.org/graphics/kphotoalbum/-/blob/master/dev/documentation/<br>
database-layout.md</a><br>
<br>
Of course with alternative 2., kphotoalbum can't really protect you against <br>
errors.<br>
<br>
> Is fun to see that the structure in KPA is very similar to my project but<br>
> the UX is much better in KPA. That's the reason for the need to import.<br>
<br>
May I ask how your current setup works / how the data is set up?<br>
<br>
Cheers,<br>
Johannes<br>
<br>
<br>
<br>
</blockquote></div>