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.

Sign up for GitHub

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

Jump to bottom

Fixed invalid extraction of image dimensions for HEIF files w/ multiple images #445

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Fixed invalid extraction of image dimensions for HEIF files w/ multiple images #445

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f032d20
Fixed invalid extraction of image dimensions for HEIF files
Nov 8, 2019
b8a7ce1
Removed heif sample images& related test as per drewnoakes 's request
Nov 22, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions Source/com/drew/metadata/heif/boxes/ImageRotationBox.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,14 @@ public ImageRotationBox(SequentialReader reader, Box box) throws IOException

public void addMetadata(HeifDirectory directory)
{
// There may be several images in the HEIF file, what we'd like to return is the rotation
// of the "main" image. We assume that if there are several images, they all have the same
// rotation (and as such we can just take the first rotation that we encounter).
// That is a bold assumption, but should be right most of the time.
// In the wild, the rotation attribute is mainly used for efficiency on cameras, as it avoids
// having to rotate the whole framebuffer (the camera just records the wanted rotation). There
// is no reason a priori to expect the camera to not use this optimization for each image in the
// HEIF file.
if (!directory.containsTag(HeifDirectory.TAG_IMAGE_ROTATION)) {
directory.setInt(HeifDirectory.TAG_IMAGE_ROTATION, angle);
}
Expand Down
24 changes: 23 additions & 1 deletion Source/com/drew/metadata/heif/boxes/ImageSpatialExtentsProperty.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,7 @@
package com.drew.metadata.heif.boxes;

import com.drew.lang.SequentialReader;
import com.drew.metadata.MetadataException;
import com.drew.metadata.heif.HeifDirectory;

import java.io.IOException;
Expand All @@ -43,7 +44,28 @@ public ImageSpatialExtentsProperty(SequentialReader reader, Box box) throws IOEx

public void addMetadata(HeifDirectory directory)
{
if (!directory.containsTag(HeifDirectory.TAG_IMAGE_WIDTH) && !directory.containsTag(HeifDirectory.TAG_IMAGE_HEIGHT)) {
if (directory.containsTag(HeifDirectory.TAG_IMAGE_WIDTH) && directory.containsTag(HeifDirectory.TAG_IMAGE_HEIGHT)) {
// There may be several images in the HEIF file, what we'd like to return is the width and height
// of the "main" image.
// We assume that the main image is the biggest image, so we want to take the max width & height.
// While it is not guaranteed to be correct, this is a pretty safe bet and seems to be validated
// by actual images found in the wild (additional images in practice are often thumbnails or overlays,
// that are going to be smaller that the main image).
// Note that here we also assume that if width is bigger than the preexisting value, so is height.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually looking at this further I think there is a different problem here. We have other image formats that can contain multiple images (e.g. GIF, JPEG, TIFF). In such cases, we produce a directory per image. These kinds of assumptions don't tend to work out well for all users. Instead it's best to reflect the actual data in the directories we produce. Fixing this is probably a larger change, but it would be correct for all users.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I completely agree that there should be multiple directories, but I didn't say anything because I assumed that there was some characteristic of the HEIF files that meant that this didn't make sense. If this is a simple "multi image container" situation, multiple directories should be generated. Developers would then make their own logic for picking which one they are interested in, if only one.

Copy link
Author

@rjean-gilles rjean-gilles Nov 18, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes indeed, as I hinted in my summary the ideal behaviour would be for the library to report all the included images obviously, which (as I said) will probably require a major overhaul if I'm not mistaken. Which means it might not come soon. In the meantime, the library as it is basically pretends that there is only one image in the HEIC file when there might actually be more. The only change that this PR does is to acknowledge that limitation and make it somewhat useful by at least making sure that we report information about the "main" image.

So we're just going from a situation where we just cannot use the library at all (as is) if we ever want to handle HEIC files coming from an iPhone (and let's be frank, that's the main reason today to bother supporting it), to a behaviour that while imperfect (because the lib pretends that there is only one image) will report the correct dimensions for all those iPhone HEIC photos. This is basically a worthwile compromise as I see it (and a temporary one at that, until the correct solution is implemented).

As for the test images, I have tried to contact Nokia about the permission to use their sample images and got no reply. That was more than a week ago, so I was about to replace them with some iPhone images that I would take myself, but sure, I can remove all that and keep the tests to myself, no problem.

Would you then consider approving the PR?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to validate the assumption that the correct change here is a major overhaul.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you.
Looking forward to your conclusion.

try {
directory.setLong(
HeifDirectory.TAG_IMAGE_WIDTH,
Math.max(directory.getInt(HeifDirectory.TAG_IMAGE_WIDTH), width)
);
directory.setLong(
HeifDirectory.TAG_IMAGE_HEIGHT,
Math.max(directory.getInt(HeifDirectory.TAG_IMAGE_HEIGHT), height)
);
} catch(MetadataException ex) {
// We could not read width and height tags as int values (unexpected type ?).
// We just ignore this. It should never ever happen given that we always set those to int values.
}
} else {
directory.setLong(HeifDirectory.TAG_IMAGE_WIDTH, width);
directory.setLong(HeifDirectory.TAG_IMAGE_HEIGHT, height);
}
Expand Down