[
https://issues.apache.org/jira/browse/TIKA-4870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110721#comment-18110721
]
ASF GitHub Bot commented on TIKA-4870:
--------------------------------------
Copilot commented on code in PR #3116:
URL: https://github.com/apache/tika/pull/3116#discussion_r3915874240
##########
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-image-module/src/main/java/org/apache/tika/parser/image/HeifParser.java:
##########
@@ -41,7 +41,8 @@ public class HeifParser extends AbstractImageParser {
private static final Set<MediaType> SUPPORTED_TYPES = new HashSet<>(
Arrays.asList(MediaType.image("heif"),
MediaType.image("heif-sequence"),
- MediaType.image("heic"),
MediaType.image("heic-sequence")));
+ MediaType.image("heic"), MediaType.image("heic-sequence"),
+ MediaType.image("avif")));
Review Comment:
`SUPPORTED_TYPES` is a mutable `HashSet` stored in a `static final` field.
Since this is effectively constant parser configuration, making it unmodifiable
avoids accidental mutation (including from tests via reflection) and keeps the
supported-type contract stable. Consider wrapping in
`Collections.unmodifiableSet(...)` (or using an immutable-set construction used
elsewhere in the codebase).
##########
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-image-module/src/main/java/org/apache/tika/parser/image/HeifParser.java:
##########
@@ -41,7 +41,8 @@ public class HeifParser extends AbstractImageParser {
private static final Set<MediaType> SUPPORTED_TYPES = new HashSet<>(
Arrays.asList(MediaType.image("heif"),
MediaType.image("heif-sequence"),
- MediaType.image("heic"),
MediaType.image("heic-sequence")));
+ MediaType.image("heic"), MediaType.image("heic-sequence"),
+ MediaType.image("avif")));
Review Comment:
If the project defines/uses `image/avif-sequence` (parallel to
`heif-sequence` / `heic-sequence`), it would be better to include it here as
well so the parser contract matches the AVIF media-type family. This won’t fix
current animated-AVIF detection by itself, but it prevents a future gap where
detection is corrected yet no parser claims the resulting media type.
##########
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-image-module/src/test/java/org/apache/tika/parser/image/HeifParserTest.java:
##########
@@ -84,4 +85,25 @@ public void testAppleLivePhotoMakerNote() throws Exception {
}
}
+ /*
+ testAVIF_XMP.avif is a 32x32 gradient encoded with libavif through
+ ImageMagick, with an XMP packet attached: AVIF is the same ISO-BMFF
+ container, so the same parser reads it (TIKA-4870).
+ */
+ @Test
+ public void testAvif() throws Exception {
+ Metadata metadata = new Metadata();
+ try (TikaInputStream tis =
getResourceAsStream("/test-documents/testAVIF_XMP.avif")) {
+ parser.parse(tis, new DefaultHandler(), metadata, new
ParseContext());
+
+ assertEquals("image/avif", metadata.get(HttpHeaders.CONTENT_TYPE));
+ assertEquals("avif",
metadata.get(ImageMetadataExtractor.UNKNOWN_IMG_NS + "Major Brand"));
+ assertEquals("32 pixels",
metadata.get(ImageMetadataExtractor.UNKNOWN_IMG_NS + "Width"));
+ assertEquals("32 pixels",
metadata.get(ImageMetadataExtractor.UNKNOWN_IMG_NS + "Height"));
+ //the XMP item is found through meta/iinf/iloc, as it is for HEIC
+ assertEquals("AVIF XMP Title",
metadata.get(TikaCoreProperties.TITLE));
+ assertEquals("Jane Photographer",
metadata.get(TikaCoreProperties.CREATOR));
Review Comment:
`TikaCoreProperties.CREATOR` can be multi-valued. Using `metadata.get(...)`
only asserts the first value; if the parser starts returning multiple creators
(or merges values), this test could miss regressions. Consider asserting
against `metadata.getValues(TikaCoreProperties.CREATOR)` (e.g., exact array
match or contains-check) to make the expectation explicit.
> HeifParser should accept image/avif
> -----------------------------------
>
> Key: TIKA-4870
> URL: https://issues.apache.org/jira/browse/TIKA-4870
> Project: Tika
> Issue Type: Improvement
> Reporter: Dominik Schmidt
> Priority: Major
>
> AVIF files reach no parser today. HeifParser claims image/heif,
> image/heif-sequence, image/heic and image/heic-sequence, nothing else in
> tika-parsers claims image/avif, and its mime entry declares no sub-class-of
> image/heif, so an AVIF is detected and then handed to no one: no dimensions,
> no EXIF, no XMP. Detection was added in TIKA-3193 and nothing ever picked it
> up for parsing.
> The container is the same ISO-BMFF and the metadata sits in the same places.
> HeifXmp locates XMP generically through meta/iinf/iloc, which is where AVIF
> puts it as well, and metadata-extractor reads HEIF item properties for AVIF
> too, so adding MediaType.image("avif") to the parser's supported types is
> most of the work; what it needs is a fixture and a check of which properties
> actually come out.
> Once that is in, the Motion Photo work from TIKA-4869 should be checked
> against it: AVIF is one of the three primary image formats the Motion Photo
> format allows, alongside JPEG and HEIC, and its video sits in the same
> trailing mpvd box, so the same code should emit it. There is no test for that
> today.
> Detection of animated AVIF is a separate question and is tracked in TIKA-4509.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
