This is the technical companion to Parergon 1.7.1: full IPTC coverage.
That post lists what’s new. This one explains a piece of groundwork underneath it: how Parergon reads and writes IPTC fields that are not a single value but a list of entries, each with its own parts.
Flat fields and structured fields
Most metadata fields are flat. A Title is one piece of text. A Rating is one number. Read it, change it, write it back.
IPTC also defines structures: a field made of named parts. A Location has a City, a Country, a Sub-location and more. An Artwork has a Title, a Creator, a Date Created and a Copyright Notice.
And many of those structures repeat. A photo of a gallery wall can show three artworks. A news photo can list several people shown, each with a name, an identifier and a description. A picture can credit several contributors, each with a name, an ID and a role.
Inside the file, a repeating structure is an ordered list of entries. The meaning lives in the grouping: this name belongs to this role, in this entry.
Where flat editing goes wrong
The simplest way to edit a structure is to flatten it: show “Contributor Name” as one field and “Contributor Role” as another, and write whichever one changed.
That works while there is only one entry. With two, it breaks.
Tell the metadata engine to set Contributor Name on a file with two contributors, and it does not know which contributor you meant. The write can merge the entries or drop one, keeping whatever parts happened to survive. Nothing reports an error. The file simply describes one contributor where there were two.
We found the same pattern with Location Shown and Artwork. On a file with several entries, editing City for one location removed City from the others.
Step one: refuse the unsafe edit
The first fix in 1.7.1 is a guard. Parergon now counts the entries before it writes.
When a file holds two or more Location Shown, Location Created or Artwork entries, those fields become read-only, and the editor says why. Templates and Metadata Profiles skip them and report that in their summary. Undo leaves them alone.
The same rule covers the flattened parts of every repeating structure: writing one part on its own, such as Contributor Name in the Advanced tab, is refused, because it would merge or drop entries.
Refusing an edit is not a satisfying feature. It is, however, much better than a save that reports success and loses an entry.
Step two: read entries as entries
The second step is to read a repeating structure the way the file stores it: as a list of entries, each with its own parts, in order.
Parergon now does that for repeating IPTC Extension structures. Each name, identifier and role stays attached to the entry it came from.
While reading, Parergon also checks that it can write each entry back exactly. If an entry contains something it doesn’t recognise, such as an unknown part another application added, the list is shown read-only for that file, with the reason. Writing back a list Parergon can’t fully reproduce would delete the parts it doesn’t understand.
Step three: write the whole list, then check it
The third step is writing. Parergon never writes one part of a repeating structure on its own. It writes the whole list as one unit, in a single structured document, with every value escaped exactly once so punctuation, accented letters and non-Latin scripts arrive unchanged.
Then it checks its own work. The write goes to a temporary copy first, and the copy is checked against the list Parergon meant to write before it replaces your original. If the check fails, the original is not replaced.
Undo puts the whole list back as it was, every entry and every part, rather than replaying individual changes.
Every repeating structure, one foundation
Contributor was the first IPTC field built on this foundation. In the Editor tab you can add, change and remove contributors as a list, each with a name, identifiers and roles, and templates (Pro) can set or clear the list.
The rest followed on the same rules: Licensor (with ID, address, phones, email and URL), Copyright Owner, Image Supplier and Image Creator, Person Shown with Details, Product Shown, About and Genre (CV Term), Registry Entry, and the linked and embedded encoded rights expressions. Each is a list you edit entry by entry, and each entry keeps its own details.
Image Regions
IPTC Image Regions are the most demanding repeating structure in the standard. Each region has a shape (a rectangle, circle or polygon) with its coordinates, plus its own name, ID, people, organisations, content types and roles, and some of those are lists in turn.
Parergon reads them with the same structured reader and shows them in their own window, with every region drawn on the image, rotated photos included. You can draw rectangles, circles and polygons, move and reshape them with the mouse or the arrow keys, edit each region’s details, add and delete regions, and save them with undo. Anything else a region carries is written back exactly. When a file’s regions hold something Parergon could not keep, they stay read-only, which is the same rule as above, made visible.
What this foundation is for
Together these cover the repeating structures that photographers, agencies and collections rely on, and with them every field of IPTC Photo Metadata 2025.1, Core and Extension. They all follow the same three rules: refuse what can’t be done safely, read entries as entries, and write the whole list and check it before it touches your file.
That is slower to build than a flat field. It is also the only way we know to edit these structures without ever trading one fact in your file for another. The safety fixes that came out of this work are in What you save is what ends up in the file, and every change is in the Parergon 1.7.1 release notes.
Parergon is free to download, with five metadata edits a day; editing a list or an Image Region is an ordinary edit that counts toward them. Parergon Pro removes the limit and adds templates, among other features.
