Voorkom dat cloud-sidecars de opnamedatums van foto's wijzigen door de oorspronkelijk ingesloten opnametijd als bron van waarheid te behandelen en elke samenvoeging van sidecars eerst te testen voordat deze je hoofdarchief raakt.
In een fotobibliotheek op een thuis-NAS ontstaat het probleem meestal na een cloud-export, mobiele synchronisatie, het wegschrijven van Lightroom-sidecars of een bulkreparatie van metadata: de afbeelding ziet er nog correct uit, maar de tijdlijn, mapvolgorde of back-upvergelijking volgt plotseling de exportdatum, bewerkingsdatum of JSON-sidecardatum in plaats van het moment waarop de foto is gemaakt.
Stel vast welke datum je fotobibliotheek werkelijk gebruikt
De eerste veilige stap is om drie verschillende klokken van elkaar te scheiden: de in de camera opgeslagen opnamedatum, de wijzigings- of aanmaakdatum van het bestandssysteem en de datum in een sidecarbestand. Ze kunnen allemaal dezelfde foto beschrijven, maar foto-apps kiezen ze niet altijd in dezelfde volgorde.
Bij normale JPEG-workflows en veel RAW-workflows zijn ingesloten tags zoals DateTimeOriginal, CreateDate en ModifyDate de velden die de meeste tools controleren om te bepalen wanneer een afbeelding is gemaakt; ExifTool documenteert deze algemene datumvelden en biedt ook de snelkoppeling AllDates voor gecoördineerde wijzigingen van deze metadatadatums.
Voordat je een cloud-export in je hoofdgalerij importeert, controleer je enkele bestanden met een metadatalezer en noteer je welke waarde overeenkomt met het werkelijke opnamemoment. Als de bestandsdatum de exportdag aangeeft terwijl de ingesloten opnamedatum correct is, laat je je organizer geen mappen opnieuw indelen op basis van de klok van het bestandssysteem.
Bewaar sidecars naast foto's zonder ze automatisch te laten prevaleren
Sidecars zijn nuttig omdat ze bewerkingen, cloudcorrecties, beoordelingen, labels of ontbrekende metadata bevatten zonder de originele afbeelding opnieuw te schrijven. Het risico zit niet in hun bestaan, maar in het blind laten toepassen ervan op elk datumveld door een importer.
Adobe Lightroom Classic kan bijvoorbeeld wijzigingen automatisch naar XMP schrijven, waardoor sidecars voortdurend kunnen worden bijgewerkt terwijl je werkt. Dat is handig voor overdraagbaarheid, maar het betekent ook dat je de tijdstempel van de sidecar en de opnamedatum van de foto niet als uitwisselbaar mag beschouwen.
Verplaats of back-up elke foto samen met de bijbehorende sidecar, maar configureer je importregel zo dat sidecarbewerkingen de opnamedatum niet overschrijven, tenzij je hebt gecontroleerd dat de sidecar het gecorrigeerde opnameveld bevat dat je wilt gebruiken. Als de app een proefbewerking biedt, bekijk je de datummapping voordat je deze toepast.
Test cloud-JSON-sidecars op een kopie voordat je datums samenvoegt
Cloud-exporten voegen vaak JSON-bestanden toe waarvan de namen lijken op de bestandsnaam van de foto. Deze bestanden kunnen nuttige metadata bevatten, maar ook meerdere datums met verschillende betekenissen. Daarom is het beter eerst een kopie te testen dan de hele map rechtstreeks samen te voegen.
Handleidingen voor het herstellen van Google Photos Takeout maken vaak onderscheid tussen een veld voor de fotodatum en velden voor upload- of aanmaaktijden; een uitleg van Google Takeout-JSON-bestanden vermeldt dat photoTakenTime het tijdstip van de foto weergeeft, terwijl creationTime kan aangeven wanneer het item aan Google Photos is toegevoegd. Dat onderscheid verklaart precies waarom een blinde samenvoeging een heel archief naar het verkeerde jaar kan verplaatsen.
Kopieer tien representatieve bestanden naar een testmap, voeg alleen het bedoelde opnameveld samen en controleer de resultaten op twee plaatsen: met een metadatalezer en in de daadwerkelijke galerij-app die je op de NAS gebruikt. Ga alleen verder als beide overeenkomen met de verwachte opnamedatum en de sidecarbewerkingen nog steeds zichtbaar zijn.
Behoud wijzigingsdatums van bestanden wanneer je metadata herschrijft
Veel metadatatools schrijven een bestand opnieuw wanneer ze ingesloten velden bijwerken. Daardoor kan de wijzigingsdatum van het bestandssysteem veranderen, zelfs als de ingesloten opnamedatum nog correct is. Dat is van belang als je back-upsoftware of galerijvolgorde de wijzigingsdatum van het bestand gebruikt.
ExifTool bevat een optie om de wijzigingsdatum van het bestandssysteem te behouden voor workflows waarin metadata moet veranderen zonder de tijdstempel van het bestandssysteem te wijzigen. Dit bewijst niet dat elke app zich hetzelfde gedraagt, maar het biedt wel een veiliger patroon voor gecontroleerde reparaties.
Wanneer je gecorrigeerde datums naar bestanden moet schrijven, voer je de opdracht eerst op een kopie uit, behoud je de wijzigingsdatum van het bestand als je vervolgtools daarvan afhankelijk zijn en exporteer je een rapport met de situatie voor en na de wijziging. Stop als het opnameveld van de afbeelding correct is maar de galerij nog steeds op een andere klok sorteert; dat is een configuratieprobleem van de app en geen reden om originelen te blijven herschrijven.
Controleer het archief met mapvolgorden, galerijvolgorden en back-upverschillen
Een datumreparatie is niet voltooid wanneer de opdracht klaar is. Ze is voltooid wanneer dezelfde representatieve foto's in de juiste volgorde verschijnen in je NAS-galerij, bestandsbrowser en back-upvergelijking.
Voorbeelden uit de community rond cloud-sidecars laten vaak hetzelfde foutpatroon zien: gebruikers voegen JSON- of XMP-gegevens samen en ontdekken daarna dat een bibliotheek na het importeren het verkeerde veld gebruikt. Een PhotoStructure-ondersteuningsthread over verwarring rond datums in Google Takeout-sidecars herinnert eraan dat je naamgeving en datumsemantiek in de doelapp moet controleren, niet alleen in de exportmap.
Nadat de testbatch is geslaagd, voer je dezelfde controles uit op een grotere kopie voordat je je productieshare wijzigt. Als de resultaten tussen tools verschillen, pauzeer je de workflow, bewaar je de onaangeroerde back-up en documenteer je welk datumveld elke app leest voordat je verdergaat.
Veelgestelde vragen
Moet ik JSON- of XMP-sidecars verwijderen nadat ik foto's heb geïmporteerd?
Nee, niet voordat je hebt bevestigd dat de bewerkingen of gecorrigeerde metadata veilig zijn ingesloten of geïmporteerd. Bewaar de sidecars bij de originelen totdat een back-up en een galerijcontrole aantonen dat je ze niet meer nodig hebt.
Welke datum moet ik vertrouwen wanneer de bestandsdatum en EXIF-datum niet overeenkomen?
Vertrouw bij originele camerabestanden eerst op de ingesloten opnamedatum, tenzij je weet dat deze in de camera verkeerd was. Bestandsdatums kunnen tijdens downloaden, exporteren, synchroniseren, kopiëren en herstellen gemakkelijk veranderen.
Als deze reparatie deel uitmaakt van een grotere opschoning van je thuisarchief, combineer je deze met een opslagbeleid waarbij onaangeroerde originelen gescheiden blijven van bewerkte of gerepareerde kopieën; dezelfde scheidingslogica helpt ook wanneer je retentie voor snapshotreplicatie voor een NAS-fotoshare plant.
Ondersteuning & Tips
Meer om te lezen

Opslaghandleiding voor live-tv-opnamen voor capaciteit, bewaartermijn en opruimen
Meet echte opnamen, houd hoofdruimte vrij, combineer limieten voor leeftijd en capaciteit en toon aan dat het oudste in aanmerking komende programma wordt verwijderd...

Workflow voor herstel van metadata van thuismedia na het terugzetten van een database
Bescherm de herstelde status, controleer de identiteit en paden van de media en herstel vervolgens ontbrekende artwork of overeenkomsten in een proeff bibliotheek voordat...

Compatibiliteitschecklist voor Jellyfin-clients voor audio, video en ondertiteling
Test representatieve bestanden één variabele tegelijk en noteer voor elke client Direct Play, remux, audioconversie, videotranscodering of fout.

