Add HEIC/HEIF test fixtures for upcoming heic-convert-based decoding
Reuses libheif's own LGPL/MIT-licensed with-alpha-512x512.heic sample under both a .heic and .heif filename, verified to decode correctly via heic-convert (the library the image format work will use). No suitably-licensed HEVC/mif1-branded .heif-distinct sample exists that is compatible with the pinned libheif-js version, and file-type detects both extensions identically regardless of container brand, so the duplicate content is sufficient to exercise the heif source-format code path.
This commit is contained in:
Vendored
+16
@@ -0,0 +1,16 @@
|
||||
# HEIC/HEIF fixture attribution
|
||||
|
||||
`sample.heic` and `sample.heif` are byte-identical copies of
|
||||
`tests/data/with-alpha-512x512.heic` from the
|
||||
[strukturag/libheif](https://github.com/strukturag/libheif) repository
|
||||
(the reference HEIF/AVIF codec library), licensed under the project's
|
||||
LGPL-3.0/MIT terms (see that repo's `COPYING` file).
|
||||
|
||||
Both filenames use the same content deliberately: `file-type` (the
|
||||
content-sniffing library this project uses) detects any file in the
|
||||
HEIC/HEIF family as `ext: 'heic'` regardless of the actual container
|
||||
brand, so the `.heic` vs `.heif` distinction in this project's code is
|
||||
purely about the declared source format taken from the upload's file
|
||||
extension, not about decoding a differently-branded container. Reusing
|
||||
one verified, cleanly-licensed sample under both extensions exercises
|
||||
that code path without requiring a second real-world sample.
|
||||
Reference in New Issue
Block a user