Photo: TIFF metadata corruption on export

[Paul Coddington]

Problem: When exporting to TIFF, any of the Subject, Tags, Comments metadata fields are corrupted (changed to Chinese characters). Usually the Subject and Tags or the Subject and Comments fields are corrupted depending on scenario.

Steps (Scenario 1):

1. Add metadata tags to a TIFF file in File Explorer.

2. Open in Affinity Photo.

3. Export to TIFF unaltered (with ZIP compression).

Steps (Scenario 2):

1. Add metadata tags to an image in Affinity Photo.

2. Export to TIFF (with ZIP compression).

Steps (Scenario 3):

1. Add tagged TIFF files to Batch process in Affinity Photo.

2. Use Batch process to export TIFF files unaltered to TIFF (with ZIP compression).

The goal of resaving the file with ZIP compression is to workaround the bug in File Explorer that saves tagged TIFF (Zip) as TIFF (LZW) at about three times the size. However, I currently have no editors available that can save a TIFF file with metadata intact without corrupting it (this is also a bug in all Adobe products last time I used them, which was quite some time ago, and the reason I would attempt to use File Explorer to add metadata after editing).

Side discussion: Compression is an interesting problem. On top of the metadata tagging in File Explorer roughly tripling the file size by converting to LZW, simply embedding a TIFF in an AFPHOTO file roughly doubles its size, and if the layer is rasterised with no modifications whatsoever, the AFPHOTO file doubles in size again (even when saved as a fresh copy to compact it). All of this adds up to massive (and expensive) storage waste. They say storage is cheap, but it isn't cheap enough to want to buy three times as many hard drives at several hundred dollars a pop to do the job of one.

For the sake of not sharing family photos, examples are a frame exported from Blu-ray movie for desktop wallpaper. Tags made up to be "typical" (with Unicode characters).

[Explorer bug has been reported to Microsoft.]
 

export.tiff original.tiff

[- S -]

I am also able to reproduce this issue with a new blank TIFF file created with Affinity Photo.  At least for the "Comments" and "Subject" fields, but not for the "Tags" field.

When opening the TIFF file, Affinity Photo converts some Microsoft metadata tags to their own Serif-specific XMP metadata tags [XMP-serifExifExt].  When the file is then saved again from Affinity Photo as another TIFF file, Affinity Photo writes back to the metadata tags shown below.  However, when it writes the Microsoft metadata tags, presumably a text encoding/byte issue is introduced as the written text string now appears as Chinese characters.

The IFD0:XPComment tag gets written to:

XMP-serifExifExt:XPComment
IFD0:XPComment (as Chinese characters)

The IFD0:XPSubject tag gets written to:

XMP-serifExifExt:XPSubject
IFD0:XPSubject (as Chinese characters)

 

Screenshot showing comparison before and after saving in Affinity Photo:

 

Exporting to JPEG works as expected.

-----

Affinity Photo - 2.3.1.2217 (EXE)
Windows 10 - 19045.4046

 

[Paul Coddington]

I have a nagging doubt that I have previously encountered a truncation problem with tags. When this problem is investigated, it would be a good idea to check that the full length of the Tags field is always preserved and not truncated to something shorter than it should be. The Tags field can hold an large amount of data to cater for a long list of many hierarchical tags with potentially long paths. Some apps have been known to truncate it to 255 or even fewer characters, and/or limit each semicolon delimited item to an unrealistically short length.

The Tags in the attached sample file have been truncated, but I think I accidentally did that while copy-pasting them (the last tag should end with the word "FILM" but ends with "F").

[Paradise33]

Possibly related bug special characters used in MetaData fields when using the Affinity Photo Develop Persona the copyright and degrees symbol are converted as seen in the attached photos. Only happened since update to version 2.4.0. Previous versions have always worked correctly.

First image shows correct format in Imatch and second is in Affinity Photo