Private fields and interfaces make file inspection difficult

[jblachly]

My use case is relatively simple:

I need to look for images (within the IFD of a given file) with a particular (Tag, Value) pair and remove them.

Zooming out, it would be nice if the API supported such a use case relatively directly (for example, streaming images from a Decoder to Encoder , potentially with a filter).

Still, implementing this by hand looks to be difficult to impossible, because:

1. No way to know how many IFDs are present (I understand this is a design decision to support streaming decoding)
2. Image is pub(crate), meaning I cannot iterate a list of tags. Alternatively, a member function to provide Directory would be helpful.

Am I approaching this wrongly? Thanks in advance for thoughts or advice.

[fintelia]

Yeah, the crate doesn't really expose an interface for editing existing TIFF files at the moment. You can use get_tag and more_images / next_image to determine which images have the specific tag, but there isn't a way to request all the other tags to encode a new TIFF with everything but that one tag

[jblachly]

Yeah, the crate doesn't really expose an interface for editing existing TIFF files at the moment. You can use get_tag and more_images / next_image to determine which images have the specific tag, but there isn't a way to request all the other tags to encode a new TIFF with everything but that one tag

Given the way the library is structured with Decoder and Encoder, I get the idea that modifying existing file is out of scope, and that seems fine to me.

My real issue is that even duplicating a file with paired Decoder/Encoder seems impossible given that the set of tags is un-knowable.

Would it make sense to make fully pub (not just pub(crate)) decoder::Image? Or, at a minimum to have a method on Decoder that returns ifd: Option<Directory>?

I can make some of these changes but would be ideal if I design it for future upstreamability

[fintelia]

Exposing the Option<&Directory> would probably be the way to go. The type is already public so it would just be a matter of adding the method. I've been wanting to do a more complete overhaul of the crate API for a long time, but it is kind of a lot of work and I haven't gotten around to it...