[digikam] [Bug 385726] Add Support For Apple Live Photos (HEIF)
https://bugs.kde.org/show_bug.cgi?id=385726 --- Comment #35 from Glassed Silver --- (In reply to caulier.gilles from comment #31) > About Apple Live Photo, Samsung's Motion Photos, and Huawei's Moving > Picture, i'm not sure where the differences are located. > > I'm sure that Apple Live Photo is HEIF based. > > in all cases libheif must support these format to access to image and video > data in container. About metadata, libexiv2 will support Base Media Format > (HEIF and AVIF containers) with next 0.27.4 release planed for June 2021. Modern implementations yes, but before Apple adopted HEIF Live Photos existed as well and there's plenty of JPEG-based Live Photo backlog that would be in I bet many users' libraries. :) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385726] Add Support For Apple Live Photos (HEIF)
https://bugs.kde.org/show_bug.cgi?id=385726 --- Comment #30 from Glassed Silver --- Just checked the release notes for 7.2 and noticed that Apple Live Photo Support has been scheduled for 7.4, which is fantastic! I have one question though, are competing, similar formats like Samsung's Motion Photos, Huawei's Moving Picture and possibly other contenders that may be relevant in later feedback still on track for release as well? Personally for my own needs I am using Apple and Samsung's formats, so those would be my main concern, but Huawei is also pretty popularly used. Not sure what other manufacturers put out there, but having Apple, Huawei, Google and Samsung included would cover a large share of the market. Photo enthusiasts with mobile device choices around their creative needs may even go for some other brands, but I'm pretty sure those need not be the focus for now and could get added once the main share of the market is implemented and has gone through some wider trialing in the field I guess? Also, if desired I could add a new Samsung Motion Photo sample taken with a newer device (Note20 Ultra) just in case there are alterations to Samsung's implementation. (doubt it, but I want to be as assisting in this implementation as possible and providing samples is something I can do pretty nicely as someone who doesn't develop themselves) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385726] Add Support For Apple Live Photos (HEIF)
https://bugs.kde.org/show_bug.cgi?id=385726 --- Comment #28 from Glassed Silver --- (In reply to caulier.gilles from comment #27) > Don't be afraid. HEIF and CR3 support are popular format, and Bugzilla is > here to remember the important entry (you can vote for this support here > too). > > HEIF is Android and Apple used format -> very popular > CR3 is Canon RAW file -> a major actor in photography. > > So... > > Gilles Caulier Well, I'm a CR2 user thanks to my 60D, I know it's pretty much inevitable a solution will be found. HEIF isn't just Apple and Android though, I think in the future demand for it will rise quite a bit more, because it does provide substantial space savings which can be applied elsewhere too. Oh also I wanted to let you know that I've donated to Digikam a few days ago because seeing the Live Photo format getting picked up alerted me to help out a bit myself. When this issue gets resolved I'll be looking at weeks if not months of carefully moving data to Digikam and trialing productive use with a large library. Finally a home for my photography and videoclips again. Much love from Germany! :) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385726] Add Support For Apple Live Photos (HEIF)
https://bugs.kde.org/show_bug.cgi?id=385726 --- Comment #26 from Glassed Silver --- Thank you so much for your input. I wasn't trying to advocate for a work-around, I was just trying to make sense of why you're optimistic, since this seems like it could go either way over at that project. At least from what I read regarding the potential legal implications. I gave the OP post a thumbs up, I guess that's what you meant by voting for it. Again thank you so much and I'll just adopt your hopefulness and anticipate the release, hopefully with CR3 and HEIC metadata support. I guess one way or another a way has to be found either way eventually, so if I don't completely misinterpret this, if the feature doesn't make it into 7.0, hope wouldn't be completely lost? Cheers! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385726] Add Support For Apple Live Photos (HEIF)
https://bugs.kde.org/show_bug.cgi?id=385726 --- Comment #24 from Glassed Silver --- (In reply to caulier.gilles from comment #23) > yes, HEIF is supported in digiKam 7.0.0 right now, but not yet the video > embeded. > > The problem is with Exiv2 which refuse to support HEIF due to possible > patents. > > If HEIF will host video, we will need to be able to extract this data, and > Exiv2 sound like the best way to operate. > > > The problem between HEIF and EXiv2 do not touch only HEIF, but all formats > based on ISO base media format: > > https://en.wikipedia.org/wiki/ISO/IEC_base_media_file_format > > This include also the famous Canon CR3 raw files, and it's very problematic > for the future... > > https://github.com/Exiv2/exiv2/issues/236 > > So we need to have a plain support of ISO/IEC 14496-12 format first before > to support extra video from this kind of container... > > Gilles Caulier Maybe I'm missing something here, but if we rely on a third-party dependency to resolve this and they don't release a solution in code before July (and even that isn't certain) how can you be sure that this feature is on track for 7.0 final scheduled to release on or around July 12? Do you have an intermediary workaround in mind to use until this gets resolved? Thanks for the wealth of background info as well! Very interesting to see this unfold and at the same time I cannot stop but cry over software patents being a thing... ESPECIALLY for things like file formats. Real innovation stifling at work... -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385726] Add Support For Apple Live Photos
https://bugs.kde.org/show_bug.cgi?id=385726 --- Comment #22 from Glassed Silver --- (In reply to caulier.gilles from comment #21) > Thanks Ritesh. I will take a look. > > Gilles Caulier Forgive me if I may come across as impatient, I am just very thankful for finally being close to getting the long awaited Aperture replacement... (yep... I held out this long!) My question is: is this feature still on track for 7.0 final? Again, thank you so so much for even getting on this, bridging the different kinds of live photo-like implementations no less. I really think it's a very transformative format of our time and I cannot tell you how often I've been enjoying the little bit of extra life Live Photos and similar approaches have brought to me. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385726] Add Support For Apple Live Photos
https://bugs.kde.org/show_bug.cgi?id=385726 --- Comment #17 from Glassed Silver --- https://drive.google.com/drive/folders/1PgxB3JBql7kRzOkEzhBwqKQUXtddcLAj?usp=sharing The filesize limit doesn't allow me to include the files directly, which is a shame, not a fan of link rot and I gotta admit, this link WILL go down once this issue is resolved, because I don't like lingering public links on my Drive account. Either way, I included a sample for Huawei's "Moving Picture" implementation. (consumer info page: https://consumer.huawei.com/uk/support/faq/how-to-take-moving-pictures/) The pic was taken on my MediaPad M5 8.4" tablet. Not amazing quality on that one, but should do the trick of showing the file's logic. I also included a sample for Samsung's "Motion Photo". (consumer info page: https://www.samsung.com/global/galaxy/what-is/motion-photo/ (it doesn't list S20 as compatible device, but it's been reported that it is indeed still a maintained feature, guess they forgot to update that page so far) That pic was taken with my Galaxy Note9. Forgive the dirty keyboard... -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385726] Add Support For Apple Live Photos
https://bugs.kde.org/show_bug.cgi?id=385726 Glassed Silver changed: What|Removed |Added Status|RESOLVED|REOPENED Ever confirmed|0 |1 Resolution|FIXED |--- --- Comment #15 from Glassed Silver --- Why is this item flagged as resolved? Live Photos are still just presented as a separate JPG/HEIC and a .mov. Here's some further reading if it helps grasp the concept of how it all works how it's designed to be a) detected b) treated/viewed. 1) Very nice conclusive overview post on Reddit, also links to sample images for Apple's version, but also Google's. https://www.reddit.com/r/DataHoarder/comments/cuk06h/help_preserving_iphone_live_photos_how_they_seem/exx2rj6/ 2) This is another program written in C++ that to my knowledge correctly implements Live Photos: https://github.com/LycheeOrg/Lychee-Laravel/issues/378 3) Apple's HIG on how Live Photos should be treated: https://developer.apple.com/design/human-interface-guidelines/live-photos/overview/ If desired I can provide a sample for Samsung's implementation, too. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385726] Add Support For Apple Live Photos
https://bugs.kde.org/show_bug.cgi?id=385726 --- Comment #12 from Glassed Silver --- I think if we're going to implement a unified view for the JPG (or HEIF) and movie pair we shouldn't use the regular grouping function, because then we couldn't group multiple Live Photos without creating a messy situation when you ungroup them again. So in a way, we'd probably need a "level zero grouping" so to say. (sorry, can't find a good way to phrase it) You say we should create a new ticket for that then? Not sure about that, but I could do that. Whilst we're at it we might as well implement other popular Live Photo-like implementations as well and use the same unified view for that. Samsung has Motion Photos, Google has Motion Photos as well on Pixel devices and some Android One phones as well I think (I know the Nokia 3.1 has that too for example) and then Huawei has an implementation very much like Apple's too. They all work a little different, but technically it's always a pair of image and movie files being fused into one element visually. Samsung for example embeds the video into the image file itself (making the JPG bigger in size). I know this might sound like a lot at once, but I swear to God, despite me owning a nice and lovely Canon DSLR often times I will at least take a picture a second time with my smartphone just to capture a Live Photo. It really adds that much more to pictures and lets you relieve moments a bit more vividly that didn't seem like a "video moment" but the little bit of motion can often times add a lot. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385726] Add Support For Apple Live Photos
https://bugs.kde.org/show_bug.cgi?id=385726 --- Comment #10 from Glassed Silver --- Created attachment 120775 --> https://bugs.kde.org/attachment.cgi?id=120775=edit Apple Photos Live Photo View -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385726] Add Support For Apple Live Photos
https://bugs.kde.org/show_bug.cgi?id=385726 --- Comment #9 from Glassed Silver --- Created attachment 120774 --> https://bugs.kde.org/attachment.cgi?id=120774=edit Screenshot digikam Live Photo as two separate entries -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385726] Add Support For Apple Live Photos
https://bugs.kde.org/show_bug.cgi?id=385726 --- Comment #8 from Glassed Silver --- Wooops, no not 2 for each, I changed my phrasing mid-sentence and then that happened. Sorry. It's one entry for the image and video part each. So it shows the technically correct two files as what they are - technically - 2 files. However the whole point of Live Photos isn't that the capture process is bundled, but also viewing the image alongside the video seamlessly. Default settings basically beyond some preferences during install wizard. SQLite db, locally stored. No sidecar files. Attached screenshot of digikam and a short video screencap of Apple Photos viewing a Live Photo. As you can see it only displays one entry visually for the IMG_nnn.JPG & IMG_nnn.MOV pair and on mouse hover it will start playing the video bit without sound and if you go into view mode you can play with sound there. (latter not shown) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385726] Add Support For Apple Live Photos
https://bugs.kde.org/show_bug.cgi?id=385726 Glassed Silver changed: What|Removed |Added CC||glassedsil...@gmail.com --- Comment #6 from Glassed Silver --- Just tried adding a Live Photo to digikam 6.1 on macOS and all it produces is two entries for the image and the video part each. It doesn't show the two files as one entry as you'd expect coming from Apple Photos. If this is how it's supposed to work, it's a wrong implementation and not doing anything more than just importing the two files as presented by ANY other software. I would not call this Live Photo support then. However I assume this might be an incompatibility with the macOS port yet? Should I try the GNU/Linux version or is there any other thing to keep in mind? -- You are receiving this mail because: You are watching all bug changes.
