Please do something with this. According to the standard, xmp-files should be embedded for these files. When using Mylio together with other applications, we get two sets of xmp: a sidecar and an embedded version. This can cause trouble.
I guess this is the reason why Mylio will not pick up changes done in other applications for:
date and time
This will also cause trouble if we save metadata to files in Mylio: many other applications use embedded xmp for these filetypes.
My opinion: NOT until Mylio comes up with some kind of partial-file or block-level replication. I do NOT want Mylio to resync my entire 250 MB TIFF file to all my vaults, every time I change a simple flag or keyword.
Yes, it’s a pain but it can be made to work. I’d also prefer Mylio works exactly like Adobe (XMP sidecars for RAW, embedded metadata where supported (JPEG, TIFF, DNG). But even Adobe is inconsistent here - eg, they use XMP sidecar for HEIC.
But not at the expense of horrendous sync performance. Triggering full sync of large image files is a much bigger issue for Mylio than other apps - precisely because replication is it’s primary reason for existence.
If you change metadata in Mylio, then:
a) perform Save Metadata to File in Mylio
b) perform Read Metadata from File in Lightroom
If you change metadata in Lightroom, then:
a) perform Save Metadata to File in Lightroom
b) perform Organize -> Scan for Changes in Mylio, then wait indefinite time for changes to show up (they usually do, eventually)
Mylio unfortunately does not have the exact equivalent of LR’s Read Metadata from File command. See my previous feature request for that:
But the problem seems to be that using Mylio to add different type of metadata and then save to file causes xmp sidecars, not embedded xmp. But I am no expert here;)
My point here is that I want changes done in Imatch or Lightroom to show up in Mylio. And I don`t have too good experience with this. Seems at least to be inconsistent.
I think the problems starts if I save metadata to files from Mylio for some operations/metadata and save metadata to files for other data from Imatch. Then you get both embedded and sidecar xmps in the system. This seems to be potential trouble. But I may be wrong:)
Yes, that was what I was thinking of: If I want all xmp-files in a folder embedded (for dng, jpeg, tiff), I can do that with Save Metadata to File. As long as I use this command when edits are done in Mylio, all xmp-files will be saved inside the files.
What is the reason to have this sidecar when the metadata is already stored inside the file (the save metadata to file is used)? This is double? Shouldn`t there be a choice to avoid this behavior? Or an easy way to just delete these sidecars when the metadata is saved to files?
The use of sidecar files vs embedding is a decades-old debate in the world of metadata, not only for images but for documents also. Both approaches have their merits.
For XMP sidecar files:
One standard method for reading/writing metadata. Same for every file type. Doesn’t have to be re-invented / re-coded for every new file type (for example, newer Apple .HEIC files).
Works for file types that don’t support embedded metadata, like most proprietary RAW files.
No need to touch your precious original files. Less chance of some random app having a bug, and corrupting or destroying your image files while saving metadata.
For apps that automatically replicate (sync) your files - no need to re-sync the entire image every time the metadata is changed. Just re-sync the (small) XMP file. Especially relevant for Mylio. Note that a few apps (but not Mylio yet) can do partial or “block-level” replication to minimize this problem.
For embedded metadata:
No need for a separate sidecar file. Much simpler file move/copy/delete operations for users and apps.
Supported by more apps, in particular operating-system viewers like Finder or File Explorer.
Mylio has chosen to standardize on XMP sidecar files for everything. Which makes sense for them. But unfortunately complicates interop with other apps that don’t understand XMP sidecars. Adobe has chosen different behavior for different file types. They never touch your proprietary RAW files, but they embed metadata for DNG, JPEG, and TIFF (but surprisingly not HEIC).
It would be great if every app would work the same as every other app - but I’m afraid that’s like asking for world peace . For now, using the Save File to Metadata and Read Metadata from File between apps seems to work for me.
But if Mylio could someday implement partial-file syncing, then I agree it would make sense to prefer embedded metadata where possible.
And there’s actually a THIRD way to store metadata - which is inside an application’s database. Both Mylio and Lightroom do this as well. But that doesn’t allow for ANY interoperability, hence the need to also support either 1) sidecars or 2) embedded metadata.
We do plan to address the problem of embedded xmp files for jpg’s, tiff’s and dng’s at some point this year. As explained above, doing this without differential replication will cause a lot of data to be replicated each time a rating, say, is changed. There are exciting things coming – more than one of them. I’m not sure I’d call this exciting, but it too is coming.
A few larger projects are taking longer than we expected although they are also going to be better than we expected when done. First and foremost is dedup. Not far behind is web sharing (creating a web album that you can send a sharing link to that is automatically connected to and populated from a Mylio album). Object recognition, to complement faces is somewhere in that mix.
And, yes, embedding XMP still has to be done; we just have to figure out when.