Wrong image auto orientation ?

[fpgamaster]

ImageMagick version

7.1.1-26

Operating system

Other (enter below)

Operating system, version and so on

FreeBSD 14

Description

Wrong image orientation using MagickBooleanType MagickAutoOrientImage(MagickWand *wand)

Steps to Reproduce

Here is the EXIF information. As a result of auto orientation the image is rotated incorrectly at 90 CW but should be rotated at 90 CCW!

ExifTool Version Number         : 12.50
File Name                       : pwhc7j1vpy7h
Directory                       : .
File Size                       : 36 MB
File Modification Date/Time     : 2024:05:10 21:16:26+03:00
File Access Date/Time           : 2024:05:10 23:05:59+03:00
File Inode Change Date/Time     : 2024:05:10 21:16:26+03:00
File Permissions                : -rw-rw-rw-
File Type                       : DNG
File Type Extension             : dng
MIME Type                       : image/x-adobe-dng
Exif Byte Order                 : Big-endian (Motorola, MM)
Make                            : Apple
Camera Model Name               : iPhone 12 Pro
Preview Image Start             : 63556
Orientation                     : Rotate 90 CW
Rows Per Strip                  : 3024
Preview Image Length            : 7549126
Software                        : 17.5
Modify Date                     : 2024:04:18 13:52:39
Subfile Type                    : Full-resolution image
Image Width                     : 4032
Image Height                    : 3024
Bits Per Sample                 : 12 12 12
Compression                     : JPEG
Photometric Interpretation      : Linear Raw
Samples Per Pixel               : 3
Planar Configuration            : Chunky
Tile Width                      : 504
Tile Length                     : 504
Tile Offsets                    : (Binary data 427 bytes, use -b option to extract)
Tile Byte Counts                : (Binary data 335 bytes, use -b option to extract)
Linearization Table             : (Binary data 21699 bytes, use -b option to extract)
Black Level                     : 0 0 0
White Level                     : 65535 65535 65535
Noise Profile                   : 3e-05 3e-08
Default Black Render            : None
Profile Gain Table Map          : (Binary data 49408 bytes, use -b option to extract)
Exposure Time                   : 1/428
F Number                        : 2.0
Exposure Program                : Program AE
ISO                             : 25
Exif Version                    : 0232
Date/Time Original              : 2024:04:18 13:52:39
Create Date                     : 2024:04:18 13:52:39
Offset Time                     : +03:00
Offset Time Original            : +03:00
Offset Time Digitized           : +03:00
Shutter Speed Value             : 1/428
Aperture Value                  : 2.0
Brightness Value                : 7.707632833
Exposure Compensation           : 0
Metering Mode                   : Multi-segment
Flash                           : Off, Did not fire
Focal Length                    : 6.0 mm
Subject Area                    : 2004 1514 2318 1393
Run Time Flags                  : Valid
Run Time Value                  : 2995265885958
Run Time Scale                  : 1000000000
Run Time Epoch                  : 0
Acceleration Vector             : -0.03274015709 -0.9480307104 -0.3352252245
Focus Distance Range            : 3.33 - 3.37 m
Live Photo Video Index          : 1112547584
Sub Sec Time Original           : 136
Sub Sec Time Digitized          : 136
Exif Image Width                : 4032
Exif Image Height               : 3024
Sensing Method                  : One-chip color area
Scene Type                      : Directly photographed
Exposure Mode                   : Auto
White Balance                   : Auto
Focal Length In 35mm Format     : 52 mm
Lens Info                       : 1.539999962-6mm f/1.6-2.4
Lens Make                       : Apple
Lens Model                      : iPhone 12 Pro back triple camera 6mm f/2
Composite Image                 : General Composite Image
GPS Latitude Ref                : North
GPS Longitude Ref               : East
GPS Altitude Ref                : Above Sea Level
GPS Time Stamp                  : 10:52:38
GPS Speed Ref                   : km/h
GPS Speed                       : 0
GPS Img Direction Ref           : True North
GPS Img Direction               : 259.9790649
GPS Dest Bearing Ref            : True North
GPS Dest Bearing                : 259.9790649
GPS Date Stamp                  : 2024:04:18
GPS Horizontal Positioning Error: 6.59729063 m
DNG Version                     : 1.6.0.0
DNG Backward Version            : 1.3.0.0
Unique Camera Model             : iPhone13,3 back telephoto camera
Color Matrix 1                  : 1.210916758 -0.5171784163 -0.2446352243 -0.4480841756 1.493248224 0.007582519203 -0.04304760322 0.1864003539 0.6076977849
Color Matrix 2                  : 0.8891333342 -0.2923306227 -0.1202171519 -0.421434015 1.284245372 0.1107940823 -0.1072451025 0.2506295443 0.4410457015
Analog Balance                  : 2.121582031 1 1.820556641
As Shot Neutral                 : 1 1 1
Baseline Exposure               : 4.041075706
Baseline Sharpness              : 1.5
Calibration Illuminant 1        : Standard Light A
Calibration Illuminant 2        : D65
Noise Reduction Applied         : 0.9499999881
Profile Name                    : Apple Embedded Color Profile
Warning                         : [Minor] Not decoding some large array(s). Ignore minor errors to decode
Profile Tone Curve              : (large array of 514 float values)
Run Time Since Power Up         : 0:49:55
Aperture                        : 2.0
Image Size                      : 4032x3024
Megapixels                      : 12.2
Preview Image                   : (Binary data 7549126 bytes, use -b option to extract)
Scale Factor To 35 mm Equivalent: 8.7
Shutter Speed                   : 1/428
Create Date                     : 2024:04:18 13:52:39.136+03:00
Date/Time Original              : 2024:04:18 13:52:39.136+03:00
Modify Date                     : 2024:04:18 13:52:39+03:00
GPS Altitude                    : 622.9 m Above Sea Level
GPS Date/Time                   : 2024:04:18 10:52:38Z
GPS Latitude                    : 42 deg 38' 20.73" N
GPS Longitude                   : 23 deg 23' 0.78" E
Circle Of Confusion             : 0.003 mm
Field Of View                   : 38.2 deg
Focal Length                    : 6.0 mm (35 mm equivalent: 52.0 mm)
GPS Position                    : 42 deg 38' 20.73" N, 23 deg 23' 0.78" E
Hyperfocal Distance             : 5.19 m
Light Value                     : 12.7
Lens ID                         : iPhone 12 Pro back triple camera 6mm f/2

Images

No response

[fmw42]

What command did you use? Did you include -auto-orient? See https://imagemagick.org/script/command-line-options.php#auto-orient

[fpgamaster]

Hi @fmw42,

It is a C binding which calls these functions in this order:

MagickBooleanType MagickReadImage(MagickWand *wand, const char *filename)
MagickBooleanType MagickAutoOrientImage(MagickWand *wand)
MagickBooleanType MagickWriteImage(MagickWand *wand, const char *filename)

[dlemstra]

Did you check if this still reproduces in the latest version of ImageMagick? There might also be other metadata that results in a different orientation. But without an image we probably cannot give you more information.

[fpgamaster]

HI @dlemstra,
No, I have not checked with the latest ImageMagic since the MagickCore/transform.c is same.

Here you can find two images. The first one is oriented correctly but the second one does not:
http://77.85.20.96/pics/3f22cvy4rb89
http://77.85.20.96/pics/pwhc7j1vpy7h

It looks like that the EXIF informations is incorrect but I do not think that Apple will do such thing.
At the same time both pictures are correctly oriented on Apple devices.

[fpgamaster]

May be I am facing the same issue as #5183 ?
It is closed but may be there are changes which lead to the same issue ...

[dlemstra]

pwhc7j1vpy7h.zip.001.zip
pwhc7j1vpy7h.zip.002.zip
3f22cvy4rb89.zip

Adding images for future reference.

[dlemstra]

Your tiff file contains a TIFFTAG_ORIENTATION that is set to RightTop and that is why your image is rotated upside down. The value is 6 and that means the following according to the documentation (https://www.awaresystems.be/imaging/tiff/tifftags/orientation.html):

6 = The 0th row represents the visual right-hand side of the image, and the 0th column represents the visual top.

So I suspect that the software that created this has written 6 instead of 8.

[fpgamaster]

Hi @dlemstra,
Thanks for the info!
The documentation says: 'The orientation of the image with respect to the rows and columns.'
So, if the orientation is 'Rotate 90 CW' we need to rotate to 90 CCW.
The image is taken with iPhone in portrait orientation.

[dlemstra]

There is no need to mention my name in the response. The TIFF value of 6 means that the top of the image is the right side and that the left side is the top. This means that we are rotating the image correctly.

[fpgamaster]

Hmm, I am a bit confused :(
I can't find any reports for incorrect orientation flag of DNG images from iPhone.
Also, I can't find any similar issues with other imaging softwares related to DNG and Apple devices.
If the orientation flag is correct then it depends on how the DNG image is loaded.

[fmw42]

See

https://irfanview-forum.de/forum/program/feature-requests/1943-https://helpx.adobe.com/content/dam/help/en/photoshop/pdf/DNG_Spec_1_7_1_0.pdf
https://www.awaresystems.be/imaging/tiff/tifftags/orientation.html
https://sirv.com/help/articles/rotate-photos-to-be-upright/#:~:text=EXIF%20orientation%20values,-The%208%20EXIF&text=%3D%200%20degrees%2C%20mirrored%3A%20image,and%20is%20on%20its%20side.

I cannot seem to download and/or unzip your files. So my question is do the exif orientation and the tiff orientation flags indicate the same needed orientation rotation?

[fpgamaster]

Please, take a look of this: python-pillow/Pillow#4053

[fmw42]

That looks like a Pillow issue, not a tiff tag issue.

[fmw42]

Please repost an image with this issue. When I download your file, it has no suffix. When I try the zip file, it won't unzip. It says "unsupported format"

Nevermind, I see that your file is tiff. So I added a tiff suffix to it.

[fpgamaster]

Yes, it is a Pillow issue but look how they handle the tiff orientation tag values:

if orientation == 2:
srcim = srcim.transpose(Image.FLIP_LEFT_RIGHT)
elif orientation == 3:
srcim = srcim.transpose(Image.ROTATE_180)
elif orientation == 4:
srcim = srcim.transpose(Image.FLIP_TOP_BOTTOM)
elif orientation == 5:
srcim = srcim.transpose(Image.TRANSPOSE)
elif orientation == 6:
srcim = srcim.transpose(Image.ROTATE_270)
elif orientation == 7:
srcim = srcim.transpose(Image.TRANSVERSE)
elif orientation == 8:
srcim = srcim.transpose(Image.ROTATE_90)

[fmw42]

When I look at your bad example in Imagemagick display, it looks like it has been photographed so that it needs to be rotated 90 to the left or counter clockwise. That is it is photographed 90 clockwise from a proper orientation. From the verbose information and from exiftool, it shows:

IM verbose info Orientation: RightTop

Exiftool: 274 Orientation : Rotate 90 CW

I think the exiftool means that the image was rotated 90 CW. So both of these mean that it needs to be rotated 90 CCW, which is what IM has done.

I think that the OP may be using a viewer that does not respect the orientation tag and so the result looks wrong.. He should try using magick display to view the original and then the -auto-oriented image and see if that looks correct

magick -quiet image.tiff -auto-orient new_image.tiff
magick display image.tiff
magick display new_image.tiff

[fmw42]

So what about the Pillow tags. Perhaps they mean what you need to do with the file to correct, not what is wrong with the file. Is that just a difference in cw vs ccw. That is ROTATE_270 CCW is the same as ROTATE_90 CW.

[fpgamaster]

Please, find an iPhone and take some pictures in RAW format (RAW in the top right corner of the camera app).
Make sure that you have transferred the image in correct format (DNG) to your test environment.
Then let us know if it is a bug in Apple's software/hardware or it is something else.
Thanks

[fmw42]

Why don't you try taking a picture and save it some other format and see if you get the same issue and let us know.

You never answered what viewer you are using to view your results. Did you view in some other app or with

magick display image.dng

or

magick display DNG:image.dng

to ensure it is reading as DNG.

[fmw42]

I found this diagrammatic interpretation.

https://sirv.com/help/articles/rotate-photos-to-be-upright/

Also see the section titled: Incorrect EXIF orientation

[fpgamaster]

FYI

Original images:
http://77.85.20.96/pics/pwhc7j1vpy7h
http://77.85.20.96/pics/3f22cvy4rb89

Auto rotated by Pillow:
http://77.85.20.96/pics/pwhc7j1vpy7h.jpeg
http://77.85.20.96/pics/3f22cvy4rb89.jpeg

And the python script:
http://77.85.20.96/pics/auto_rotate.py

Best regards

[fmw42]

I cannot get to your images. A login username and password is needed. Nevertheless, what is the point here? We are not a Pillow or Python forum.

[fpgamaster]

Links should work again.
All files zipped: http://77.85.20.96/pics/ref_files.zip

The point here is that there could be an explanation other than wrong exif information.

[fmw42]

I looked at your JPG example. It shows

Imagemagick: Orientation: RightTop

Exiftool: 274 Orientation : Rotate(d) 90 CW

Both indicate to rotate the image CCW 90 deg, which is what Imagemagick is doing if you use the magick display to view it.

I have no idea what other software is doing? The image looks correct to you an me on Mac Preview because many other tools are ignoring the orientation tag. I have no idea why the image is tagged with RightTop meaning to re-orient by 90 deg CCW.

[fpgamaster]

If exif is ignored (stripped), the original jpeg image is rotated at 90 CCW and the original TIFF image is rotated at 90 CW.
They have same exif orientation tag '90 CW' but the one is in jpeg and the other is in tiff format.
I have tested with pillow and opencv and both produce correctly oriented results.
It looks to me that the reason for this is that they apply 90 CW for jpeg and 90 CCW rotation for tiff format.
In other words, for tiff rotation should be in opposite direction.

[fmw42]

What viewer did you use to examine the images? When I strip the meta data for your JPG image and view the results in Imagemagick, the RightTop corner of the image is in the LeftTop position. So it has been rotated 90 CCW and needs to be rotated 90 CW. I might have referenced that backwards before.

Nevertheless, Imagemagick is auto-orienting the image properly when viewed with Imagemagick display. And the original is viewed by Imagemagick with its RightTop corner in the LeftTop position indicating it needs rotating 90 CW

[fpgamaster]

I use Safari and Chrome but always strip the exif data.

[fmw42]

See my edited comment above. Mac Preview seems to auto-orient automatically, because both the input and the auto-oriented versions (not stripped) are viewed with it correctly. Some viewers do that automatically, such as Mac Preview and on my Safari.

[fpgamaster]

Yes, for jpeg ImageMagick produces correct results but not for tiff.

[fmw42]

It works properly unstripped for me in Safari because Safari does the auto-orient automatically when viewing. So I do not understand how you view it correctly after stripping unless ...

Might you be stripping after it has been corrected by these tools automatically?

[fpgamaster]

I strip the exif of original images only to verify their actual orientation.
The exif info is needed for the auto rotation but after that it is stripped.

[fpgamaster]

As of my understanding the exif orientation tag has different meanings for jpeg and tiff formats:

• JPEG: rotate to position
• TIFF: The position at which the image is captured

[fmw42]

After auto-orient, there is no need to strip. As for differences between tiff and jpg, if the both use the exif standard, then they would be the same. I cannot believe that they would not be following the standard.

[fmw42]

If you see a difference in the text representation, then that is either because one is say how the image is mis-rotated and the other is saying how it should be rotated to correct it. Those would be just the opposite directions.

[fpgamaster]

I am still trying to find some trustful information about such a difference but you see how Apple and some other imaging softwares are handling tiff orientation.
It will be nice if you can find some tiff (dng) samples from other vendors.

[fpgamaster]

These issues may be related or have tiff samples:
#5231
#5183

[fmw42]

Both files (your JPG and your TIFF) are displayed properly when you preface your tiff with dng: or change the suffix to .dng. It show up wrong when I display without the preface. Is that TIFF really DNG?

magick display pwhc7j1vpy7h_orig.tiff shows with LeftBottom at 0,0 (so would need 90 CCW to correct) and displays wrong (upside down) after correction because the exif orientation say RightTop

magick display dng:pwhc7j1vpy7h_orig.tiff. show with RightTop at 0,0 (so would need 90 CW to correct) and is corrected as the exif orientation says RightTop.

Sorry, I do not know why the behave opposite. I know that DNG follows the TIFF format. But there must be some coding differences that control this difference according to whether Imagemagick knows it is actually DNG or TIFF from the suffix (or DNG: preface). That is a question for one of the Imagemagick developers or user who know more about DNG vs TIFF than I do.

[fpgamaster]

The file suffix does not matter and should not be used to determine the file type. See the output below:

file pwhc7j1vpy7h

pwhc7j1vpy7h: TIFF image data, big-endian, direntries=32, height=0, bps=0, compression=JPEG, PhotometricInterpretation=YCbCr, manufacturer=Apple, model=iPhone 12 Pro, orientation=upper-right, width=0

exiftool pwhc7j1vpy7h

File Type                       : DNG
File Type Extension             : dng
MIME Type                       : image/x-adobe-dng
Exif Byte Order                 : Big-endian (Motorola, MM)
Make                            : Apple

[dlemstra]

It looks like this file is a raw file pretending to be a tiff. I just pushed a patch that will detect from the header of the image that it is a raw file:

identify pwhc7j1vpy7h.tiff
pwhc7j1vpy7h.tiff RAW 4032x3024 4032x3024+0+0 16-bit sRGB 34.7465MiB 0.001u 0:00.001

This will become available in the next release.

[fpgamaster]

Actually, the file pwhc7j1vpy7h was something with .dng extension and the exiftool reports it as a DNG file type.
I have applied your patch but can not see any difference.

[fmw42]

Did you read my comments above showing that the tiff file was miss-labeled and was really dng. When using as dng, it auto-oriented fine.

[fpgamaster]

How to tell to this function something related to your explanation?

/*
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                                             %
%                                                                             %
%                                                                             %
%   M a g i c k R e a d I m a g e B l o b                                     %
%                                                                             %
%                                                                             %
%                                                                             %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                                              
%  MagickReadImageBlob() reads an image or image sequence from a blob.
%  In all other respects it is like MagickReadImage().
%                                                                              
%  The format of the MagickReadImageBlob method is:
%  
%      MagickBooleanType MagickReadImageBlob(MagickWand *wand,
%        const void *blob,const size_t length)
%  
%  A description of each parameter follows:
%                                                                              
%    o wand: the magick wand.
%                                                                              
%    o blob: the blob.
%  
%    o length: the blob length.
%  
*/

[fmw42]

What does this have to do with auto-orient? Are you reading a blob or an image format? Please clarify.

[fpgamaster]

Please, ask someone of developers to take a look at this issue or close it!
After more than two decades, my choice is about to change.