Add ability to import image exif data from the image.

[blistovmhz]

Looks like definitely pre-2010, and possibly other cases, images retained exif data in the jpg itself. Consequently immich-go can't find a corresponding JSON, and just ignores the file and doesn't import it.
It'd be nice if it'd check the image for exif first, or in combination with the json.

Is there currently any way to force this behaviour? Didn't see anything in the docs, nor in a cursory glance at the code. I've got about 1TB of images and roughly 20% are missing corresponding JSON, but so far all seem to have complete exif data.

[simulot]

Is this concerns the import of a google photos takeout archive?
What was the command line?

[blistovmhz]

Yes. This is attempting to import around 400GB from G Takeout.
What I'm finding is that takeout is missing a large number of JSON files as well as has a large number of JSON files that are not associated with any image. I think the latter represents JSON's for images that have been deleted at some point.

Regarding the former though, I haven't scripted a full proof yet, but I haven't been able to find any images in Takeout that do not have their EXIF in-tact. So while we're missing the associated JSON file, we seem to have MORE exif info in the jpg itself.
So 1. Images without accompanying json are not imported with immich-go (as far as I've seen).
2. I can't find a case where I NEED the JSON in the first place.

So the question is whether or not immich-go has an option to just use the images exif data and ignore missing JSON.

command:
./immich-go -server=https://immich.somehwere.net -key=somekey upload --create-albums -google-photos 002/Takeout/Google\ Photos/

There's substnatially more exif data in the images compared to the json anyway, so i feel like the JSON should only be used in this case, to retain album data.

[simulot]

It's likely that you have imported one part of a several part takeout archive. When the takeout archive is split, it happens that JSON and corresponding images are stored into another parts.

Immich-go is designed to process all parts in the same time, either by processing all zips (takeout*.zip), or processing the result of decompression and merge of all parts.

Immich-go need only the date of capture to match json / images and albums. However the immich-server use part of EXIF data to display the GPS coordinates.

The latest version of immich-go give an extensive log of process. A summary is given at the end. You will see how many files are duplicates, or not associated.

./immich-go -server=https://immich.somehwere.net/ -key=somekey -log-level=INFO -log-file=immich-go.log upload --create-albums -google-photos 002/Takeout/Google\ Photos/

Can you share the log file (the good parts)?

[blistovmhz]

This makes more sense. I've been doing one part at a time as otherwise I'll need a TB of storage to do the extraction and subsequent upload.

I'll give it a try. On that note, why does the script not deal with tgz?

[simulot]

What's not make sense is the google takeout file...
You can read the issue #36 for details.

You can give a try with a zip export.

[blistovmhz]

Take out only allows up to 2 GB zip files, and they don't seem to have any provision for downloading all of them at once or in sequence. So the download process is entirely manual and would take several days.
I'm extracting my existing TGZs, which are all technically slightly corrupt as well but of course Google doesn't provide any sort of hash for each file. As far as I can tell there's nothing actually missing, but it looks like they run out of memory during the compression phase and they don't write the EOF correctly.
So far though it's not looking like I'm missing any actual data.

[simulot]

I have the possibility to get 50GB zips. Not you?

[blistovmhz]

Nope. Max 2GB. I've never seen an option for more in the past.

[simulot]