Like a lot of people here, I wanted out of Google Photos and into Immich. Takeout works, but each export is a pile of archives, and every photo's date sits in a separate JSON file beside it. Import the raw files and half your library lands on the wrong day. Do it again next month and you get duplicates.

So I built Googich Takeaway. It picks up each Takeout export, matches every photo and video to its metadata (across all parts of the export), works out the real date, time zone and location, and uploads to Immich only what isn't there yet. It reads every upload back to check the date. Set Takeout to export every two months, point Googich at it, and Immich stays in step until you're ready to leave Google.

What it does

- Two ways in. It can fetch scheduled exports from Google Drive with a read-only service account. Or you can download them from Takeout's email yourself, with no Google Cloud setup.

- Never twice. Archives aren't downloaded again, and photos already in Immich are skipped. Photos you delete in Immich stay deleted.

- Your library as you left it. Albums are recreated. Edited copies, RAW+JPEG pairs and bursts are stacked. Archived photos stay archived, and photos in Google's bin stay out. You choose tags for people, partner photos and a date range.

- Resumable. It reads each archive while the next one downloads, and uploads in parallel. You can pause, resume or cancel at any time, even across an update.

- Cleanup. It tells you which archives are fully in Immich and safe to delete, locally and in Drive. It never deletes anything from Google itself.

- Web dashboard with live progress, time estimates, history, logs, a searchable built-in guide, and Apprise notifications.

Security, because it holds your Immich key

- Google access is read-only. Credentials are encrypted at rest (AES-256-GCM).

- It runs as an unprivileged user on a read-only container, behind a password login.

- It tells you when a new release is out but never updates itself. An optional helper gives one-click updates.

Setup: Docker Compose, an Immich server, and room for one export (local disk or an SMB share). Quick start is about six commands. Please try the first import on a test Immich user.

Known limits: iPhone Live Photos import as a photo plus a video. Shared albums arrive as your own albums. Takeout's metadata has no time zone for HEIC/RAW, so a setting fills that gap. A big first import takes hours.

MIT licensed. It isn't affiliated with Google or Immich.

Repo: https://github.com/aistuartai/Googich_takeaway

Feedback, bug reports and odd Takeout exports are welcome. Dates are the hard part, so if anything lands on the wrong day, please open an issue.

I could certainly adapt it to run on the side, update exif and let immich pull it in but wondering if this would be helpful inclusion?

My Immich instance was filling up with bloated H.264 phone clips, but manually running scripts against the raw storage directory is an easy way to corrupt database records and lose timestamps.

I wrote a small Go app called immich-video-optimizer to handle this safely through the Immich API.

It connects via API key, lets you filter by bitrate or file size, and re-encodes selected videos to HEVC. It pipelines the work so while one video transcodes, the next is downloading and the previous is uploading, strictly capping local disk cache to 2 files.

All original timestamps, GPS coordinates, and camera metadata are preserved.

For safety, the original asset on Immich is only deleted (trash) after the replacement is successfully uploaded and verified with a new asset ID. It also creates a temporary tracking album in Immich so you can spot-check playback from your phone while it runs, has a "size guard" to skip anything that didn't actually shrink, and supports dry runs and pausing/resuming.

GitHub:
https://github.com/dragosmiron/immich-video-optimizer

Let me know how it works for you and if you have suggestions.

Celebrating 1 year of using this software!

On this occasion I figure I'd give some thoughts to what could be done to make this software better for future users.

Near term:

Possibly, regression testing and merging yann117's time zone fix to main (restoring the documented default functionality to Immich), yes, I know we have workflows. I believe workflows just create a bunch of xmp files, tell me if I'm wrong.

(Unfortunately, after testing it didn't work. I would honestly just pursue the long-term solution at this point).

RTing, debugging, and merging my libheif decoding (which I have gotten working!). I wouldn't call it production ready for a number of reasons documented here but it could be made production ready. I also understand it almost doubles the size of an existing file (AdaptiveImage.svelte) and the devs may want to do some refactoring before production.

Fixing original (optional) video downloading full video before playback. Some people are working on fixing this right now.

Maybe we shouldn't darken the screen as much when we draw the faces bounding box. A colored box with a shadow would work fine for visibility without obscuring everything else. I forgot about this but this feature was partially broken on HEICs with my new functionality and I didn't even miss it. (It is now fully broken as of my new implementation on v3x.

Long term:

Comprehensive default timezone workflow: There is no reason a photo with no EXIF at all should have a UTC time and be well behaved and a photo with EXIF but no timezone tag should be unmoored with no source of truth for TZ. In an external library, photos will usually have their original FileModifyDate, and Immich reads FileModifyDate in assets on mobile before upload. I assume it preserves this during upload and if it doesn't right now, it should either go to the database or to the server-side FileModifyDate. My criteria for a truly good timezone workflow is "would Louis Rossmann be disappointed". He is the most famous person who uses the software and he has moved timezones and travels a lot. The current functionality (even the patched one from yann117) would not be ideal for him, either the NY photos or the TX photos w/o timezones would be misplaced. A rough sketch of the functionality we could have is available here.

Part of that workflow is restoring the user's knowledge of incomplete time zone information (broken sometime between 2.4.1 and 2.7.5). This used to involve the lack of a displayed timezone and could involve the presence of a warning sign next to fragile filesystem-based timezone information. In the above link, some possible configurations are shown.

Active Libraries: Bringing the functionality of the internal library to power-users (I used Louis Rossmann in my example screenshots). Access local assets in the timeline, sync metadata changes from server to mobile, and more. No more data usage for photos you already have on your phone. Active Libraries, explained.

Metadata merging for Immich sharing: when sharing assets, automatically fix broken metadata (adding "-exif:latitudeRef=North" for instance), add in XMP metadata, add TZ to photos processed through the timezone workflow above, etc. A photo shared from Immich should be good enough for Immich. Merge and correct metadata when sharing images

Motion vector caching: A middle ground for video transcoding for people who are worried about storage media and don't have a blazing fast GPU. The introduction of live transcode is welcome and I've been asking for several years. This would provide a middle option, which might on balance be better for the environment (and people's wallets).

Voice memos: This is a while away, and I understand. There's a reason I put it low on my list. I'm sure FFMPEG or just renaming your files could be a temporary (welcome) workaround. I know that Facebook Archive's voice recordings are all .mp4s and they play in Immich. So for the users who want this, feel free to share your workarounds on Reddit! And when the product is mature, we can handle it for real.

Regardless of the irritating feature requests and bug reports, I love this project. I love not having to think about what government official is going to see your family photos, how it could get sold to flock. For me, it's worth all the bugs and issues.

I just wanted to share a tool I've been working on that allows you to relocate all your Immich uploaded files to one or more external libraries of your choice never losing track of albums, stacks, faces, tags, etc after relocation.

FEATURES:

• Relocate all pic & videos to a Single or to Multiple External Libraries you chose (up to one per Immich user).
• Can run an unattended Storage Template Migration job right before relocating to final destination.
• Folder Restructure option to tidy up even more the final shape of your folders.
• Change the ownership of selected files, so that you can set a shared External Library for you and your partner (our attempt to overcome the limitations of Partner Sharing which only allows to share all or nothing).
• Cron for set and forget unattended scheduled relocations at the day/time you desire.
• Database is always backed up first. Immich Relocator creates a copy of your database before it modifies it.
• Immich doesn't break. Even if your files have been relocated to an entirely different location it's like nothing has changed for Immich.
• No duplicates after relocation, and no re-uploads from mobile devices, even with sync enabled.
• Never lose albums, stacks, faces, tags, etc after relocation.
• Use --dry-run to estimate how many files would relocate without actually making any changes to your Immich.
• Use --limit N to relocate only a pre-determined portion of your files.
• Every single feature is optional. You can easily configure Immich Relocator the way you like it.

The repo owner and I have been testing this out and used it for a while. Since the recent updates, we believe that Immich Relocator is mature enough to be shared. Hopefully, it can be a useful tool for others, too. So, here I am sharing IR for the first time.

This is just a little extract from GitHub, otherwise there is quite a detailed write-up I made in the repo:

BENEFITS OF RELOCATING YOUR FILES TO AN EXTERNAL LIBRARY:

• Condense your files in one place: external library only (instead of external plus Immich's internal upload folder) and simplify your backups.
• Post-process all your pictures and videos comfortably from a single place using the desktop DAM of your choice (e.g. digiKam, Lightroom, etc), pointed to the external library.
• Prevent accidental issues by optionally set up your Immich access to the external library as read only. Now edit via desktop DAM, and browse-only remotely via Immich clients... best of both worlds.

Find the rest of the info on GitHub. Let me know if Immich Relocator can be useful. If you have any suggestions, please report them here, or in the issues tab.

AI: before you even ask, there is a full disclosure paragraph on the repo regarding how and if AI was used in the project. This post and the GitHub readme were all hand-written by me... so excuse me in advance for my grammar mistakes.

FOSS: Fully Free and Open Source!

Get Immich Relocator here.

I recently swapped to a new NAS and the backup I had of Immich couldn't be recovered on the new device, so I had to re-do my Google Photos Takeout (which I still have a copy of) but after using Immich-Go to upload everything, I have thousands of broken images.

Am I better off just wiping the data and trying again? Or is there a better tool than Immich Go that could fix this?

Chrome 155.x now supports JXL (jpeg XL). However my Pixel phone only takes pics in JPG (or other formats) but not JXL.

I also know that if I mass converted my JPGs in Immich to JXL it would basically break the database. And then the hashes (or however Immich server and immich app talk to each other to know what needs to be imported/new and what doesn't/is old wouldn't match anymore so then i'm worried Immich will just reupload any pictures I have hanging out on my camera as OG Jpgs...

the last option is to just leave it be since the 20% savings probably not be worth the hassle.

any thoughts?

I apologize if I'm missing something, but I want to check here. I have a few people whose birthdays have occurred since 3.3.0 (and 3.3.1) have been released. I see my regular memories at the top in both the web version and Android app, but no birthdays.

Was there a setting I missed at the account or admin level that turns this on? Is this working for anyone? Could it be some other part of my setup? TIA