Skip to content
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

Grid image arranges tiles in wrong order if IDs in the iref are not sequential #2311

Closed
farindk opened this issue Jul 23, 2024 · 8 comments · Fixed by #2312
Closed

Grid image arranges tiles in wrong order if IDs in the iref are not sequential #2311

farindk opened this issue Jul 23, 2024 · 8 comments · Fixed by #2312
Assignees

Comments

@farindk
Copy link

farindk commented Jul 23, 2024

libavif apparently assumes that the tile IDs of a grid image are sequential. If that is not the case, the tiles are composed into the output image in an incorrect arrangement.

Here is an example image that is decoded by libavif like this:

image

@y-guyon
Copy link
Collaborator

y-guyon commented Jul 23, 2024

libavif apparently assumes that the tile IDs of a grid image are sequential. If that is not the case, the tiles are composed into the output image in an incorrect arrangement.

The tile IDs should not matter at all. HEIF spec ISO/IEC 23008-12 says:

The input images are inserted in row-major order, top-row first, left to right, in the order of
SingleItemTypeReferenceBox of type 'dimg' for this derived image item within the ItemReferenceBox. 

However libavif does not respect that pattern as of today (libavif is used in Chrome for example):
2345 avif

5432 avif

@farindk
Copy link
Author

farindk commented Jul 23, 2024

Yes, that's what I meant but expressed incorrectly. It should respect the order in the iref, which it currently doesn't.

@farindk farindk changed the title Grid image arranges tiles in wrong order if IDs are not sequential Grid image arranges tiles in wrong order if IDs in the iref are not sequential Jul 23, 2024
@y-guyon
Copy link
Collaborator

y-guyon commented Jul 23, 2024

Not sure what GIMP 2.10.36 uses under the hood but it opens the out-of-order dimg association file correctly.

@farindk
Copy link
Author

farindk commented Jul 23, 2024

Not sure what GIMP 2.10.36 uses under the hood but it opens the out-of-order dimg association file correctly.

It uses libheif. Same as I used to create the file.

@y-guyon
Copy link
Collaborator

y-guyon commented Jul 23, 2024

(Thank you for taking the time to report this issue by the way.)

copybara-service bot pushed a commit to webmproject/CrabbyAvif that referenced this issue Jul 23, 2024
Instead of using the order from the constructed items, use the dimg
ordering from the iref box.

Fixes the libavif bug AOMediaCodec/libavif#2311

PiperOrigin-RevId: 655255206
copybara-service bot pushed a commit to webmproject/CrabbyAvif that referenced this issue Jul 23, 2024
Instead of using the order from the constructed items, use the dimg
ordering from the iref box.

Fixes the libavif bug AOMediaCodec/libavif#2311

PiperOrigin-RevId: 655255206
copybara-service bot pushed a commit to webmproject/CrabbyAvif that referenced this issue Jul 23, 2024
Instead of using the order from the constructed items, use the dimg
ordering from the iref box.

Fixes the libavif bug AOMediaCodec/libavif#2311

PiperOrigin-RevId: 655255206
@wantehchang
Copy link
Collaborator

To test the fix for this issue, we also need an image grid in which multiple grid tiles reference the same image item. (In the extreme case, all grid tiles reference the same image item.)

@farindk Dirk: do yo happen to have such an image available?

@y-guyon
Copy link
Collaborator

y-guyon commented Jul 24, 2024

To test the fix for this issue, we also need an image grid in which multiple grid tiles reference the same image item. (In the extreme case, all grid tiles reference the same image item.)

I manually edited
https://github.com/AOMediaCodec/libavif/blob/676a6cb82c0261cf5474c086f8e94f0f65ad4645/tests/data/sofa_grid1x5_420.avif
to repeat the same tile twice in dimg:
sofa_grid1x5_420_dimg_repeat avif

The image does not work in Chrome (libavif).
However it does not work in GIMP (libheif) either:

Opening '/home/yguyon/Downloads/sofa_grid1x5_420_dimg_repeat.avif' failed:
Loading HEIF image failed: Invalid input: Unspecified: 'iref' has double references

Which is compliant with the ISOBMFF specification ISO/IEC 14496-12:

8.11.12.1 Definition
The items linked to are then represented by an array of to_item_IDs;
within a given array, a given value shall occur at most once.

A workaround would be an intermediate iden derived image item (which is also unsupported by libavif).

Anyway I believe this is a different issue than #2311.

copybara-service bot pushed a commit to webmproject/CrabbyAvif that referenced this issue Jul 24, 2024
Instead of using the order from the constructed items, use the dimg
ordering from the iref box.

Fixes the libavif bug AOMediaCodec/libavif#2311

PiperOrigin-RevId: 655255206
@wantehchang
Copy link
Collaborator

wantehchang commented Jul 24, 2024

Yannis: That's good news. I was mislead by the incorrect comment in libavif. Thank you for finding proof that the image grid I requested is not compliant with ISOBMFF.

copybara-service bot pushed a commit to webmproject/CrabbyAvif that referenced this issue Jul 25, 2024
Instead of using the order from the constructed items, use the dimg
ordering from the iref box.

Fixes the libavif bug AOMediaCodec/libavif#2311

PiperOrigin-RevId: 655255206
copybara-service bot pushed a commit to webmproject/CrabbyAvif that referenced this issue Jul 25, 2024
Instead of using the order from the constructed items, use the dimg
ordering from the iref box.

Fixes the libavif bug AOMediaCodec/libavif#2311

PiperOrigin-RevId: 655255206
copybara-service bot pushed a commit to webmproject/CrabbyAvif that referenced this issue Jul 25, 2024
Instead of using the order from the constructed items, use the dimg
ordering from the iref box.

Fixes the libavif bug AOMediaCodec/libavif#2311

PiperOrigin-RevId: 655255206
copybara-service bot pushed a commit to webmproject/CrabbyAvif that referenced this issue Jul 25, 2024
Instead of using the order from the constructed items, use the dimg
ordering from the iref box.

Fixes the libavif bug AOMediaCodec/libavif#2311

PiperOrigin-RevId: 656071329
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Jul 31, 2024
Changed since 1.1.0
* In avif.h, change "AVIF_API AVIF_NODISCARD" back to "AVIF_NODISCARD AVIF_API"
  to fix clang-cl and MSVC compilation errors in the shared library build on
  Windows.
* Fix -DAVIF_GTEST=SYSTEM, AOMediaCodec/libavif#2258.
* Fix infe_type and codec_config_type wrongly read as byte-aligned fields in the
  experimental feature AVIF_ENABLE_EXPERIMENTAL_METAV1.
* When building aom as a local dependency, runtime CPU detection
  (`CONFIG_RUNTIME_CPU_DETECT`) is now always `ON`; in 1.1.0 it had been
  disabled for non-native builds.
* Fix CMake config shared library leaks
  AOMediaCodec/libavif#2264.
* Fix clang-cl compilation.
* Update gain map metadata to current ISO 21496-1 draft.
* cmake: Only search for ASM_NASM language on x86_64 platforms.
* Fix "No known features for CXX compiler" CMake error.
* Fix aom link flags so that transitive library link flags are included when
  aom is a static library
  AOMediaCodec/libavif#2274.
* Fix out-of-order 'dimg' grid associations
  AOMediaCodec/libavif#2311.
* Report files with an item used in multiple 'dimg' boxes with
  AVIF_RESULT_NOT_IMPLEMENTED instead of AVIF_RESULT_INVALID_IMAGE_GRID.
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 a pull request may close this issue.

3 participants