Formats like TIFF, PDF, and others can contain multiple images. One way to handle this would be to return [](*meta.Data) from the Load() for such containers, and add an imagePath field and an ImagePage() method to meta.Data indicating which image from the file the metadata describes.
The image path probably needs to be a string. For many formats this will simply hold the string representation of an integer index, but for a format like PDF a more general approach to paths is needed. It is useful if the path is human readable for debugging purposes, but the content of the path only needs to be meaningful to the image file decoder.
While I am thinking about it, it may also be useful to add isEmbedded to the either the ICC header or to meta.Data to day where the ICC profile came from. In formats like PDF, the ICC profile embedded in the image can be overridden by a separately stored profile that is associated with the image. It can be helpful to know which kind you are dealing with.
Since the two profiles may not be the same (e.g. when the embedded profile has been intentionally overridden in a PDF), we may want meta.Data to distinguish between the active ICC profile and the embedded ICC profile. My suggestion would be that the current iccProfileX fields hold the active (working) profile so that current behavior is not altered, and that embeddedProfileX fields be added. Usually these will reference the same data.
Formats like TIFF, PDF, and others can contain multiple images. One way to handle this would be to return
[](*meta.Data)from the Load() for such containers, and add animagePathfield and anImagePage()method tometa.Dataindicating which image from the file the metadata describes.The image path probably needs to be a string. For many formats this will simply hold the string representation of an integer index, but for a format like PDF a more general approach to paths is needed. It is useful if the path is human readable for debugging purposes, but the content of the path only needs to be meaningful to the image file decoder.
While I am thinking about it, it may also be useful to add
isEmbeddedto the either the ICC header or tometa.Datato day where the ICC profile came from. In formats like PDF, the ICC profile embedded in the image can be overridden by a separately stored profile that is associated with the image. It can be helpful to know which kind you are dealing with.Since the two profiles may not be the same (e.g. when the embedded profile has been intentionally overridden in a PDF), we may want
meta.Datato distinguish between the active ICC profile and the embedded ICC profile. My suggestion would be that the currenticcProfileXfields hold the active (working) profile so that current behavior is not altered, and thatembeddedProfileXfields be added. Usually these will reference the same data.