support livp photos

[oldwang12]

Uploading photos in the format of livp through the iOS immich app will result in an error on the server.

[Nest] 1  - 04/08/2024, 1:22:53 PM   ERROR [AssetService] Unsupported file type IMG_4372.livp

I found that the code does not have the livp format here. Can you add the livp format here?

[mmomjian]

This PR is not complete - at a minimum it needs to be added to the spec.ts file as well.

what testing have you done to confirm that the image libraries used in Immich support LIVP?

[alextran1502]

Hello, thank you for the PR! Have you tested that the file is supported, i.e., the thumbnail gets generated and metadata is read correctly?

[mertalev]

The livp format is apparently an archive containing a JPEG and a MOV file. This would require more than just adding it to the list.

[SandiyosDev]

Some useful links for developing .LIVP support:

• Open Pull Requests: Keep track of .LIVP-related developments here: Nextcloud Viewer Issue #2059
• Existing Implementations:
  • livp2jpg
  • livp2png
  • unziplivp
• PhotoPrism Discussion: Check how PhotoPrism is dealing with this issue: PhotoPrism Issue #2312

I believe a simple handler could be developed to extract these files, generate previews, catalog EXIF data, and perhaps include conversion features in the future. The above references should be helpful for anyone interested in working on this.

[SandiyosDev]

If any maintainers would like to assist me in working on this, please reference the right files and add potential boilerplates so I could try implementing this filetype on my end.
It would be a good starter for me to get familiar with the codebase.

[mertalev]

Thanks for offering to help! The most relevant file is the metadata service.

We handle something similar for motion photos: the video is embedded into the image so we extract it as a new asset and link the two.

But there's an additional wrinkle in this case since the image portion also needs to be extracted. Every image and every video is its own asset, so thumbnail generation assumes the originalPath can be directly read, storage template can move that asset, etc. We could create a new asset for the image portion, link that to the video portion and hide the livp asset.

[SandiyosDev]

Thanks for offering to help! The most relevant file is the metadata service.

We handle something similar for motion photos: the video is embedded into the image so we extract it as a new asset and link the two.

But there's an additional wrinkle in this case since the image portion also needs to be extracted. Every image and every video is its own asset, so thumbnail generation assumes the originalPath can be directly read, storage template can move that asset, etc. We could create a new asset for the image portion, link that to the video portion and hide the livp asset.

I think my scenario is an edge case. I primarily bind mount external libraries and use Immich for cataloging and remote access. So, in my mind, automatically, I went with the route of extracting assets, cataloging info, generating previews, deleting the extracted assets, and linking the previews and metadata to the original. However, I'm less familiar with the process for directly imported files and the specific code that handles them.

Ideally, I'd prefer .LIVP files to be handled as-is upon upload, without converting them into new assets. But I'm unclear on which part of the codebase deals with this or the standard procedures for managing new file types like this. Could you point me to a previous pull request or any documentation that discusses how similar cases have been handled? This would really help me figure out the best approach

@mertalev

[SandiyosDev]

Also, I believe .photoasset can be treated the same way as .LIVP

[mertalev]

This PR is probably the most closely related.

We generally try to minimize the number of "special cases" to make job processing cleaner and more robust, so this is why I suggested making separate assets for the image and video. Using the livp asset as the image portion would have implications in other jobs as well as for things like asset serving.

@jrasm91 has the most context on live/motion photos, so they might have more thoughts on this.

[SandiyosDev]

he previews and metadata to the original. However, I'm less familiar with the process for directly imported files and the

Thanks @mertalev, that helps a lot!
While I'm waiting for his response, how should external libraries with LIVP be treated then? does that follow the earlier linking process that I mentioned, or is there also a pull reference for those cases?
Perhaps it would belong to #8721 instead?

[mertalev]

The extracted videos for motion photos are put in the encoded-videos folder, separate from the external library. #8512 is a recent PR related to this that was later split up. I imagine it'd be similar in this case except that the image would go in the thumbs folder.

[mertalev]

Closing this PR since it doesn't address the actual implementation needed to support this format.