Minor xmp fixes

[chkuendig]

• Don't write xmp sidecar for adjusted versions (some metadata like orientation only makes sense when applying to l the original file)
• Some images (screenshots?) have a different 'adjustmentSimpleDataEnc' (plist instead oc compressed JSON) field. This led to a crash
• One comment had the wrong indents

[AndreyNikiforov]

• Some images (screenshots?) have a different 'adjustmentSimpleDataEnc' (plist instead oc compressed JSON) field. This led to a crash

For filenameEnc field we have to evaluate type subfield to get correct encoding. Does adjustmentSimpleDataEnc have type differentiating encoding too? We can use it to support encoding explicitly and skip unsupported types - probably good to do that for all enc fields to avoid breakages when Apple introduce new encoding.

[AndreyNikiforov]

How many XMP files we need for one asset downloaded in multiple sizes, e.g. original+alternative or original+live? For requested adjusted version we download original if adjusted does not exist yet (and there is complex logic for size fallback) - may be we need digging deeper into this ares? WDYT?

[chkuendig]

Yeah, it might make sense to think this through better. Maybe only download the xmp for original? Generally since the XMP is based on the asset record, it should only be created once for a specific foto.

[AndreyNikiforov]

If only one xmp per asset, then we need some mechanism to ensure it is indeed once for any number of sizes fetched for asset.

[chkuendig]

I removed this change. It's not critical compared to the crash when processing screenshots.

[chkuendig]

For filenameEnc field we have to evaluate type subfield to get correct encoding. Does adjustmentSimpleDataEnc have type differentiating encoding too? We can use it to support encoding explicitly and skip unsupported types - probably good to do that for all enc fields to avoid breakages when Apple introduce new encoding.

Unfortunately for all fields ending in Enc the type subfield just says ENCRYPTED_BYTES which afaik can be any of the following three (maybe there's more):

• Base64 encoded bytes for a unicode string
• Base64 encoded bytes of a binary plist dict
• Base64 encoded bytes of zlib compressed JSON

The Plist is easy to detect (it has specific header bytes), the other two can only be detected by decoding it (and in theory you could probably have a zlib compressed JSON where all bytes are valid unicode?).

[chkuendig]

@AndreyNikiforov I removed the limitation on the AssetVersionSize so this can be unblocked. Maybe long term this is something to revisit, but it doesn't cause any issues as is I think (unlike the crash that's also fixed in this PR).

[AndreyNikiforov]

@AndreyNikiforov I removed the limitation on the AssetVersionSize so this can be unblocked. Maybe long term this is something to revisit, but it doesn't cause any issues as is I think (unlike the crash that's also fixed in this PR).

Great! Add notes to changelog, pls, so it is clear what is new for the next release