Image rotation issues after export from DXO

[hluxem]

Hello DxO users, have you ever had problems with file orientation of exported portrait images when adding face tags?

I have seen portrait files rotated wrongly, fixed them, but after writing back meta data they changed again. Usually that happened when I added face tags to the images.
Never been able to make good sense of what is happening, so today I decided to start with 2 sample pictures.

I downloaded several portrait pictures from my phone using Windows Explorer.
Next I created a test data base, the portrait pictures are displayed correct. Below is what the meta data app shows.

Make (IFD0): motorola
Model (IFD0): moto z4
Orientation (IFD0): 6
Orientation (IFD1): 6
XMP-tiff Orientation in Database: Rotate 90 CW

After export from DXO the images still display correctly, but IFD0 and IFD 1 are now different.

Software (IFD0): DxO PhotoLab 2.3.2
Orientation (IFD0): Horizontal (normal)
Orientation (IFD1): 6
Different EXIF orientation values. IFD0: 1, IFD1: 6
XMP-tiff Orientation in Database: Rotate 90 CW

If I change a rating and write back meta data, the file still shows ok, the values don't change and are still different. So even that there are different/wrong values in the orientation field, it's not showing.

That changes when I add a face tag to the image. After write back the picture turns and is displayed in the wrong orientation.
The meta data app shows that the values are now the same, just as with the original pictures.
In the past I set the Exif rotation to normal and everything looked good. What made matters so confusing is that it flipped again after another write back. It's also nothing you notice if you only look at the thumbnails as they stay the same.

I think DXO changes the IFD0 tag during the export to 1, normal orientation. I assume that DXO should have changed the IFD1 tag and maybe other tags to normal orientation as well.

What is the best way to synchronize these tags, can the IFD1 tags be deleted or do I need to set them with a metadata template?
Are there any other tags involved I need to check?

I attached a file exported from DXO showing correctly and one exported and a face tag added showing wrong.

Thanks a lot,

Heiner

[jcldl]

Yes I had exactly the same problem with many pictures after using DXO. Now I use Capture One and there is no more problems.

[mopperle]

Heiner, while your DXO PL version seems to be quite outdated (current is 3.2), have you asked DxO? Maybe it has been solved meanwhile.

[hluxem]

have you asked DxO

When I started looking into this it wasn't quite clear that DxO is causing this.
Thanks for pointing out that I used the old version. I did add the wrong short cut to the favorites. I verified with the last version and see the same issue.
I will open a support ticket with DxO.

I found that the ifd1 tags are used for an embedded thumbnail in the jpg file which seems to be not used much. It did say that the orientation needs to be the same. I think DxO is not even touching the thumbnail section in the Exif data and that's why there are different orientation tags.

The following command will remove the thumbnail section from the jpg file.

-ifd1:all=
{Files}

I want to do some more testing, but it looks like this works and solves my issues.

[Mario]

By the looks of it, the problem is that the 'wrong' rotation is in the XMP Tiff orientation tag.

DxO (or whatever leaves the toolkit name XMP Core 5.5.0) in the file has written a minimal XMP record. Consisting only of the toolkit name and a wrong (!) XMP orientation.

IMatch imports the metadata from the file, including the wrong orientation from the XMP record (existing EXIF XMP overrides EXIF data).
When IMatch writes back metadata, XMP is synchronized with the EXIF in the file.  And this sets the EXIF from the wrong XMP orientation.

When you strip the XMP from the image and then force a re-import in ECP, things should be OK. Because now IMatch creates the XMP orientation itself, from the correct IFD. That should work.

Other metadata issues reported for the "DxO" file by the Metadata Mechanic:

EXIF
Different EXIF orientation values. IFD0: 1, IFD1: 6

XMP
[ExifIFD]:DateTimeOriginal not mapped to [XMP-exif]:DateTimeOriginal (embedded).
[ExifIFD]:CreateDate not mapped to [XMP-xmp]:CreateDate (embedded).
[ExifIFD]:DateTimeOriginal not mapped to [XMP-photoshop]:DateCreated (embedded).
[GPS]:GPSLatitude not mapped to [XMP-exif]:GPSLatitude (embedded).
[GPS]:GPSLongitude not mapped to [XMP-exif]:GPSLongitude (embedded).

Detailed Validation

Non-standard format (int8u) for ExifIFD 0xa301 SceneType
Wrong IFD for 0xa002 ExifImageWidth (should be ExifIFD not IFD1)
Non-standard format (int32u) for IFD1 0xa002 ExifImageWidth
Wrong IFD for 0xa003 ExifImageHeight (should be ExifIFD not IFD1)
Non-standard format (int32u) for IFD1 0xa003 ExifImageHeight
Missing required JPEG GPS tag 0x0000 GPSVersionID

[JohnZeman]

Just to add my 2 cents worth.....Are you using versions in IMatch?

I use DxO PhotoLab but I'm not yet using face tagging so my post may not be relevant to your problem but I'll mention it just in case it might be.

A couple months ago I had an orientation problem when exporting my CR2 raw portrait images from PhotoLab.  The exported JPG versions were always rotated incorrectly.  After a lot of testing I reached the conclusion that JPGs should always have normal orientation, that is no rotation even if it's a portrait image.

Long story short it was my IMatch Edit > Preferences > File Relations > CR2 Versioning configuration.  I needed to needed to check the box for Don't Copy XMP Orientation from the master CR2 to the version JPG.  Once I did that my problem was solved and it hasn't returned since.

[hluxem]

Hello all,
Thanks for all the input.

By the looks of it, the problem is that the 'wrong' rotation is in the XMP Tiff orientation tag.

This is certainly true, and I thought another way to fix the issue is to change that tag. But it looks like it's not sticking, when I write back it reverts to the old value. The change will only stay if I delete the IFD1 tag.

The common thing for all files displayed in the wrong orientation is that there is an IDF0 and an IDF1 tag. I see the problem even with files directly from phone or camera.

If I change the exif orientation for one of these files with Imatch, the xmp orientation will not change and I just created a 'wrong' orientation tag. Changing and writing back meta data like rating or adding GPS data to a file will not change either orientation tag. But the good thing is it will not change the way the file is displayed either.   

And this sets the EXIF from the wrong XMP orientation

This happens only when a face annotation (personinimage?) is written back. At this point it looks like the wrong orientation either from the IDF1 tag or the xmp tag is propagated to the exif tag.

My conclusion so far is that the best way is to remove the IDF1 tags.

Thanks,
Heiner

[Mario]

Remove the XMP. IMatch then produces the correct XMP on re-import.

[hluxem]

Remove the XMP. IMatch then produces the correct XMP on re-import.

I assume that means to use the exif tool command with the preset "Delete XMP Metadata". I tried that but it is not working.

While it is certainly an issue with files processed with DXO, I can get the same effect with pictures straight of a camera or phone.
It happens when a file has an IFD0 and IFD1 tag. If they are directly from the camera they have the same value. 
Take one of these files and change the exif rotation. Both tags become different. After deleting the xmp data the tags are still different. Could it be that the xmp tag is created from the IDF1 tag which is not updated during the rotation?

If you take the rotated file, add a face tag and write back the change, the image will rotate back. The exif tag is changed and now the same as the xmp and IDF1 tag. It will not rotate when you add and write back a rating or GPS data. 

Once I delete the IDF1 tag this problem is gone. I will go forward with that solution.

Keep in mind, this issue only shows in connection with face tags. I certainly was puzzled and kept manually rotating them back, never figured out what happened and why. I found at least 2 cameras and 1 phone having both tags. When these images are rotated, adding a face tag will rotate the image back. There maybe more users seeing the same issue in the future when they start using face tags.

Thanks,

Heiner

[Mario]

This is not related to face tags. It is related to ExifTool mapping the XMP orientation back into EXIF during write-back.
I could produce the problem with the DxO file you have provided by just adding a rating and writing back. Since the XMP in the image does not match the correct orientation of the image on import, it will also be false on export. Hence, deleting the wrong XMP written by DxO and then forcing a re-import fixed the problem. Because not the orientation in XMP is correct.

If you have another method that works, good.

Usually the EXIF should never be wrong and always reflect the correct orientation of the image IFD0 and thumbnail (in case of JPEG) in IDF1. And the JPEG data and thumbnail data should use the same orientation. Some cameras store the thumbnail always in neutral rotation, even if the image itself must be rotated for display.

[abgestumpft]

Hi,

I also have an issue with DXO Photolab 3.2 and iMatch 20.3.4 and rotation/faces with potrait rotation RAW files (.ORF).
I'm currently using the iMatch RAW processor because of the known problem with WIC codecs and Olympus ORF Rotation (should be fixed in next iMatch version)

What I see is:
I process a RAW file that is in portrait rotation and has face assigned (assigned by iMatch and stored in XMP) in DXO Photolab 3.2 and export it as .JPG.
Then this file is loaded by iMatch: the image is still shown in correct rotation, but the face box is in wrong position (looks like applied with 90° rotation)

RAW file info in iMatch how it was passed to DXO:

Code Select Expand


[XMP-mwg-rs]    Region Applied To Dimensions H  : 2400.000000
[XMP-mwg-rs]    Region Applied To Dimensions Unit: pixel
[XMP-mwg-rs]    Region Applied To Dimensions W  : 3200.000000
[XMP-mwg-rs]    Region Area H                   : 0.296667
[XMP-mwg-rs]    Region Area Unit                : normalized
[XMP-mwg-rs]    Region Area W                   : 0.223000
[XMP-mwg-rs]    Region Area X                   : 0.572000
[XMP-mwg-rs]    Region Area Y                   : 0.603667
[XMP-mwg-rs]    Region Name                     : Persons Name
[XMP-mwg-rs]    Region Type                     : Face
...
[XMP-tiff]      Orientation                     : Rotate 270 CW
[IFD0]          Orientation                     : Rotate 270 CW



JPEG produced by DXO:

Code Select Expand


[XMP-mwg-rs]    Region Applied To Dimensions H  : 2400.000000
[XMP-mwg-rs]    Region Applied To Dimensions Unit: pixel
[XMP-mwg-rs]    Region Applied To Dimensions W  : 3200.000000
[XMP-mwg-rs]    Region Area H                   : 0.296667
[XMP-mwg-rs]    Region Area Unit                : normalized
[XMP-mwg-rs]    Region Area W                   : 0.223000
[XMP-mwg-rs]    Region Area X                   : 0.572000
[XMP-mwg-rs]    Region Area Y                   : 0.603667
[XMP-mwg-rs]    Region Name                     : Persons Name
[XMP-mwg-rs]    Region Type                     : Face

[XMP-tiff]      Orientation                     : Horizontal (normal)
[IFD0]          Orientation                     : Horizontal (normal)


The Data for the face area is the same, but orientation flag was changed.

What I think what happened:
DXO is physically rotating the file and then changing the orientation from 270 CW to Horizontal (-> still shown with correct rotation in iMatch).
But it keeps the face area data coordinates / size and together with changed rotation the box is now in a different position.

[abgestumpft]

FYI:
I have exactly same behaviour with JPGs from Capture One 20:
1. Load a RAW file with Portrait Orientation and Face Tag in Capture One
2. Capture one processes to JPG
3. iMatch loads that JPG

Now (like with DXO), I see the JPG in correct orientation, but the face tag is in wrong position (90° rotated)
Seems like Capture One is also rotating the image (but does not provide any rotation information at all: no "Orientation" set):

Code Select Expand


[XMP-mwg-rs]    Region Applied To Dimensions H  : 2400.000000
[XMP-mwg-rs]    Region Applied To Dimensions Unit: pixel
[XMP-mwg-rs]    Region Applied To Dimensions W  : 3200.000000
[XMP-mwg-rs]    Region Name                     : Persons Name
[XMP-mwg-rs]    Region Type                     : Face
[XMP-mwg-rs]    Region Area H                   : 0.296667
[XMP-mwg-rs]    Region Area Unit                : normalized
[XMP-mwg-rs]    Region Area W                   : 0.223000
[XMP-mwg-rs]    Region Area X                   : 0.572000
[XMP-mwg-rs]    Region Area Y                   : 0.603667



[bekesizl]

I reported a bug to DxO some time ago, that they are handling face regions wrongly, although my issue wasn't orientation, but position and size.
When I applied crop to an image that was face tagged before (in my case in Mylio, but that doesn't matter here), the exported jpg inherited the original tag positions.

The reply from DxO was, that they are pretty much taking the content of the XMP sidecar as is and putting it into the exported file.
It is usually useful, as keywords, GPS location and other information are carried with the export.

But in case of face regions, the coordinates should be transformed with the image transformation or filtered out.
They said, they will consider it. They also said, that they

don't have an exhaustive (and futurproof) knowledge of all these fields set by any third party software

, although in the case of face regions and face tags it is probably straightforward, which XMP tags are used.
At least IMatch 2019 was able to read the face tags created by Mylio

See my thread at the DxO forum.
https://feedback.dxo.com/t/bug-incorrect-export-of-face-regions-to-jpg/11387

Then I found a workaround in Mylio: I can delete all face tags of selected images with a command (the originals exported by DxO) and tag them again.

If you feel like, you can revive my thread and report this issue there. If you don't want to, please tell me and I will test it with Mylio and report it.

[jch2103]

This raises an important workflow question: Should face recognition be deferred for all raw images where cropping may later be involved (whatever the raw processing program). More generally, should face recognition be performed only after raw processing (on both the raw and output images)?

[Mario]

Always run it on the final image. Same as metadata. Avoids many problems and pitfalls.

[Mario]

Then I found a workaround in Mylio: I can delete all face tags of selected images with a command (the originals exported by DxO) and tag them again.

You can do that easily in IMatch too. No need to add Mylio to your workflow. Keep in mind that Mylio has only very sparse support for metadata and may cause issues not even IMatch can fix afterwards.

[abgestumpft]

@bekesizl
I have now replied to your thread in the DXO Forum.
The region tag has a relative position to the top left corner. So if DXO is rotating the image they should adjust the coordinates accordingly.
I'm not too optimistic, but we shall see :-)

[Mario]

Not even IMatch rotates face annotations when you change the EXIF orientation info. Too complicated. To many edge cases.
I recommend to do face recognition only after you have decided how to rotate the image. It makes no sense before.

[abgestumpft]

I recommend to do face recognition only after you have decided how to rotate the image

I am not rotating anything. What happens is when I process RAW files that where shot in portrait orientation with DXO (or Capture One) those are exported by a rotated version (and Orientation flag changed to "Horizontal". They keep the face region data 1:1 and therefore the position is now wrong.

This means that RAW files in portrait orientation with face tags will always have wrong positioned face tags after they have been processed by DXO / Capture One (except when the face is exaclty in the middle  ).

[Mario]

So the other software messes up the EXIF orientation?
You can fix that in IMatch before doing face recog.

[abgestumpft]

What I think what happens is this (behaviour is same with iMatch and Lightroom):

1. I have a RAW file shot in Portrait: the pixels are stored in horizontal orientation, but "270 CW" orientation is set -> shown in correct orientation in iMatch, Lightroom,...
2. Then I tag a face, and it is tagged with the coordinates relative to the upper left corner and stored in XMP
3. I open that file in DXO (or Capture One) and just export it as JPG (I don't rotate the image)
4. But then both DXO and Capture One automatically physically rotate the image to portrait orientation (and set orientation to "Horizontal (normal)"). They keep the XMP data 1:1, so the relative coordinates of the face region are still the same -> wrong position
5. The JPG is then loaded into iMatch and orientation is shown correct (it is now a JPG stored in portrait mode and no rotation applied), but the face box is now off because the coordinates are still the "old" ones.

See how the XMP tags change in my previous post here: https://www.photools.com/community/index.php?topic=9905.msg70102#msg70102

I tested this with:
iMatch <-> DXO
iMatch <-> Capture One
Lighroom <-> DXO

And everytime the face box is in wrong position after handling a file in portrait orientation.

[abgestumpft]

Here a quick example:
Penguin RAW = Face box in iMatch before passing it to DXO
Penguin JPG DXO = Face box in iMatch of the processed JPG via DXO

As you can see the box is now misplaced (and also squeezed a little bit because of the percentual size to image height/width)