Standalone operation

[evrial]

Immich recently supports external library, there is little need to operate via API. I'd simply use it as takeout archive processor with output path, is that possible?

[simulot]

Immich-go currently focuses on importing photos into immich internal library using immich's API.

However your request is valid. Simply unzipping the Google Photos takeout archive into the external library path wouldn't capture the valuable metadata included in JSON files.

To address this, I propose the following approach:

1. Customizable Destination in the external library: Allow users to customize the destination of photos within the library to suit their preferences.
2. Original Filename: Use the original filenames retrieved from the JSON data to name the files in the library.
3. Collision Avoidance: Implement mechanisms to prevent filename collisions with existing files.
4. Sidecar File: Create sidecar files containing the date of capture and GPS coordinates extracted from the JSON data.
5. Dedicated Google Photo Library: Explore the possibility of creating a separate library specifically for Google Photos imports, leveraging Immich's support for multiple external libraries.
   6. Two-Pass Processing: After copying all files, initiate the "library" job within Immich. Information that requires API interaction beyond simple file placement can be updated using the API in a separate pass.

Please share any comments or suggestions you may have on this approach.

[evrial]

I think it is a valid reason to split the functionality into two executables, One dedicated for takeout archive preprocessing and other for immich API. I wish to have full control of structure of files and albums with dates before files are sent to server. This tool is valuable without immich.

[simulot]

How you would like to have the result?

[evrial]

Albums as folders and Uncategorized folder/album with original filenames/timestamp they were uploaded. Each photo may have 0 or more albums so I wish to use fdupes for sanitizing.

[simulot]

Albums folders often (not al the time) contain a copy of the file that exists in the Year folder. fdupes will detect them. What do you will do of this information? Discard one copy?

immich doesn't check external library file's hashes. If you keep the copy, you'll get duplicates photos.

Could you explain your photo workflow?

[evrial]

I wish to use other galleries besides immich and this tool provides the best data integrity from Google takeout metadata json. That's why I'm asking for standalone option.

[Chaphasilor]

I mean immich-go supports importing regular directories into Immich, so it seems reasonable to add one mode (maybe a subcommand) that parses and extracts the google photos archive into a new directory structure, that can then later be imported using immich-go (if needed). The existing mode could be kept unchanged, and the new mode won't be as integrated with Immich, but that seems like a good tradeoff?

[simulot]

I agree. This could be an intermediary step to import photos into another photo manager, or a legacy system.

I would like to do correctly to not lose information carried by the takeout structure and json files:

• Date and GPS. Easy -> xmp files
• Albums --> beware of missing or duplicates photos because of albums
• Photos having the same name, but different, like iphone photos

What would be the ideal structure to support this?

[evrial]

Ideally all data should be in exif and mtime just like you copied them from phone. Thats 99% of work, the rest can be shell scripted. Messed up dates are the worst.