Wat is supplemental-metadata.json in Google Takeout?
Dit bestand bewaart de datum, plaats en beschrijving van elke foto uit Google Foto's. Het is de naam uit 2024. Bewaar het tot die gegevens in de foto staan.
supplemental-metadata.json is het kleine tekstbestand dat Google Takeout naast elke foto en elke video zet. Er staat in wat Google Foto's van dat bestand wist: de opnamedatum, de GPS-locatie, het bijschrift en de oorspronkelijke bestandsnaam. Sinds 2024 is dit de naam van het sidecarbestand dat in oudere exports IMG_5512.HEIC.json heette. De inhoud is hetzelfde.
Bewaar het tot de datum en locatie in de foto zelf staan. De meeste foto-apps lezen het bestand nooit. Zonder die stap tonen je foto's dus de downloaddatum.
Misschien ben je hier omdat een script dat vroeger Takeout-exports repareerde nu de helft van je foto's overslaat. Of je zag IMG_5512.HEIC.supplemental-metadata.json naast de ene foto en PXL_20240311_183022711.jpg.supplemental-m.json naast een andere, en je vroeg je af of die tweede kapot is. Geen van beide is kapot. Hieronder lees je wat de namen betekenen, wat erin staat en wat je met de bestanden doet.
Wat "supplemental metadata" betekent
Metadata is informatie over een foto: wanneer, waar, met welke camera. "Supplemental" betekent aanvullend. Het gaat om de informatie die Google Foto's in zijn eigen database bewaarde, niet in het afbeeldingsbestand zelf.
Veel foto's hebben al een datum in zich, in hun EXIF-gegevens. Screenshots, afbeeldingen die je uit chats hebt opgeslagen, scans en elke foto waarvan je de datum of plaats in Google Foto's hebt aangepast, hebben dat niet. Voor die foto's is het sidecarbestand de enige plek waar staat wanneer en waar ze gemaakt zijn. Meer achtergrond vind je in Wat zijn de .json-bestanden in Google Takeout?.
Wat staat er in het bestand?
Open er een in Kladblok, TextEdit of een code-editor. Het is gewone tekst. Dit zijn de velden die ertoe doen:
title: de oorspronkelijke bestandsnaam. Handig als Takeout de echte bestandsnaam heeft ingekort.photoTakenTime: de opnamedatum zoals Google Foto's die toonde. Een datum die je zelf hebt aangepast, zit hier ook in. Dit is de datum die je wilt gebruiken.creationTime: het moment waarop het bestand naar Google werd geüpload. Bij een scan van een oude afdruk kan dat tientallen jaren na de echte datum zijn.geoData: de locatie zoals Google Foto's die kende, ook een plaats die je zelf hebt ingesteld.geoDataExif: de locatie die bij het uploaden in de eigen EXIF van het bestand stond.description: je bijschrift, als je er een hebt getypt.peopleenfavorited: getagde namen en foto's met een ster, als die er zijn.
De tijdstempels zijn seconden sinds 1 januari 1970, in UTC. Een foto zonder locatie heeft 0.0 als breedte- en lengtegraad. Lees dat als "geen locatie", niet als een echte plek. Zie restoring GPS from Takeout (Engels).
Waarom de naam in 2024 veranderde
Jarenlang heette het sidecarbestand van IMG_5512.HEIC gewoon IMG_5512.HEIC.json. Fotonaam, dan .json. Elk script zocht daarop.
In 2024 stapte Google over op IMG_5512.HEIC.supplemental-metadata.json. Zelfde inhoud, zelfde velden, langere naam. De nieuwe naam zegt wat het bestand is, in plaats van een kale .json die je voor de eigen gegevens van de foto zou kunnen houden. Exports sindsdien gebruiken de nieuwe naam. Een oude export op een schijf gebruikt de oude, en een map waarin beide exports samenkomen, bevat beide.
Alles wat zoekt naar <foto>.json vindt nu niets en gaat door. Sommige tools melden voor elk bestand "geen sidecar gevonden". Andere vallen stil terug op de bestandsdatum, en dat is de downloaddatum. De foto's krijgen dan de verkeerde datum, zonder foutmelding. Dat stille falen zit achter veel berichten van het soort "de oplossing werkte niet".
Waarom sommige namen zijn afgekapt, zoals .supplemental-m.json
Google kort de volledige naam van het sidecarbestand in tot 46 tekens. Met het oude korte .json maakte dat zelden uit. Met .supplemental-metadata.json erachter verliest elke fotonaam van meer dan ongeveer 19 tekens een deel van de extensie.
Een Pixel-foto met de naam PXL_20240311_183022711.jpg telt 26 tekens. Met .supplemental-metadata.json erbij worden dat er 53. Google kort in tot 46: PXL_20240311_183022711.jpg.supplemental-m.json. Een Samsung-foto 20240311_183022.jpg krijgt 20240311_183022.jpg.supplemental-metada.json. Elk cameramerk geeft een net iets andere afkapping, dus er is geen vaste extensie om op te zoeken.
Het bestand is niet beschadigd. Alleen de naam is korter. De betrouwbare regel: de naam van het sidecarbestand is het begin van <fotonaam>.supplemental-metadata.json. Een script moet dat controleren, en geen vaste tekst vergelijken. Heel lange oorspronkelijke bestandsnamen, bijvoorbeeld namen die je zelf hebt getypt, kunnen tot in de fotonaam zelf worden afgekapt. Daarom is het veld title in het sidecarbestand de moeite waard. Why Takeout files have strange names (Engels) zet alle naamregels op een rij.
Waar de (1) terechtkomt
Google Foto's staat twee bestanden met dezelfde naam toe, en Takeout moet ze in één map zetten. Het tweede bestand krijgt een teller: IMG_5512.HEIC en IMG_5512(1).HEIC.
Je zou verwachten dat de sidecarbestanden IMG_5512.HEIC.supplemental-metadata.json en IMG_5512(1).HEIC.supplemental-metadata.json heten. Dat is niet zo. De teller schuift naar het einde van de sidecarnaam, vlak voor .json: IMG_5512.HEIC.supplemental-metadata(1).json. In de oude stijl was het IMG_5512.HEIC(1).json.
Een tool moet dus de fotonaam nemen, de (1) weghalen, de sidecarnaam opbouwen en de (1) vlak voor .json terugzetten. Combineer dat met de afkapping op 46 tekens en je krijgt namen als PXL_20240311_183022711.jpg.supplemental-(1).json. Echte exports bevatten zulke namen.
Tellers komen vaak voor. Dezelfde foto in twee albums, een bewerkte foto waarvan Google beide versies bewaarde, of twee telefoons die allebei een bestand IMG_0001.JPG noemden: ze leveren allemaal tellers op.
Bewerkte kopieën hebben geen eigen sidecarbestand
Foto's die je in Google Foto's hebt bewerkt, komen eruit als twee bestanden: IMG_5512.HEIC en IMG_5512-edited.HEIC. Meestal is er één sidecarbestand, en dat hoort bij de oorspronkelijke naam. Een eenvoudige tool laat de bewerkte kopie zonder datum. Een zorgvuldige tool haalt -edited weg en gebruikt het sidecarbestand van het origineel opnieuw. Meer daarover in Takeout duplicates and edited versions (Engels).
Mag ik supplemental-metadata.json verwijderen?
Ja, maar pas als de datum en locatie in de foto staan. Verwijder je de bestanden eerder, dan is die informatie weg. Je foto's houden de downloaddatum, en de enige weg terug is een nieuwe Takeout-export.
De veilige volgorde: zet de gegevens in de foto's, controleer een paar foto's en verwijder daarna pas de .json-bestanden. Importeer je in Immich of PhotoPrism, bewaar ze dan tot die import klaar is, want die tools kunnen de sidecarbestanden lezen. Het korte antwoord staat in Mag je de .json-bestanden van Google Takeout verwijderen?.
Welke apps lezen het?
Apple Foto's, Windows en de galerij op je telefoon niet. Die kijken alleen in het afbeeldingsbestand zelf. Google Foto's leest het ook niet als je de map opnieuw uploadt. Immich, PhotoPrism en een paar andere zelf gehoste tools kunnen de sidecarbestanden van Takeout lezen tijdens het importeren. Voor elke andere bestemming zet je de gegevens eerst in de foto.
Zo zet je de gegevens terug in de foto
De gegevens uit het sidecarbestand in de EXIF van de foto schrijven heet samenvoegen. Met exiftool doe je dat twee keer, één keer per extensie:
exiftool -r -d %s -tagsfromfile "%d/%F.supplemental-metadata.json" "-DateTimeOriginal<PhotoTakenTimeTimestamp" -ext jpg -ext heic -overwrite_original .
exiftool -r -d %s -tagsfromfile "%d/%F.json" "-DateTimeOriginal<PhotoTakenTimeTimestamp" -ext jpg -ext heic -overwrite_original .Kijk daarna met exiftool -r -if 'not $DateTimeOriginal' -filename . welke foto's nog geen datum hebben. Wat overblijft, zijn de afgekapte namen en de (1)-gevallen. De eenvoudigste oplossing: hernoem die sidecarbestanden met een kort script naar de volledige verwachte naam en draai exiftool opnieuw. De volledige uitleg, met GPS en video's, staat in Google Takeout-json in je foto's zetten en in de exiftool-handleiding.
GooglePhotosTakeoutHelper, een gratis tool uit de community, heeft deze koppeling ingebouwd en is de gebruikelijke keuze als je je thuis voelt in een terminal. Nieuwe versies lopen soms achter op de wijzigingen van Google. Kijk dus in de issue tracker als een run bestanden overslaat.
De app
Takeout JSON Metadata Fixer regelt al deze gevallen zonder instellingen, op macOS, Windows en Linux.
Voor elke foto probeert de app de naam uit 2024, de oude naam, de verschoven (1)-teller en ten slotte elk .json-bestand in de map waarvan de naam het begin is van de volledige verwachte naam. Bewerkte kopieën lenen het sidecarbestand van het origineel. Daarna schrijft de app de datum en GPS in het bestand. Aan het eind meldt ze hoeveel foto's een sidecarbestand hadden en hoeveel terugvielen op EXIF of de bestandsdatum. Zo zie je of de koppeling gelukt is voordat je iets verwijdert. Een proefrun toont het plan zonder iets te schrijven. De eerste 1000 foto's zijn gratis.
Veelgestelde vragen
Is de inhoud van supplemental-metadata.json anders dan die van de oude .json?
Nee. De velden zijn dezelfde: title, photoTakenTime, creationTime, geoData, geoDataExif enzovoort. Alleen de bestandsnaam is veranderd.
Mijn foto heeft helemaal geen sidecarbestand. Hoe kan dat?
De videoclips van Live Photos hebben er vaak geen. Sommige heel oude uploads ook niet. En als een sidecarbestand is afgekapt of een verschoven teller heeft, meldt je tool het misschien als ontbrekend terwijl het er wel is. Kijk zelf in de map. Why some photos have no JSON file (Engels) zet de gebruikelijke oorzaken op een rij.
Is het bestand een virus of spyware?
Nee. Het is een gewoon tekstbestand dat Google in je eigen export zet. Er zit geen programmacode in.
Kan ik de sidecarbestanden terug hernoemen naar de oude stijl?
Ja, en dan werken oude scripts weer. Een hernoeming die .supplemental-metadata weghaalt en de (1) terugzet in het fotodeel van de naam, is genoeg. Doe het eerst op een kopie.
Verandert Google de naam nog eens?
Misschien. De veilige aanpak voor elke tool is koppelen op het begin van de naam en op het veld title, niet op een exacte extensie.