iOS Live Photo Support?
matthewpritchett opened this issue · comments
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
Hey, as I don't use iOS, could you provide some example files I could use to test this?
It would be also cool to support other live photo implementations (Galaxy, Pixel, ...)
Here's a live photo example file:
IMG_3353.HEIC.zip
Here's a normal HEIC file (not live photo):
IMG_6741.heic.zip
Here's a iphone video (.mov) file:
IMG_1768.MOV.zip
and here's a gif file:
IMG_6881.GIF.zip
Hope that helps.
Thanks a lot! That'll help for sure yeah :)
Hi Miha @SmilyOrg just came around to see if you have given this any more thought? (in terms of supporting the above formats)
Not on live photos specifically, however when I get some more time I should merge in imagemagick support. It would add support for all static image formats imagemagick supports, including HEIC.
Live photos and animated gifs would need extra integration across the whole stack, but I imagine them working a bit like videos do now.
Doubly so for mov files, if your browser doesn't support them natively (do any? except maybe Safari?), it would require transcoding, which is a whole 'nother can of worms I'm not willing to open just yet. My feeling is that there are more fundamental issues to fix first :)
Any more thoughts on your side?
Ah, forgot to mention, but the reason I haven't merged the imagemagick support yet is that it's kind of slow and resource intensive, so not an amazing experience. But maybe having it work at all is better than not supporting those formats in the first place.
Totally agree! It is all incremental in nature - Static is the least complicated and then as you go towards live/gif/mov it will get more complicated and resource intensive in any case.
After that it becomes a gain vs loss exercise for each user and you could even make all of it optional via config for users who value speed/performance over all the different formats.
I am a big proponent of building things incrementally so totally makes sense to do static files first (like HEIC) and is the biggest impact in any case as all iphone users will end up needing that. (I believe even live photos are heic in essence and could display the static version of heic once static heic is supported)
Beyond that and incrementally building it - you could even start by just adding placeholder img/links for non native formats that only play in Safari for users who can just click the placeholder and play it without the additional overhead of transcoding it to support other browsers (e.g. If I am a user uploading an ios live photo, I most likely have access to safari and/or would end up playing it in safari anyway).