Used immich-go for this too. Had no problems, and the dev is really open to feedback. All the metadata was there (except for labeled persons), and albums were also created correctly. It even inported archived photos into Immich’s archive!
Jumping in to second immich-go, just used it recently. I had no issues other than Google Photos not giving me the data for shared albums (most of mine), which seems to be a Google Takeout issue.
To answer my own Q, yes, anything shared by others with you isn’t in the takeout backup. You have to go to each such album and do Download All. Then you can import it with immich-go with the correct album name. If you already have that album, it will just add the missing content to it.
If you import it as external library, Immich will not be able to modify or delete any of the files, but you will see the files just like you see ones uploaded using immich. It is up to you to decide what is better
A couple years ago, Google decided that instead of exporting the photos with EXIF data exactly as you’ve uploaded them, which was the original behavior and how platforms such as OneDrive do it, they are going to completely delete all EXIF from the image and instead also create a .json containing the original data, in a non-standard format. This script is an open and free version of a paid tool that goes through each image, finds the corresponding .json, and puts the EXIF data back on.
If you don’t do that, when you reupload these photos into a new service, the date will be reverted to the day you’ve downloaded them and location data will be missing entirely.
Google reminds me more and more of Microsoft of the 90s. That’s exactly the kind of compatibility breaking asinine move MS would do 30 years ago. Sigh…
Yes! I imported 23k media files into a new platform, and the takeout process was such a pain. My destination was built to handle the zipped or unzipped media, but occasionally issues cropped up,like when files spanned archives but the json was on the previous one. That resulted in orphaned files with upload dates instead of date taken.
Ultimately, I think I had the best experience extracting all 123GB and uploading the albums/folders that way.
Would have been SO much easier with an API that allowed cloud to cloud.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
Used immich-go for this too. Had no problems, and the dev is really open to feedback. All the metadata was there (except for labeled persons), and albums were also created correctly. It even inported archived photos into Immich’s archive!
Immich-go is stupid easy.
Just dump all your takeout zips in the same folder as immich-go and run the import. Lmk if you need help.
It ingested 60+ zips with 100gb of photos when I used it.
Jumping in to second immich-go, just used it recently. I had no issues other than Google Photos not giving me the data for shared albums (most of mine), which seems to be a Google Takeout issue.
deleted by creator
Could you elaborate, what shared albums? Shared with you? Are you referring to this problem?
To answer my own Q, yes, anything shared by others with you isn’t in the takeout backup. You have to go to each such album and do Download All. Then you can import it with immich-go with the correct album name. If you already have that album, it will just add the missing content to it.
Does it properly handle takeouts exif data?
Yes.
If you import it as external library, Immich will not be able to modify or delete any of the files, but you will see the files just like you see ones uploaded using immich. It is up to you to decide what is better
I recommend using this: https://github.com/TheLastGimbus/GooglePhotosTakeoutHelper
A couple years ago, Google decided that instead of exporting the photos with EXIF data exactly as you’ve uploaded them, which was the original behavior and how platforms such as OneDrive do it, they are going to completely delete all EXIF from the image and instead also create a .json containing the original data, in a non-standard format. This script is an open and free version of a paid tool that goes through each image, finds the corresponding .json, and puts the EXIF data back on.
If you don’t do that, when you reupload these photos into a new service, the date will be reverted to the day you’ve downloaded them and location data will be missing entirely.
Google reminds me more and more of Microsoft of the 90s. That’s exactly the kind of compatibility breaking asinine move MS would do 30 years ago. Sigh…
Yes! I imported 23k media files into a new platform, and the takeout process was such a pain. My destination was built to handle the zipped or unzipped media, but occasionally issues cropped up,like when files spanned archives but the json was on the previous one. That resulted in orphaned files with upload dates instead of date taken.
Ultimately, I think I had the best experience extracting all 123GB and uploading the albums/folders that way.
Would have been SO much easier with an API that allowed cloud to cloud.
I wonder if this is worth doing even if I import with
immich-gowhich seems to combine this data too.This was the tool I used. It worked great for me.
Very shitty of them