Oddities creating Exif Profile

[SpooRancher]

I have an issue with handling ExifProfiles, where adding a profile to a JPEG image and then reading it
back doesn't give me exactly what I started with. I don't think I fully understand what I'm doing here, so
advice will be appreciated.

Using
Magick.NET.Core 12.1.0
Magick.NET.SystemDrawing 6.1.0
Magick.NET-Q8-x64 12.1.0

The app targets .NET Framework 4.8.2 and is built with Visual Studio 2022 Community 17.3.2

I start with a tiny JPEG from Photoshop (created from new, saved with "Export As" with "Save metadata" unchecked).
The file starts like this:

00000000  ff d8 ff ee 00 21 41 64 6f 62 65 00 64 40 00 00  ÿØÿî.!Adobe.d@..
00000016  00 01 03 00 10 03 02 03 06 00 00 00 00 00 00 00  ................
00000032  00 00 00 00 00 ff db 00 84 00 02 02 02 02 02 02  .....ÿÛ.„.......
...

Then I create an Exif profile with this code:

    var exifProfile = new ImageMagick.ExifProfile();
    exifProfile.SetValue(ImageMagick.ExifTag.ImageDescription, "ABC");

Using exifProfile.ToByteArray() to get it as a byte array I get:

000000 0000 : 45 78 69 66 00 00 49 49 2a 00 08 00 00 00 01 00  Exif..II*.......
000016 0010 : 0e 01 02 00 04 00 00 00 41 42 43 00 00 00 00 00  ........ABC.....
000032 0020 : 00 00 00 00                                      ....

I read this as:

49 49 2a 00 08 00 00 00             TIFF header, Intel byte ordering
01 00                               IFD contains 1 entry

                                       First and only 12-byte IFD entry:

   0e 01                                Tag value 010e (ImageDescription)
   02 00                                Data is a string
   04 00 00 00                          Data is 4 bytes long, so follows this length count
   41 42 43 00                          The null terminated string

00 00 00 00                          Link to next IFD is 0, so this is the last IFD
00 00 00 00                          ??? 

(I'm not sure what the final 4 null bytes are??)

The exifProfile.Values property gives me one "ImageDescription" value as I expect; the exifProfile.InvalidTags
property is an empty list as it should be.

Now I open the starting image file, set the Exif profile into it and save it:

    using (var magickImage = new ImageMagick.MagickImage("StartingImage.jpg"))
    {
        magickImage.SetProfile(exifProfile);
        magickImage.Write("ImageWithExifProfile.jpg");
    }

Here's how the resulting file starts:

00000000  ff d8 ff e0 00 10 4a 46 49 46 00 01 01 00 00 01  ÿØÿà..JFIF......
00000016  00 01 00 00 ff e1 00 26 45 78 69 66 00 00 49 49  ....ÿá.&Exif..II
00000032  2a 00 08 00 00 00 01 00 0e 01 02 00 04 00 00 00  *...............
00000048  41 42 43 00 00 00 00 00 00 00 00 00 ff db 00 43  ABC.........ÿÛ.C
00000064  00 02 01 01 02 01 01 02 02 02 02 02 02 02 02 03  ................
...

Last step is to open the resulting file again, extract the Exif profile and examine it:

   using (var magickImage = new ImageMagick.MagickImage("ImageWithExifProfile.jpg"))
    {
        var exifProfile = (ImageMagick.ExifProfile)magickImage.GetExifProfile();
    }

I'm expecting to get exactly the Exif profile that I added.

The result from exifProfile.ToByteArray() is:

000000 0000 : 45 78 69 66 00 00 49 49 2a 00 08 00 00 00 01 00  Exif..II*.......
000016 0010 : 0e 01 02 00 04 00 00 00 41 42 43 00 00 00 00 00  ........ABC.....
000032 0020 : 00 00 00 00                                      ....

which is identical to what I created, and the exifProfile.Values property again gives
me the "ImageDescription" value as it should.

But now the exifProfile.InvalidTags property contains one value 42 (x2A)

So it looks as if the ExifProfile object I get reading from the file will give me a correct
byte-array rendering; but has mis-analysed the profile contents.

The ExifProfile object created directly gives a correct analysis of the contents.

The x2A value for the invalid tag is interesting: The only occurrence of that byte value in the file is
in the TIFF file header at offset x32. This byte is 8 before the start of the first directory
entry at x40.

[Attached files are the starting image with no Exif profile, and the file after I added one]

All advice gratefuly received

Thanks

[dlemstra]

This does look like a bug and thanks for providing so much information. It made it much easier to investigate what is happening. Those last 4 bytes is for the offset of the thumbnail image and because this profile has no thumbnail this is zero. But when the profile is read it tries to read the thumbnail from offset zero and that fails. This will be fixed in the next release.

[SpooRancher]

Thanks for looking at this one for me, Dirk! Would you like me to put this in as an Issue for tracking??

Alan

[dlemstra]

There is no need to create an issue for this. I will use this discussion as a reference.