Digikam: waarom wél of niet met xmp-sidecar-bestanden werken

[Jenske]

Ik gebruik Digikam voor het beheer van mijn 35.000+ foto's.
Je hebt de mogelijkheid om informatie zoals titel, fotograaf enzovoort te laten schrijven naar het bestand zélf (als het beschrijfbare jpg's zijn), naar een zgn. sidecar-bestand (een apart bestand met zelfde naam als fotobestand, maar dan met extensie xmp) of de gewone database die Digikam intern gebruikt.
Verder kan je bij de instellingen ervoor kiezen dat ...

• alle gegevens van de database (die DK sowieso intern gebruikt) wordt geschreven naar xmp-bestanden
• alle gegevens van de datbase alleen worden geschreven naar een sidecar-bestand als de foto zélf schrijfbeveiligd is (bv. bij RAW-beelden)
  

En dan kan je nog kiezen om alle gegevens te schrijven dan wel te lezen (OF beiden!) naar en van de database en xmp-bestanden.

Aangezien ik veel foto's heb, kost al dat gelees en geschrijf erg veel tijd. Ik vraag me dus af of ik niet best al dat xmp-gedoe AF zet en vervolgens ALLE xmp-bestanden in mijn fotomap verwijder.

Maar klopt mijn redenering wel?

[jvecht]

Geen idee, Jenske. Ik gebruik Digikam niet.

Maar het probleem van het beheer van een heel grote verzameling foto's ken ik wel (het begint hier langzaam richting de 1 TB te gaan) en het enorme beslag wat programma's om zo'n verzameling te beheren op je PC doet ook.

Ik doe het nu al heel lang zo, dat ik alle foto's van een dag in een map bewaar. Ik deel dat in met een hoofdmap voor het jaar, dan een map voor de maand en dan die map voor de dag. Daarmee is de datum vastgelegd. Dan zet ik in elke dagmap een simpel tekstbestand met de naam "fototag" en daarachter de sleutelwoorden voor die opnamen.

Met de terminalopdracht

Code: [Selecteer]

find . -name *fototag* -type f
krijg ik razendsnel een mooi overzicht en met

Code: [Selecteer]

find . -name *fototag* -type f > demo.txt
krijg ik een net tekstbestandje. Je kan de zoekterm fototag ook vervangen door een ander zoekwoord, maar meestal doe ik dat verder zoeken dan wel in het gemaakte tekstbestand.

Bovendien is dit heel universeel en niet van een programma afhankelijk. Dat wilde ik ook niet meer. Dat was me te kwetsbaar en vrijwel altijd vervuilen dergelijke programma's de boel ook nog

Misschien heb je wat aan die methode. Dit vertraagt je PC niet.

[MKe]

Mijn werk is Big Data. Dit probleem is idd algemeen. De reden waarom je zowel de xmp bestanden als de database wilt houden is dat je met de xmp files altijd je database kan herstellen als die database (sqlite) corrupt raakt. Overigens gebruikt digikam standaard sqlite3. Deze database vorm heeft duidelijk beperkingen, vooral wat snelheid betreft. Volgens mij kan digikam ook met mysql overweg. Misschien is dat een optie voor je met deze aantallen foto's. Met mysql is de kans op een beschadigde database ook een stuk minder.

Tja, jvecht's methode is een slimme manier om de foto's bij te houden.. Je zou ook nog al die keywords bestanden in een key-value database kunnen gooien of een full text search en dan heb je zelfs een nog snellere methode. 
Tmsu is trouwens ook een zeer mooi programma om dit te doen. Dan kun je zelfs een virtual filesysteem mounten waar de bestanden gerangschikt zijn bij tag of zelfs by query van jou. Dit is wat ik gebruik, naast shotwell voor de meest recente foto's. http://tmsu.org/

Overigens is in de echte big data wereld de oplossing om een object store te maken. Dat is een distributed systeem waar metadata in de objecten (=files) wordt opgeslagen en waarin je files nooit corrupt raken.

[Paul Matthijsse]

...en waarin je files nooit corrupt raken.

Bestaat niet.

[MKe]

Klopt, dat is de hele filesofie achter distributed objectstore. Je gaat er vanuit dat iets altijd een keer stuk gaat, dus zorg je ervoor dat het stuk gaan van een sector, harde schijf, zelfs een server of een volledig datacentrum geen enkele invloed heeft op de data. Voor de gebruiker gaat het bestand dus nooit stuk.

[Paul Matthijsse]

Ah, Wikipedia bracht verduidelijking. EMC, HDS, Dropbox, Facebook, Google, MS... Ze gebruiken het allemaal. Zal dus wel goed zijn ;-)

[Paul Matthijsse]

Aangezien ik veel foto's heb, kost al dat gelees en geschrijf erg veel tijd. Ik vraag me dus af of ik niet best al dat xmp-gedoe AF zet en vervolgens ALLE xmp-bestanden in mijn fotomap verwijder.

Maar klopt mijn redenering wel?

Hallo, Volgens mij is dat "kost veel tijd" eenmalig. Ik heb vorige week Digikam weer eens geïnstalleerd en de opdracht gegeven om mijn fotomap in te lezen. Dat ding is ongeveer 250 GB groot en dat duurde een uur of vier (zonder enige waarschuwing vooraf...). Daarna kan ik snel door de verschillende mappen en maanden en jaren navigeren.
Die sidecar-bestanden kunnen op meerdere manieren (en/of in verschillende programma's) van pas komen en het is aan jou om te oordelen of je dat wilt of niet. Mijn ervaring is dat als je tags of locaties of persoonsnamen gaat invoeren (wie er op de foto staat en waar bijvoorbeeld, wanneer, etc.), niet alle programma's in staat zijn om die info te lezen. Volgens mij omdat die xmp-info nog niet goed is uitgekristalliseerd/gedefinieerd en diverse programma's diverse infovelden gebruiken, of delen daarvan of variaties daarop. Dus je hele fotoverzameling definitief taggen en beschrijven met één programma kan betekenen dat een deel of veel van die info in een ander programma niet of deels leesbaar is. Om die reden gebruik ik geen tags of andere aanduidingen.

[Jenske]

Vooral Mke's argument vind ik sterk én een reden om dus tóch met die xmp-bestanden te werken.
Anderzijds ben ik er wel een beetje ongerust door geraakt. Kan de database van Digikam dan corrupt geraken? Let op: ik ben geen naïeveling, maar het feit dat Mke vermeldt dat het kan, doet me vermoeden dat het al is gebeurd.

In 't algemeen heb ik wél 1 groot probleem met Digikam: dat er nogal wat opties en mogelijkheden aan of af kunnen worden gezet, maar dat er nergens bij staat WAAROM je dat aan of af zou zetten, noch wat de eventuele gevaren zijn.

Deze opmerking heb ik overigens niet alleen bij nogal wat open source software, maar ook de "zo geliefde" mikrosoft-programma's bevatten soms functies waarvan niet duidelijk is waarom je ze wél of niet zou gebruiken.

[MKe]

Het is bij mij inderdaad al gebeurd. Ik zou, als ik jou was, echt overwegen om mysql/mariadb te installeren en die als database voor digikam te gebruiken.  Zeker met die aantallen. 
Met digikam heb je wel een programma genomen die idd heel veel opties heeft. Voor mij was dat een reden om het niet meer te gebruiken, aangezien mijn doel alleen maar een simpel foto beheer was. Editing doe ik in Darktable.

[jvecht]

In 't algemeen heb ik wél 1 groot probleem met Digikam: dat er nogal wat opties en mogelijkheden aan of af kunnen worden gezet, maar dat er nergens bij staat WAAROM je dat aan of af zou zetten, noch wat de eventuele gevaren zijn.

Deze opmerking heb ik overigens niet alleen bij nogal wat open source software, maar ook de "zo geliefde" mikrosoft-programma's bevatten soms functies waarvan niet duidelijk is waarom je ze wél of niet zou gebruiken.

Inderdaad. Dan verdrink ik in opties, waarbij ik niet weet wat ik er mee kan. Nou ben ik dan wel zo dat ik de schuifjes, of wat het dan ook mag zijn, wel een paar zwiepen naar links en rechts geef om te zien wat er gebeurt. Maar als ik er niets mee kan, dan hoeft het van mij niet meer. Geef me maar wat lekker simpels.