Add DebuggerDisplay attribute to all Metadata value types, for easier debugging code related to metadata

[lassevk]

It would help tremendously when writing code dealing with metadata to see the tag names.

A simple method would be to adorn all the metadata value container types with a DebuggerDisplayAttribute, to show the tags.

Example:

[DebuggerDisplay("{Tag} = {Value} (ExifString)")]
internal sealed class ExifString : ExifValue<string>

This would, during debugging, show up as

Model = Photosmart Plus B209a-m (ExifString)

instead of just

Photosmart Plus B209a-m

granted, this might be obvious for this particular tag, but in my opinion, this:

ColorSpace = 1 (ExifShort)

is more helpful than this:

1

Rider does show the underlying type name, but since this is just ExifShort, that doesn't help much.

The above format with Tag = Value (Type) is just an example, a good discussion about the exact view would be necessary.

As an example of how this would look, here are the current items being displayed when debugging ExifValues.IEquatable:

Horizontal (normal)
Inches
00
00
sRGB
2338
2249
Photosmart Plus B209a-m
300
300
Windows Photo Editor 10.0.10011.16384
2016:01:02 20:17:37
(ExifByteArray)
96
96
2016:01:02 19:22:28
2016:01:02 19:22:28
(ExifByteArray)

whereas with the proposed change, this would be the result:

Orientation = Horizontal (normal) (ExifShort)
ResolutionUnit = Inches (ExifShort)
SubsecTimeOriginal = 00 (ExifString)
SubsecTimeDigitized = 00 (ExifString)
ColorSpace = sRGB (ExifShort)
PixelXDimension = 2338 (ExifShort)
PixelYDimension = 2249 (ExifShort)
Model = Photosmart Plus B209a-m (ExifString)
XResolution = 300 (ExifRational)
YResolution = 300 (ExifRational)
Software = Windows Photo Editor 10.0.10011.16384 (ExifString)
DateTime = 2016:01:02 20:17:37 (ExifString)
<59932> = ??? (ExifByteArray)
XResolution = 96 (ExifRational)
YResolution = 96 (ExifRational)
DateTimeOriginal = 2016:01:02 19:22:28 (ExifString)
DateTimeDigitized = 2016:01:02 19:22:28 (ExifString)
<59932> = ??? (ExifByteArray)

Even more advanced debugger visualization could also be added using type proxies (only used during debugging), to interpret rational numbers and show them as fractions and so on, if necessary.

Note that Exif tag 59932 is apparently referred to as "padding", whitespace bytes to make room for in-place changes to Exif data without having to rewrite the entire file. Whether such interpretations should be part of such a system is debatable.

[JimBobSquarePants]

@lassevk That's a great suggestion!

I think starting with the basics is wise and adding additional debugging metadata as long as it doesn't negatively affect debugging performance.

Is this something you would be interested in helping with?

[lassevk]

I would absolutely be interested in helping with this. I can do a fork and start working on it, and we'll see how it turns out.

And yes, I absolutely agree, no helper methods or types, just see how far one can go with just the attribute in the first iteration.

I was also able to push it up to the base ExifValue and IptcValue types, so it was a rather small and easy fix.

The proposed changes can be found here:
lassevk/ImageSharp@main...lassevk:ImageSharp:lvk/metadata-debuggerdisplay

I think one question would be if it is necessary to include the type of the actual container, like ExifShort and ExifString in the debugger display string. I know JetBrains Rider shows this type regardless, in front of the value, slightly toned down, but I have not used Visual Studio (Code) for a while for debugging, so I would request some input on whether this is necessary.

Here's two screenshots from how the ExifValues.IEquatable and IptcProfileTests.ReadIptcMetadata_FromJpg_Works properties look with my proposed changes (JetBrains Rider 2024.2 EAP9)

[JimBobSquarePants]

Yeah, that's much better!

I'd need to check both VS and Code to see whether the type is included before being able to make a decision regarding including the type, however I don't see any harm in adding it.