Conversation
| /// A registry for extensions that extend the set of tags able to be parsed from the TIFF | ||
| /// [`ImageFileDirectory``]. | ||
| #[derive(Debug)] | ||
| pub struct ExtensionRegistry(HashMap<String, Box<dyn TiffExtensionFactory>>); |
There was a problem hiding this comment.
The idea is for the user to define one or more TiffExtensionFactory to be used when parsing a TIFF, where one defines how to create a new struct to hold parsed TIFF tag data
| /// The name of the extension. | ||
| fn name(&self) -> &str; | ||
|
|
||
| fn from_tags(&self, tag_data: HashMap<Tag, TagValue>) -> Box<dyn TiffExtension>; |
There was a problem hiding this comment.
Defines how the factory creates a new TiffExtension instance from tags of
One difficult thing is that the tags here are provided by value,
Really we want an API where the TiffExtensionFactory builds up extension information iteratively. Where it defines the tags that it claims how to support, and then when a tag with that key is found, the IFD parser delegates to this extension builder.
So perhaps we need three things: TiffExtensionFactory, TiffExtensionBuilder, and TiffExtension. A factory defines how to create a builder. A builder receives tag data one-by-one. Then after the last tag a builder is "finished" into a standalone metadata instance.
There was a problem hiding this comment.
So perhaps we need three things:
TiffExtensionFactory,TiffExtensionBuilder, andTiffExtension. A factory defines how to create a builder. A builder receives tag data one-by-one. Then after the last tag a builder is "finished" into a standalone metadata instance.
Hi Kyle, this seems great, also nice to see a lot is happening again. Just to summarize, that would look something like this:
pub trait TiffExtensionFactory: std::fmt::Debug + Send + Sync {
fn name(&self) -> &str;
fn create_builder(&self) -> Box<dyn TiffExtensionBuilder>
}
pub trait TiffExtensionBuilder: std::fmt::Debug + Send + Sync {
fn supported_tags(&self) -> &HashSet<u16>;
/// insert the tag into self
fn insert(&mut self, tag: u16, value: TagValue);
/// Finish parsing self, returning the TiffExtension on success
fn finish(&mut self) -> Result<Box<dyn TiffExtension>, AsyncTiffError>
}
/// the main thing is that it can be put in a HashMap. supertrait `std::any::Any` to get the underlying data structure through a `downcast_ref()`
pub trait TiffExtension: std::any::Any {
fn as_any(&self) -> &dyn std::any::Any;
}There was a problem hiding this comment.
One thought was that it may very well happen that an IFD does not contain any supported tags. As in a COG only the first ifd contains geo data (now I can only find this section ) So maybe finish()->Option<> should handle that (quite common?) case?
| } | ||
|
|
||
| #[derive(Debug)] | ||
| pub struct GeoTIFFExtension { |
There was a problem hiding this comment.
An example of a parsed GeoTIFF extension. This will then expose the parsed information to the end user.
2 participants
Added some thoughts inline
Closes #100