-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iOS Live Photo Support? #52
Comments
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: Here's a normal HEIC file (not live photo): Here's a iphone video (.mov) file: and here's a gif file: 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. 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). |
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.
The text was updated successfully, but these errors were encountered: