Why do PTGui 9 and APG 2.5 wrongly rotate some inputted .CR2 image?

... and why do they not rotate the very same image (simutaneously saved in the camera in JPG) when both are simultaneously and directly inputted from the camera compact flash card?

Note: the question is answered but the problem still remains unsolved. Read the Update at the bottom of that page.

The camera Auto-rotation is shut OFF, thus no image should be rotated!

Precedent observations when using current PTGui or APG versions:

  1. To not have problem, I always set the camera (EOS 5DmkII) auto-rotation option in "OFF" position.
  2. No normal "horizontally shot" landscape mode image is affected. All normal "horizontally shot" portrait mode image are affected.
  3. Very important: the flaw may happen for some but not necesserarily for all of the Nadir shots of a same sequence. I guess that physical detection of camera /lens verticality is involved.
    The images are not rotated when displayed on screen with Mac OS "finder" or any other application that supports .CR2 on my iMac.
    Important exception: AutoPanoGiga v2.5 behaves exactly the same as PTGuiPro 9.
  4. The problem may only be only with images shot with "manual lenses" (i.e. without electrical connection at all with the camera). Not certain at all about that though.

BTW the 5D2 writes "50 mm" as the default focal lens when using a manual lens and I don't know how to change this in the camera. Does somebody knows how to change this arbitrary "50 mm" in the camera( firmware) settings? All my other cameras (incl. several EOS) write "0 mm" that is IMO preferable.

I could not find an indication of the reason of the flaw by comparing the EXIF of the different images with exiftool. After conversion of the EXIF lists into PDF I have used the comparison tool of Adobe Acrobat CS4 to check: no pertinent metadata could be traced that I could attribute to be the cause:-(

Wishing to stop here the suppositions, I have then to stop guessing and decided to investigate more systematically and report my findings....

Specific test and possible decisive experimentation:

Forgoing the vertical shooting (for Nadir and or Zenith) that produces random failure only and as Portrait Vs Landscape type of shooting seemed to be a consistant decisive parameter, I have shot successively with three camera different settings:

Each set of images is composed of (2 x 2) files as the photos were each recorded in JPG + .CR2 in the camera and in Landscape (L) first and secondly in Portrait (P) respectively.

In total there were 2 x 2x 3 = 12 images viewed in Bridge CS4 on my iMac screen:

I have then inputted those 12 images simultaneously in PTGui 9.0.1, PTGui 8.3.10, APG v2.5-RC and APG v2.0.9.

PTGui

Please notice the orientation (P or L) of the shots and (.CR2 or JPG) of the image format. One image of the "NO Auto-rotation" group is oriented differently than on all other application. Compare with Apple's Mac OSX" Finder" (click on the pict to enlarge):

Despite the "NO AUTO-ROTATION" specified by the camera, when the shot is taken in portrait mode, the image is rotated in portrait presentation!

Let's compare PTGui 9 Vs PTGui 8 (click on the following pict to enlarge):

That was not a problem with PTGui 8!

AutoPanoGiga

On a single figure APG v2.0.9 and APG v2.5RC are compared with Apple's finder window (click on the pict to enlarge):

 

EXIF of RAW images:

Here is a PDF document where the EXIF of IMG_0387.CR2 and IMG_0386.CR2 are listed (exiftool was used for the extraction). The EXIF show the very same line {Auto Rotate : Rotated by Software}both for IMG_0387.CR2 and IMG_0386.CR2 but they are treated differently by PTGui and APP...

 

Overview and conclusion:

When the auto-rotation is set on "OFF" on the EOS 5D2 and when the shot is not simultaneously aimed horizontally and in landscape mode, a wrong rotation of the .CR2 image may happen (but not always). Verticality detection by the camera may thus be involved and there is most probably a common failure cause that affects PTGui and APP (current versions only).

I was not able to find the root cause by using exiftool for investigation. As both stitching applications probably use dcraw for RAW file support, I assume that there lies the origin of the problem.

UPDATE (27 January 2011)

The answer to the question in the title of this article was given to me by Erik Krause. Thank again Erik.

YES, the problem comes from dcraw. Erik wrote:
<< dcraw uses the Canon Makernotes "CameraOrientation" flag (which can't be switched off), not the EXIF Orientation (which contains the correct value). I already complained to Dave Coffin.>>

To verify his statement I had to open Windows XP on the Mac and then run exiftoolgui.exe. Here it is: "CameraOrientation" in the Tag Name column and the rotation in the MakerNotes of the Content column!
I could not find "CameraOrientation" in the standard whole "ExifTool" extracted list by simply executing a shell in the Terminal of the Mac... I might thus have to learn how to use it better to get the most of it.

 

Michel Thoby

26 January 2011.