Embed xmp for jpeg, tiff and dng

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
  • gps/coordinates
  • faces

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.

Do I remember right that you use lightroom? Don`t you have trouble when files have both an embedded xmp and a sidecar?

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:)

No, the Save Metadata to File command in Mylio actually writes the metadata back into the image file. Not only embeded XMP properties - but also EXIF, IPTC, and other properties where appropriate.

Mylio always updates the XMP sidecar file when you change any metadata. No need to use the Save Metadata to File command for that.

Ok. I had a folder where I found a lot of xmp files. But I don`t remember if I had saved the metadata to files yet.

For dng, tiff and jpeg-files you mean that xmp-files will be embedded when saving to files. Right? Then there should be no xmp-sidecar anymore in that folder?

No, I mean that Mylio ALWAYS saves metadata to XMP sidecar files, period. For ALL image file formats.

Mylio never saves embedded metadata unless you explicitly choose the Save Metadata to File command.

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.

Yes. AND the metadata will also be stored in the XMP sidecar file as usual. The Save Metadata to File command works IN ADDITION TO Mylio’s normal sidecar behavior.

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?

Thanks for your patience:) :grinning:

1 Like

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 :slight_smile: . 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.

Thank you very much. According to Mylio founder David, they are working on something. Exciting to see during this year.

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.

Any progress for this?

Software is a funny thing.

It is still on our list, no question.

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.


Thank you David! And thank you very much for Mylio! Many reasons to love it:)