Versioning and write-protected version

[Ger]

For years I had my RAW files as master and edited files (tif, jpg) as versions. My RAW files have always been write-protected; the metadata went into the XMP side car file.

Now I tried to change the setup; the final JPG is the master; the other files are versions of that JPG. For propagation, the key selection is XMP without Camera Raw data.

If I make changes in the master JPG and want to write back the results, I can see the versions are propagated to the RAW, but the changes are not written to the corresponding XMP file.
As soon as I remove the read-only flag on the RAW, the write-back and propagation of data is successful.

So, the workaround (removing read-only flag) is easy, but I was just wondering whether this is intentional or do I overlook a setting/parameter?

ger

[Mario]

You have created RAW files where the embedded native EXIF/IPTC/GPS data is out of sync with the copies of this data maintained in the XMP record for the RAW file. This is a user decision and neither endorsed nor supported by me.

JPG files always use embedded XMP data, but may inherit XMP data from existing XMP files with the same name as the JPG file and in the same folder. When XMP data is written back, the JPEG file not only receives XMP updates but also exiting native EXIF/IPTC/GPS data in the JPEG is updated to match what's in the XMP. This is required.

I understand you are propagating data from JPEG files to RAW files now. The RAW file is intentionally write-protected.
My guess would be that the propagation detect that the target file is write-protected and respects that, aborting the propagation.

I have never tested the combination of non-standard options you use and I have never intentionally made my RAW files write-protected to cripple the mandatory synchronization between the EXIF/IPTC/GPS data contained in XMP and their native counterparts contained in the RAW. Not even IMatch can detect or handle all fringe cases or combinations of options a user selects. Maybe I did never consider adding yet another branch in the already super-complicated metadata and propagation that deals with the fact that the target file may be read-only but maybe the XMP file is not. Or maybe this works when you disable the MWG mapping and then the propagation only considers XMP data anyway. There are already 90 code paths at least...

[Ger]

The RAW files only have standard EXIF data coming straight from the camera (they are set to read-only immediately upon downloading from the camera - hence they should not have IPTC or GPS data. All metadata here is (should be) in the XMP file.

The JPG files are in a child directory of the RAW files and indeed have embedded the XMP data in the file (no XMP side car files in the JPG-directory).

As far as I know i have all settings to default, so the only breaking of the MWG mapping should then be the read-only RAWs...

I don't want to fuss too much with metadata, as you mentioned more than once: metadata is a mess. Happy to leave the RAWs read-write if that brings me back to MWG-compliance.

My thought was that the propagation would go to the XMP record of the RAW, and that file is not write-protected.

ger

[Mario]

The RAW files only have standard EXIF data coming straight from the camera (they are set to read-only immediately upon downloading from the camera - hence they should not have IPTC or GPS data. All metadata here is (should be) in the XMP file.

Keep in mind that XMP contains a copy of the native EXIF record. And when you modify certain tags in IMatch, e.g. date and time, create date, description etc. this data must be mapped back from the XMP EXIF section into the native EXIF data in your RAW files. Which you don't allow. If IMatch has to rescan your RAW files from scratch for whatever reason, the EXIF data in the RAW will wipe out changes done only to XMP.

My thought was that the propagation would go to the XMP record of the RAW, and that file is not write-protected.

By default, propagation performs XMP->EXIF/GPS/IPTC as needed after propagating metadata. This requires write access to the RAW file of course. In your case, the RAW file is write-protected and so IMatch skips the propagation to that file.

[Ger]

Mario, thanks for the explanation. Solution is very straightforward, keep the RAW files unprotected and let MWG (i.e. IMatch) manage the metadata.

[Mario]

Very good.