Skip to content

Conversation

@weiji14
Copy link
Member

@weiji14 weiji14 commented Nov 22, 2025

By using String::from_utf8_lossy.

Changes:

  • Used another sample OME-TIFF file that has non utf8 characters in the OME-XML
  • Increased prefetch bytes to more than 32kb as workaround to avoid hanging when parsing the StripOffsets tag (xref Tokio hangs when opening TIFF #89)

Fixes #101

By using String::from_utf8_lossy. Changed to another sample OME-TIFF file, and increased prefetch bytes to more than 32kb to avoid hanging when parsing the StripOffsets tag.
@kylebarron
Copy link
Member

Ok so to clarify the spec says that these characters should always be UTF8? And which spec are we talking about? TIFF or OME-TIFF?

This tag type is named Value:Ascii, so it seems like a mismatch that we're hitting utf8 issues. Should we rename that to Value::Text? or Value::String?

Alternatively we could store a Vec<u8> but if this is string data, then Vec<u8> seems improper

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

OME-TIFF: Result::unwrap() on an Err value: General("invalid utf-8 sequence of 1 bytes from index 2144")

3 participants