Closed zerocrates closed 1 month ago
Side note: while I do think the root issue here is the misdetection of the profile, it might also be reasonable to say PDFs just always have Undefined orientation? I don't know that they ever really legitimately carry an orientation flag like this, with page orientation stuff instead being handled within the format.
I just pushed a patch to make sure that we read the last xmp profile inside the file and that seems to resolve your issue. It might still be a good idea to always have an undefined orientation for PDF but I am not sure if Ghostscript will always auto orient the output images.
ImageMagick version
6.9.11-60
Operating system
Linux
Operating system, version and so on
Ubuntu 22.04
Description
ImageMagick appears to detect the orientation flag from an embedded image within a PDF and report it as the PDF's orientation. This comes out from
identify
output but is most relevant when using-auto-orient
. As best I can tell, this isn't a case of the file having an incorrect orientation flag, but of ImageMagick incorrectly reading it.The PDF I have consists of embedded JPEG images, each of which themselves have EXIF and XMP rotation flags: the images on pages 1 and 2 are "RightTop" oriented, while 3 and 4 are LeftBottom oriented. ImageMagick reports all pages of this PDF as having RightTop orientation, and with
-auto-orient
passed, it rotates the output 90 degrees clockwise, leading to incorrect output.PDF viewers and renderers, including Ghostscript as the delegate here, have no problem with displaying this PDF as intended, and no tools (i.e.
exiftool
,pdfinfo
) report the PDF itself as carrying an orientation flag, except ImageMagick. It looks like it might be improperly picking up the orientation data from one of the embedded images (the first one?) and treating that as "orientation" for the whole document.My best guess is that it's the XMP that's where the problem lies: there's separate XMP XML for each image XObject, plus an XMP profile for the PDF as a whole, but ImageMagick reports this as the XMP profile for any page of the PDF, which is the one that's specifically for the first embedded image:
The XMP profiles in the document vary page by page, with the last two having 8 for tiff:Orientation, but ImageMagick shows this same "orientation 6" profile for all pages. Regardless, the issue seems to be that any of these are being considered as the PDF's profile, as all of them are associated only with each specific image, and the orientation data they carry doesn't and shouldn't apply to the whole document.
At the end of the document is the PDF's XMP profile, which it would seem should be the one getting used and extracted here:
and this one of course has no orientation data.
Steps to Reproduce
display incorrect_rotation.pdf
shows the PDF as expected in the correct orientation.display -auto-orient incorrect_rotation.pdf
shows the PDF improperly rotated 90 degrees clockwise.(same results with
convert
for the above)identify -format "%[orientation]\n" incorrect_rotation.pdf
shows all 4 pages with "RightTop" orientation.convert +ping "incorrect_rotation_bk.pdf[0]" XMP:-
shows the offending profile (same for all pages, or repeated 4 times without the page specifier)Images
incorrect_rotation.pdf