Closed: Incorrect image rotation

[Hayo Baan]

I recently noticed something odd: some of my pictures show incorrectly rotated, both as thumbnail and in the preview window. What is strange is that the problem only affects some images, not all. Even if they were taken around the same time and with the same camera. PM5 displays these images correctly.

Looking at the metadata of the files I can't really see why one image is displayed correctly and the other isn't. They were written by different versions of Nikon Capture NX, but the embedded preview in both cases has the correct size/rotation. The only difference I found was that the image displaying incorrectly has “PhotoMechanic” metadata while the correctly displayed one doesn't (which is not strange since I likely edited the metadata of one at a different point in time). So somehow the existence of the crop info in the metadata makes PM6 incorrectly interpret the preview data. To test this, I removed the PhotoMechanic group data from the file with exiftool and indeed, now it is displayed correctly in both PM5 and PM6!

Hopefully this can be fixed easily.

Here's the metadata in the PhotoMechanic group that causes the incorrect rotation (output from exiftool):

Code: [Select]

[PhotoMechanic] Color Class                     : 0 (None)
[PhotoMechanic] Preview Crop Bottom             : 100.000%
[PhotoMechanic] Preview Crop Left               : 0.000%
[PhotoMechanic] Preview Crop Right              : 100.000%
[PhotoMechanic] Preview Crop Top                : 0.000%
[PhotoMechanic] Rating                          : 4
[PhotoMechanic] Raw Crop Bottom                 : 100.000%
[PhotoMechanic] Raw Crop Left                   : 0.000%
[PhotoMechanic] Raw Crop Right                  : 100.000%
[PhotoMechanic] Raw Crop Top                    : 0.000%
[PhotoMechanic] Rotation                        : 0
[PhotoMechanic] Tagged                          : No

[Kirk Baker]

Hayo,

I recently noticed something odd: some of my pictures show incorrectly rotated, both as thumbnail and in the preview window. What is strange is that the problem only affects some images, not all. Even if they were taken around the same time and with the same camera. PM5 displays these images correctly.

Looking at the metadata of the files I can't really see why one image is displayed correctly and the other isn't. They were written by different versions of Nikon Capture NX, but the embedded preview in both cases has the correct size/rotation. The only difference I found was that the image displaying incorrectly has “PhotoMechanic” metadata while the correctly displayed one doesn't (which is not strange since I likely edited the metadata of one at a different point in time). So somehow the existence of the crop info in the metadata makes PM6 incorrectly interpret the preview data. To test this, I removed the PhotoMechanic group data from the file with exiftool and indeed, now it is displayed correctly in both PM5 and PM6!

Hopefully this can be fixed easily.

Here's the metadata in the PhotoMechanic group that causes the incorrect rotation (output from exiftool):

Code: [Select]

[PhotoMechanic] Color Class                     : 0 (None)
[PhotoMechanic] Preview Crop Bottom             : 100.000%
[PhotoMechanic] Preview Crop Left               : 0.000%
[PhotoMechanic] Preview Crop Right              : 100.000%
[PhotoMechanic] Preview Crop Top                : 0.000%
[PhotoMechanic] Rating                          : 4
[PhotoMechanic] Raw Crop Bottom                 : 100.000%
[PhotoMechanic] Raw Crop Left                   : 0.000%
[PhotoMechanic] Raw Crop Right                  : 100.000%
[PhotoMechanic] Raw Crop Top                    : 0.000%
[PhotoMechanic] Rotation                        : 0
[PhotoMechanic] Tagged                          : No

Probably can be fixed easily.  Can you share an image that already has the metadata that reproduces the problem, please?

Thanks,

-Kirk

[Hayo Baan]

Hi Kirk, sure, just uploaded “wrong_rotation.nef” to your ftp-server.

Interesting note: “touching” the file in a way that makes PM update the metadata of the file resets the rotation to the correct way too. Even simply hitting 0 to set the colour class to none (which it already was!) resets the rotation Looking at the metadata, the updated file has the PhotoMechanic crop info removed, so it looks like this really is the issue.

PS. the file actually seems to have a minor metadata issue (exiftool reports “Warning: Ignored bad IFD linked from SubIFD”), but I don't think that has to do with the issue. In fact having exiftool rewrite the file (fixing the issue) without removing the PhotoMechanic crop info still has PM6 render it with the wrong rotation.

[dennis]

Hayo,

Good ol' CNX2.

Nikon (or should I say "Nik") decided to totally rewrite NEF files that are edited of course, and CNX2 rotates the thumbnail and preview JPGs if the image is rotated (the RAW data is left as-is "unrotated").  This caused a lot of grief for PM.  CNX2 also applies any crop to the new preview which introduces another whole set of issues (Did you know you can add another "draft crop" in PM on top of the crop made in CNX2?  Only PM will recognize this secondary "draft" crop because it doesn't apply to the original NEF raw data).

Normally a NEF out of camera only sets the TIFF rotation tag and leaves the thumbs/previews un-rotated (and otherwise intact).  When updating PM6 a little while back I changed the ordering of some code and neglected to inspect the comment (which included your name BTW) about loading the old EOF preferences (which could contain a rotation and crop) BEFORE handling CNX2's special "rawInfo" (which also contains a rotation).

I've put back the ordering of the code to match PM5 and this fixes the problem.

I suspect that if you have a lot of photos with this problem, just select them all and use the Delete Metadata Tool to remove EOF Prefs.  We no longer write these ancient prefs (everything is now in XMP), and so your simple "touch" had the side effect of deleting the EOF Prefs.

We'll make a new build with this fix later but if you want the link let me know (it will also be fixed in PM Plus beta coming by Friday).

Best,

--dennis

[Hayo Baan]

Hi Dennis,

Interesting! Who would have thought such a thing could revenge itself. Funny that apparently it only goes wrong with files that (also) have the now quite old and obsolete PM EOF preferences set. Yeah, these files have not been touched in a while

Regarding the difficulty caused by CNX2 rewriting the file with an updated preview (and which already has the crop and rotation applied), doesn't that problem exist with all applications that write an updated preview to the file (e.g. DNG)? I remember from the past that you had to prevent the crops from showing “double”. Perhaps you have my name in the comments there too

Unless there is more stuff I can pre-test for you, there is no need to provide a special build for me; the images cause no trouble to me now so I can wait till end of the week easily. (Note that I'd rather not touch the files to remove the EOF marker since that will mean an unnecessary (backup) file update).

By the way, I know I can (soft) re-crop an already cropped image with PM. I never do so though; I do all my cropping in the image editor of my choice (currently a combination of ACR and Lightroom) and have that update the embedded preview.

[dennis]

Regarding the difficulty caused by CNX2 rewriting the file with an updated preview (and which already has the crop and rotation applied), doesn't that problem exist with all applications that write an updated preview to the file (e.g. DNG)?

Unfortunately yes DNG files also have this issue with preview being cropped.  It would be nice if they kept the full image size, unrotated, but with toning adjustments only.  Let the software editing these DNG files apply the crop or be able to change the crop (e.g. expand it) and see the resulting toned pixels.

Oh well!

[Hayo Baan]

Err, what you say in your last post is quite against the logic of updating the preview image to reflect the edits. And in fact would be quite impossible to do properly in case of e.g. heavy transform, where it would even be possible to get more pixels than you had before (how could they keep the image the same size in this case?). And how about pano merges?

No, the fact that the preview IS the image after all edits, transforms, crops, etc. have been applied is exactly what you want! That way smart software (like PM) can make use of that to show what the image looks like, including the edits. It would completely break my workflow (and render PM useless to me) if this wasn’t the case...

It was a prime reason for me to switch to a DNG-based workflow.

[Kirk Baker]

Hayo,

Err, what you say in your last post is quite against the logic of updating the preview image to reflect the edits. And in fact would be quite impossible to do properly in case of e.g. heavy transform, where it would even be possible to get more pixels than you had before (how could they keep the image the same size in this case?). And how about pano merges?

No, the fact that the preview IS the image after all edits, transforms, crops, etc. have been applied is exactly what you want! That way smart software (like PM) can make use of that to show what the image looks like, including the edits. It would completely break my workflow (and render PM useless to me) if this wasn’t the case...

It was a prime reason for me to switch to a DNG-based workflow.

The problem is that you can then never crop the image again in PM because the preview is already cropped.  If you then take the image with the crop applied to one of Adobe's apps then the crop is incorrect because it is based on the cropped preview.

-Kirk

[Hayo Baan]

True, I see that, and it makes sense you can't recrop the image. Or actually, you can, but then only PM would (should) be able to work with that additional crop. I think that's how it is working now anyway (never tried to be honest; don't use PM to crop at all).

(I guess there would even be a clever way to change the existing crop values to "merge" the additional crop, but that's likely more hassle/error prone than is worth it)

Anyway, the 3328 PM+ beta solves the rotation issue. This, of course, requires a re-build of the catalog proxies, but that I already have to do to be able to get them properly colour managed. This has not yet been fixed though, so I'll not do that yet…