Skip to content

feat:extra_tags_registry #114

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

feefladder
Copy link
Contributor

@feefladder feefladder commented Jul 30, 2025

closes #100

This PR only does the registry and the needed API. There should be a separate PR coming that moves all geo-tag parsing code to use this system. I thought there'd be enough changes in this PR already

notes:

  • deep clone functionality ?needed? (since different IFDs can have different tag values)
    • this uses some pointer comparison magic where I cast to "thin" pointers, which technically shouldn't matter, since we're only expecting to have duplicates from Arc::clones, but it's a bit of a large possible footgun that's easily avoided.
    • there is a bit of a dance to make Clone object-safe, so there's the blanket ExtraTagsCloneArc trait.
  • made the API match that of DecoderRegistry: pass in the registry as an argument to the last possible function call (IFDReader::read;IFDReader::read_all_ifds())
  • The trait fn tags(&self) -> &'static [Tag] is a bit ugly, also in the tests
    • &self is needed because of object safety
    • should return a reference to a static or const variable
  • more tests still desireable for ifd::from_tags
    • this is now in exif example doctests
    • deep cloning in read_all_tags is not currently tested
  • keep the same functionality in the later PR by adding GeoTags to ExtraTagsRegistry::default()
  • could have a non-mutable access function to the underlying hashmap

@weiji14 you gave 👀, feel like reviewing? :)

@weiji14
Copy link
Member

weiji14 commented Jul 30, 2025

Hi @feefladder, I'm super busy right now (upcoming conference + travel), so won't have the headspace to review until late August. Maybe @kylebarron can have a look if he has time.

Comment on lines +271 to +278
if extra_tags_registry.contains(&t) {
extra_tags_registry[&t].process_tag(t, value).map_err(|e| {
if let AsyncTiffError::InternalTIFFError(err) = e {
err
} else {
// TODO fix error handling. This is bad
TiffError::IntSizeError
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For most purposes, the error will come from Value::into_<something>, which is InternalTiffError, so there it shouldn't be a problem. An alternative would be to panic!, or to do this outside of the match block.

Comment on lines +272 to +277
// (using thin pointer equality: https://stackoverflow.com/a/67114787/14681457 ; https://github.com/rust-lang/rust/issues/46139#issuecomment-346971153)
if seen.insert(Arc::as_ptr(extra_tags) as *const ()) {
if let Err(e) = new_registry.register(extra_tags.clone_arc()) {
panic!("{e}");
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we only expect different arcs to come from register, which is Arc::clone, fat pointers should also compare equal, but there is a bit of a rabbit-hole with there being no guarantee on vtable layouts (IIRC)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was a bit unsure to put this here or in tests/image_tiff/images, since it's strictly speaking not from there (I do like the example being exif)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Extension tag registry
2 participants