IPTC metadata support

[1c3t3a]

IPTC is a common metadata format supported by a bunch of the formats that are available in this crate. We can extend the ImageDecoder trait to make it available to extract this metadata.

This is what I would like to work towards:

Read support for IPTC metadata in:

• [x] JPEG - implemented in zune-jpeg already, released in 0.4.21.

• [x] PNG - implemented in png crate but not wired up to image

• [ ] TIFF - implemented in tiff crate but not wired up to image

Is IPTC common in other formats?

[Shnatsel]

implemented in tiff crate but not wired up to image

@1c3t3a could you clarify? I cannot find any references to tiff crate supporting IPTC metadata.

[1c3t3a]

Sorry, we should maybe open a bug there too. The problem is lined out in the discussion here. The Tiff crate does not need to support this, instead IPTC can be found in certain IFDs. The problem we have here is, that the Tiff crate has no (sane) interface to read a value as a &[u8] and we would need to add that to Tiff first.

[fintelia]

Depending on the format of the data you're trying to get Decoder::get_tag_u8_vec might be what you want?

Edit: though skimming that other thread it looks like the data isn't already in u8 format, so yeah that makes it more challenging

[197g]

I think we'd want a new buffer type that contains some tag's data as a Vec<u8> together with attributes for the byte order and tag-type it was stored in. Then said buffer can be converted to the appropriate endianess (or no conversion, for ascii etc.). We could then also use such a buffer as the output buffer argument, deriving allocation limits from the decoder, and probably supports partial reads in multiples of the type's size. Then a as_bytes() method to complete the interpretation. With appropriate constructors it would be powerful for the encoder, too.

[fintelia]

I could also imagine an API analogous to our current handling of pixel data. For querying tags, there'd be a way to get the number of bytes and a way to pass in a &mut [u8] to write the contents into (converting to native endian if applicable). The higher level API could then allocate a Vec<u32> or whatever and rely on the lower level API for the actual reading.