Giters

image-rs / image-tiff

TIFF decoding and encoding library in pure Rust

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Private fields and interfaces make file inspection difficult

jblachly opened this issue · comments

commented

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.

commented

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

commented

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

commented

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...