Handling of metadata that describes metadata

[bradh]

One of the things that the NGA GEOINT Imagery Media for ISR Profile of ISOBMFF (aka "GIMI") does is add ContentID items to identify items across files.

Those ContentIDs are essentially URN formatted UUIDs, and they exist for images and for things like general metadata and security metadata. So its kind of an item that acts as a persistent, unique label on another item.

That causes a problem in libheif, because its an error if the target of the metadata reference (cdsc) is not an image. See

libheif/libheif/context.cc

Lines 914 to 920 in 4a3327b

	uint32_t exif_image_id = refs[0];
	auto img_iter = m_all_images.find(exif_image_id);
	if (img_iter == m_all_images.end()) {
	return Error(heif_error_Invalid_input,
	heif_suberror_Nonexisting_item_referenced,
	"Metadata assigned to non-existing image");
	}

I am not sure if it is legitimate for the target of cdsc to be something other than an image or track, and have asked for clarification at MPEGGroup/FileFormat#82

Assuming it is (and I think that is likely - its already used for region items at least), would it be reasonable for ImageMetadata (

libheif/libheif/context.h

Lines 50 to 57 in 4a3327b

	class ImageMetadata
	{
	public:
	heif_item_id item_id;
	std::string item_type; // e.g. "Exif"
	std::string content_type;
	std::vector<uint8_t> m_data;
	};

) to be extended with a std::vector<ImageMetadata> ? Possibly rename it as well?

There would need to be some rework to find the right target (since it won't always be from m_all_images with this change), and to expose the metadata through the C API. Would appreciate suggestions on those.

[farindk]

When it is confirmed that this is a valid usage, we can do the necessary changes to generalize this.

In which way we would extend the API needs more thoughts. The general plan was to provide two API levels. One high-level API for the common image-reading case (basically what exists today), and a low-level API with direct access to the file structure (a step into that direction was the introduction of functions like heif_item_get_properties_of_type()). It might be that your use case would go through the low-level API instead of augmenting the existing high-level metadata functions.

[dukesook]

I really like the idea of a second low-level API, I have felt the need for such functions.

[bradh]

I think the NGA profile has moved on, such that the content ID is just an item property. So this is no longer particularly pressing.

There are tickets for other parts of the low level API.

Will close this.