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

Copying a tag value using its iterator with Exiv2::invalidByteOrder uses the wrong byte order #3199

Open
nomis opened this issue Mar 6, 2025 · 0 comments
Labels

Comments

@nomis
Copy link

nomis commented Mar 6, 2025

Describe the bug

I'm trying to access Exif.Canon.AFInfo, which is an array of uint16 values, via rexiv2 which uses gexiv2. There is no direct API access to the array of values so I'm using gexiv2_metadata_get_tag_raw() which calls Exiv2::ExifData::iterator.copy(..., Exiv2::invalidByteOrder) on the tag value.

The copy() implementation ends up calling us2Data() with invalidByteOrder which is not handled correctly so it always returns big-endian data, despite the fact that I am reading a little-endian file on a little-endian host.

To Reproduce

Steps to reproduce the behaviour:

  1. Read the Exif.Canon.AFInfo tag from these sample files: BE.txt BE.jpg LE.txt LE.jpg

  2. Copy the bytes from the iterator using Exiv2::invalidByteOrder

  3. Observe that the values are always in big-endian format

Expected behaviour

The API should disallow this type of access or the tag data should be returned in the original byte order.

Desktop:

  • OS and version: Ubuntu 20.04
  • Exiv2 version and source: 0.27.2-8ubuntu2.7

Additional context

There appears to be no API to get the byte order of the Exif data? I'm using Exif.MakerNote.ByteOrder which happens to be a copy of the byte order (which is confusing because the Canon MakerNote footer does contain a byte order too).

@nomis nomis added the bug label Mar 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant