jpeg rotation confusing output orientation of PDF #151
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I've got a jpeg from an iPhone that has been rotated and has under ImageMagick's
identify
command an orientation of "Righttop". When I do a simple img2pdf command and have-S A4
, hte PDF ends up in landscape rather than portrait mode. If I useA4^T
, it ends up with portrait instead of landscape. In both instances, the images is correctly oriented. Altering the image with a rotate in jpegtran gives the image anundefined
orientation and the output PDF in that case is fine.So it seems like the orientation is being applied to the PDF page.
Version 0.4.4
Can you share an image that you see this effect with?
Sure. Here's a blurry copy of the one I'm using (which is a photo of a passport). I'm not sure what I did exactly to get it into this form, but surely an iPhone photo that was rotated, probably more than that since it's a jpeg and not heic.
If you do not want this behavour, you can run img2pdf with
--rotation=none
. The default behaviour is to auto rotate the page according to the exif rotation value. Since your image contains exif information saying that the image should be rotated 90° clockwise, you are getting a landscape page even though you told it to use a portrait page and vice-versa.Would you prefer that img2pdf chooses portrait and landscape depending on what is the most optimal orientation for your photo?
I guess I don't undersand why img2pdf is rotating the pdf at all. I can add that switch and see what happens.
For me the expected behavior would be to use the page size and orientation in the command, if specified. That is for the pdf. The image should be rotated as its exif data indicates. That's totally separate from the pdf orientation.
In the absence of explicit pdf size and orientation commands, I don't have strong feelings about what to do.
Maybe the
--auto-orient
option is that does what you expect to happen? If I understood you correctly, I guess you want to run this:I'll play with this a bit, but I dont think this is what I want.
Instead what I want is, I think, pretty straightforward. If I specify the pdf size and orientation, that is what should result. That's it. The image should stay as it would normally be displayed. The software should not try to secondguess me.
What I get in my original example is that the image stays the same but the pdf page gets rotated. And it gets rotated to be landscape when the image is portrait. That really makes no sense to me. Nor dies the idea that the page would be affected by internal metadata in the photo.
I can see a use for auto-orient, but that is not what I'm after.
Right now what is happening is:
What I think you want (if I understand you correctly) is:
From what I understand you argue with what "feels right" and what is "intuitive". Is there actually any hard reason to go for either the first or the second way of understanding what "rotate automatially according to the exif data" means? Since I wrote this software for me, the first way makes more sense. To you I guess the second. How can we determine if one of the two is objectively (and not just subjectively) better?
I'm not sure we can get all the way to objective goodness, :-) but here is how I conceive of the app working.
I have an image. It looks good to me. I want it in a pdf. I tell img2pdf to put the image on A4 paper that is oriented normally (portrait). That's what happens: I get the image, looking like it did before, in a portrait A4 pdf.
As for the image's exif rotation data...
I usually don't think about it, as happened to me here. The image looks good in every app I view it in. Why should have to think about it? Heck, I might not even know it had been rotated. Should I have to check that before using img2pdf?
Why should the image's exif data affect the pdf? This is the part that I really don't get. The image gets rotated according to its internal metadata. That always happens. Showing it unrotated is (nearly) always wrong. Conceiving of the image without its rotation is an erroneous consideration, I would suggest. I think what you are saying is that in the current model the software ignores the rotation data, places the unrotated image on the requested page and then rotates that whole page plus image. That seems contrary to the idea of putting the image in a pdf of a particular size and orientation via -S and also to the isea that the image is incomplete with rotation metadata.
Maybe part of the conceptual difference is whether you conceive of the software converting an image to a pdf or just putting it into one? I tend to think of the latter.
PS I dont want it to get lost here how much I use this software and find it extremely helpful.
Thank you for bringing up this issue and explaining it to me.
I have to think more about this because this is a big change in how the options work together and existing users of this library might expect the current behaviour. I will keep this issue open until I find a solution that satisfies me.
Thanks for the reply.
I finally got a little time to play with the suggestions you made above.
--rotation=none
ignores the exif orientation data, which is not what I want.-a
with-S A4
does give me the result I want, as long as I don't want to put the image on a landscape page, since it forces the A4 to portait. At least the image is the right-way up.Based on the above, I guess what I'm asking is to be able to determine exactly what page size and orientation img2pdf will output without knowing anything about the exif tags on a given image. Again, I would have thought that dictating the page and orientation via
-S
would do that.It strikes me that there is an inherent potential conflict between
-S
and-a
in that the latter will override the former, if the image is not oriented the way the pdf is supposed to be.