PL9 does not read nor write corresponding xmp for heic files. Please implement this or state clearly in the settings which filetypes have xmp support
What exactly do you expect the XMP file to contain?
I‘d expect the xmp file to contain the same info like raw file xmps. E.g. Rating, color tags, keywords
Normally, HEIC files contain their own metadata, just like JPG files. Both are raster file formats. Some folks are paranoid that, if they write metadata to RAW files, it has more chance of corrupting the image, but are quite happy to write metadata to JPG files, which are evan more likely to corrupt.
This is not a technical problem, just that, because the image part of RAW files can’t be edited and folks treat it a bit like a digital negative. Whereas raster files, like JPG, don’t just contain image, they are the image and editing the "pixels " causes the whole file to be rewritten, not just the image part.
XMP metadata can equally be written to either the HEIC file or an XMP Sidecar and that depends totally on the whim of the software author.
There is just as much “danger” in writing metadata to an HEIC file as to a JPEG.
If you are not seeing the metadata, it is because your software isn’t looking in the right place.
I might remember wrong but I believe that the xmp standards allow/define metadata to be written into the JPEGs. But not into raw files.
I’m not in position to dig up the iso standard at this time but it not related to daring or if on is up to it or not.
But HEIC is not a RAW file, it’s more a “super-jpeg”
Anyway, I wrote three keywords, including two levels of a hierarchy, to a test image, along with a star rating, a Finder tag and a Description using my DAM. Everything was successfully written and PL9 had no problems reading everything except the Finder tag because that is not Label compliant…
And here is the XMP section that got written into the file…
[XMP] XMP Toolkit : XMP Core 6.0.0
[XMP] HDR Gain Map Version : 131072
[XMP] HDR Gain Map Headroom : 6.407171
[XMP] XMP Toolkit : XMP Core 5.5.0
[XMP] Description : Test of HEiC
[XMP] Subject : Animal, Mammal, Trees
[XMP] Date/Time Original : 2025:06:20 14:14:13.029+02:00
[XMP] GPS Latitude : 49 deg 46' 26.16" N
[XMP] GPS Longitude : 8 deg 44' 20.59" E
[XMP] GPS Altitude Ref : Above Sea Level
[XMP] GPS Altitude : 258.7832 m
[XMP] Hierarchical Keywords 1 : Animal, Animal
[XMP] Hierarchical Keywords 2 : Mammal
[XMP] Rating : 2
[XMP] Hierarchical Subject : Animal, Animal|Mammal, Trees
[XMP] Preserved File Name : IMG_8316.HEIC
@schweidj1970 or were you expecting to find other metadata?
I am aware of the fact that for RAW files metadata is normally written to xmp and for heic/jpg into the file itself. But not every software follows these rules. So as it‘s definitely less dangerous to create xmp files than writing in the file, why not allways offer the option to write xmp files? For ALL filetypes?
Because you would be breaking the rule of SPOD (single point of definition). Or should I say, even more than PL does already.
if you open a JPG file and edit the keywords in a great majority of software, it will write the metadata directly into the JPG file’s XMP section - the SPOD.
Unfortunately, PL also writes those metadata to both a DOP sidecar and the database. So, now you are going to have TPOD (three points of definition).
If you then ask for an XMP sidecar a well, you are going to end up with FPOD (four points of definition).
And it is going to depend on what other software you use as to whether it can make sense of that mess and which particular definition it accepts as truth. At least we can be reassured that nothing else is going to read either the DOP or the database, as those are proprietary to DxO.
But we are still left with two points of definition and which gets read is going to depend on which software you are using.
Take the example of maCOS. it maintains its Spotlight database, which allows you to search and filter on a large number of metadata keys, including keywords. So, all I have to do to find an image is to use the comprehensive search provided by Finder, without the need to resort to any kind of third party DAM or cataloguing software.
If I were to use XMP sidecars instead of writing to the original image file, that then means I would have to do a Finder search for a specific text that matches the key/value in the XMP file and then having found that XMP file, move to the folder that contains it and seek out the original file with the same name. Much more effort.
This is one strong reason why I write metadata directly to RAW files.
And before you can shout “Danger! Will Robinson”, you need to consider the other side of the coin. If you should lose an XMP sidecar, you would have no means of searching for the image file, other than visually browsing the thousands of image in your photo library.
Provided you use a tried and tested tool like ExifTool, which provides automatic backups of original files before deleting the original, the possibility of losing an image is infinitesimally small.
Finally, if you have multiple points of definition and one of your apps write one and another writes it elsewhere, where are you going to go for the truth? Or do you read both, which could get confusing and, if you did, which takes priority over the other?
I’m sorry but, since even Adobe is confused on this matter and both embedded and sidecars are possible. It took the greater part of the PL5 beta and a point release after the main release to get, what the majority felt was the best compromise and I can’t see DxO touching this topic again in the near future.
Then there’s this mammoth thread that is just as confusing as it is helpful…
In any case, because PL is a non-destructive editor, if you don’t explicitly export the metadata, it always exports a new copy of the file with all its edits. Even an original JPG image is not modified.