TIKA-4870: Parse AVIF, do not only detect it - #3116
Merged
Merged
Conversation
AVIF reached no parser: HeifParser claimed heif, heif-sequence, heic and heic-sequence, nothing else claims image/avif, and its mime entry declares no sub-class-of, so an AVIF was detected and then handed to no one. It is the same ISO-BMFF container, and the metadata sits in the same boxes: adding the type is enough for the dimensions, the brands and the XMP that HeifXmp locates through meta/iinf/iloc. Detection was added in TIKA-3193 and nothing picked it up since. The fixture is a 32x32 gradient encoded with libavif through ImageMagick, with an XMP packet attached.
Contributor
There was a problem hiding this comment.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
Pull request overview
Adds actual parsing support for AVIF by routing image/avif to HeifParser, with a regression test and release note so AVIF metadata (dimensions/XMP, etc.) is extracted instead of only being detected.
Changes:
- Extend
HeifParsersupported media types to includeimage/avif - Add a JUnit test verifying AVIF parsing extracts content-type, container brand, dimensions, and XMP fields
- Document the behavior change in
CHANGES.txt
Reviewed changes
Copilot reviewed 3 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
.../HeifParserTest.java |
Adds regression coverage for parsing AVIF (type, dimensions, XMP). |
.../HeifParser.java |
Registers image/avif as a supported type for HeifParser. |
CHANGES.txt |
Notes that AVIF is now parsed (not just detected) under TIKA-4870. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
AVIF reached no parser.
HeifParserclaimsimage/heif,image/heif-sequence,image/heicandimage/heic-sequence, nothing else in tika-parsers claimsimage/avif, and its mime entry declares nosub-class-of, so an AVIF was detected and then handed to no one: no dimensions, no EXIF, no XMP. Detection was added in TIKA-3193 back in 2020 and nothing picked it up since.It is the same ISO-BMFF container and the metadata sits in the same boxes, so adding the type is the whole change. What comes out of the fixture:
image/avif, the brands, 32x32 from theispe, and the XMP thatHeifXmplocates throughmeta/iinf/iloc, the same path HEIC takes.The fixture is a 32x32 gradient encoded with libavif through ImageMagick, with an XMP packet attached, 1 KB.
Two things this does not touch. Animated AVIF still detects as
video/quicktime, which is TIKA-4509 and is a question about the media type name rather than about parsing. And the AVIF motion photo case from TIKA-4869 needs #3115 as well, so its fixture and test follow whichever of the two lands second; I have verified locally that the two together emit the video from the trailingmpvdbox as expected.https://issues.apache.org/jira/browse/TIKA-4870