R C-R

Off topic but this problem could easily be avoided if software makers simply avoided using those four characters in product keys. Why none of them have done this is something I will never understand.

OK, for example dive into the whole big picture for Nikon at http://owl.phy.queensu.ca/~phil/exiftool/TagNames/Nikon.html. Search the page on "unknown," look for the question marks, or note what it has to say about Nikon LensID Values: Or consider what he has to say at http://owl.phy.queensu.ca/~phil/exiftool/writing.html about writing tags: That page also includes other info about the problems & pitfalls of writing metadata tags, even with tools based on an ExifTool backend. So it seems pretty obvious that if we do dive into the big picture it becomes very clear that there is nothing simple about this, & that the issue is in fact a very difficult one to solve.

I think a lot of different points have been mentioned here, not the least of which is that just adding some variant of "© copyright" to any tag is, by itself, just about useless. Minimally, the usage rights & who claims them need to be defined as well, ideally both in the IPTC "core" & "Plus" extensions.

I am not so sure that is true. Consider the table from the link. From what I can tell, it only covers jpeg files generated by the listed cameras, so the tags in the innumerable RAW format outputs might be different. The table also doesn't show anything decoded, just raw ASCII & hex values for the first 20 (of how many?) characters in the tag. Judging from your reading and writing those back link, 'automagically' fixing these "particularly insidious" write-back problems is iffy at best, so "operator intervention" is required, meaning some technical knowledge and/or experimentation will be needed. If not done correctly, "some" (how much?) of the MakerNote information may be lost permanently. So I suspect if the dev team posts any comments about it, they basically will say that the 'breakage' issue is a very difficult one to solve, regardless of the available third party libs/code the apps might use.

According to the links posted in this topic, doing that is what breaks the MakerNote tag.

Did you try editing or adding any of the tags that precede the MakerNote one in these apps?

Since cropping is non-destructive by default, I doubt this would make much of a difference unless the additional step of rasterizing each image instance was also done (since that removes the out-of-crop part of the raster image). But I still think using Symbols would be more effective ....

As I understand it, there are other ways for companies to buy multi-user licenses for the Mac versions, but it is not clear if the licenses for them would qualify for the free-for-now bonus content, or how the app updates for the Mac versions can be obtained.

I am reasonably sure they already know about this, but as the link @v_kyr provided explains, the real problem is camera makers are using the Makernote tag for many different kinds of metadata that should be in other metadata tags that are not encoded in some proprietary format that require reverse engineering to decode, and/or break if the Makernote tag must be moved because another tag is added or inserted before it in the file's embedded metadata. IOW, Serif/Affinity did not create the problem, but it they would have to devote significant time & resources to fix it. This almost certainly is part of the reason why apps that do all the necessary reverse engineering & are coded to prevent the tag from breaking when a preceding tag is edited cost more.

Nope. All apps bought through the Mac App Store include an anti-piracy & anti-malware feature that locally generates a receipt file encrypted with the Apple iD used when the app was bought. If the app has been altered, for example by someone injecting malevolent code into it & distributing that as 'free' version, or if the receipts file is missing or has been altered, the app will not run. This protects both Apple's & Serif's "piece of the pie" but it also protects end users from malware posing as legitimate MAS apps.

When you say "edit the file in AD from AP" do you mean via Affinity Photo's File > Edit in Designer like @Callum mentioned? If so, one of the staff (@MEB I think) mentioned some time back that this & Affinity Designer's File > Edit in Photo could cause problems in certain workflows. Unfortunately I can't find the post now or remember the details well enough to say if this was in reference to crashing/freezing or something else, but I do remember that it was suggested to save any changes to the file before using these File menu commands just in case something unexpected happened. This does not change the file extension -- regardless of which app you save the file with, it retains the original extension applied during the first save. Since saving one's work frequently is good practice anyway, maybe give this two step method a try & see if it eliminates the freezing.

Have you tried making one of the duplicates into a symbol & replacing the others with instances of that symbol?

That may have something to do with this from the Exif Wikipedia article: EDIT: The link @v_kyr provided explains this much better.

The last step is exporting the document to some file format at whatever resolution/pixel size is appropriate for the intended end use of the file. Sharpening can be done prior to that using various tools like the Filters > Sharpen choices or the Sharpen Brush. It can also be done on the exported file separately if it is a raster format file. Resampling the file when changing its size, either via "Resize Document..." on the Affinity Photo Document menu or during export (either in the Export Persona or from the File menu > Export item) will affect the sharpness of the file as a byproduct of the resampling algorithm used, but that is not really the same thing as applying sharpening: resampling may sharpen or soften the image & may introduce artifacts like ringing or halos, depending on the algorithm used. To avoid guessing, assuming you know the end use resolution required you can duplicate the file, flatten it if necessary, & experiment with the "Resize Document..." algorithm choices, & then export it at that size. But it is still the last step, & the final sharpness/quality/softness of the exported file will still vary if you choose the jpeg format because that format uses lossy compression. If instead of or in addition to using the "Resize Document..." choice, you use the Export Persona for your exports, you have the option to export to multiple file formats at multiple sizes, using multiple resampling algorithms, ICC profiles, quality settings, & so on. This is very useful if you require different resolutions and/or file formats for different end uses. EDIT: I realize that the English language video tutorials are not ideal for everyone, but the Affinity Photo - Document/Image Resizing one explains more about the differences between using the Resize Document option & the export resizing ones.

I have no idea where the presets are stored in the Windows file system but Callum said, "I have attached the presets to this post for you to download and re import." So I assume you do not need to know where they are installed -- just import them via the Tone Mapping Persona > Presets panel's 'hamburger' menu & I am guessing they will be converted to the appropriate .propcol file format & stored as such.

Are you saying AP can see the lens metadata in the exported file, or in the .afphoto one? What is the file format of the exported version?

What do you mean by "moved"?

I do not understand what you mean by this. Why do you think exporting to some (presumably lower resolution?) web-friendly format "would result in a degree of sharpening"? Are you talking about the effects of the resampling method used to rescale the document? If so, & if you want control over that, you need to do it before export, but that has nothing to do with whether you do the export via the File menu in the Photo Persona or in the Export Persona. Please explain a bit more about what you mean.

Since no other apps besides the Affinity ones can open native format Affinity files (ones with the .afphoto or .afdesign extension), I assume instead of 'save & load' you mean export the Affinity document to some other format other editors can open. If so, one of the export options in AD/AP allows you to remove the metadata on export. (It is in the "Embed Metadata" checkbox in "More" window for File > Export & similarly in the Export Persona.) If you uncheck that option, the all metadata will be stripped from the exported file, including lens data. This will not affect the Affinity format file, so if you open that file again in the Affinity app after exporting it to another format, the metadata will still be there. If you confuse the two files, this would explain what you are seeing.

If you purchased the Mac version of Affinity Designer, you need to go to the Mac App Store ("App Store..." on the Apple menu). The Affinity Store (https://affinity.store/) does not sell the Mac version nor can you get updates to it there. If you open the Mac App Store app from the Apple menu & search on "Affinity," you should see something like this: Go to the Updates tab to find it listed there, along with a download button.

Anyone can sign up to use this website for free. The extra 1.6 content is free until the 16th only for those who have bought the app. For that reason, to download it you must open the app's Welcome screen & click on the "Claim Now" button. If you do not have an Affinity Store account (which is completely different from the website's log in) you can create one using the "New to Affinity" tab at the Affinity Store web page that opens when you click on the "Claim now" button.

Is anyone using SetEXIFData? From the link, there is this: I am not sure if this means the copyright symbol is replaced with the text or visa-versa, but either way, according to http://www.photometadata.org/meta-resources-field-guide-to-metadata#Copyright Notice (& other sources) it seems like this would make it difficult to use the symbol or the word as appropriate for the country or region of interest. I assume "rights" in the above refers to the IPTC Core tag Rights Usage Terms, but from http://www.photometadata.org/meta-resources-field-guide-to-metadata#Rights Usage Terms, in addition to including "free-text instructions on how the photograph can be legally used" in this field, there is this: It is probably a good idea to also click through on that "PLUS" link to see why adding the parallel metadata is encouraged. Anyway, all this implies that a lot of associated metadata should be added for the most effective usage rights protection. It seems pretty obvious to me that a separate tool dedicated to this purpose, ideally with batch processing & preset capabilities, is the best way to go.

Maybe, but a) it is still using a brush tool selectively & b) if the image is developed with different RAW settings that affect contrast, brightness, etc. it seems unlikely that applying the same preset or settings corrections to both would work -- their locality is the same but the amount of correction that would be needed to blend the corrected & uncorrected areas seamlessly is not. At least as I see it, this takes us back to the 'relative to what' problem. I don't know of any way to define that that is somehow independent of the (developed) image. Any ideas on how to do that?

It would be great if deselecting steps & exporting the macro removed the deselected steps during export but I don't think it works like that.

There is still the problem of trying to match the localities of the source(s) & destination(s) between or among different images. I can't see any way this could be done other than manually with a brush or brushlike tool, which I do not think is what @N'Awlins Contrarian wants. Besides, I think there is already a method provided to apply cloning between different images, as explained in the Affinity Photo - Clone Sources video.