Integrating Dx0 with PS

[Ruhell]

Hi Stephen
I looked into the maker tab of ExiftollGUI, and on the jpg/tif out of DPP4 I didn't find any info about orientation.
On the CR2 raw file and the two out of DxO10 I found "CameraOrientation Rotate 270 CW"

[Stephen]

I didn't study this thread in detail, but my point is that some software apps change the maker notes. You might like to look at original files out of the camera before they have passed through any software and then compare them at each stage of your workflow.

[jstartin]

I think that it is not the Maker Notes that are important (they are not standardised and are not intended to exchange information), but rather the rotation tag in the standard "as per specs" Exif (which can be considered as an instruction). Some software reads this and rotates the displayed image accordingly and some does not. Some software, when asked to rotate an image, just changes the tag, but this is ignored by some other software! Some software rotates the image itself (either losslessly or not) but fails to update the tag to match so that other, rotation-aware, software then displays the image wrong! And so on.
As this is a "workflow" type issue there doesn't seem to be any proper standardisation and incompatibility is pretty much assured.

[Stephen]

That's it, Jim, imho!
BTW, Ruhell, you can auto rotate the images when importing into PSu if you wish. It's below "Verify Ingested Images", but only visible when you select "more copy settings".

[Mke]

I've also found that PSU sometimes fails to heed DxO's rotation too. Often it's resolved by selecting the relevant files in PSU, right clicking and selecting Metadata -> Convert Metadata to XMP, followed by Operations -> Rebuild Selected Thumbnails. Occasionally that doesn't work and I spin the files around in Windows Photo Viewer, then repeat the above. Strange, but not a major issue for me.

On the larger topic, my workflow isn't far off Frank's. The main difference is that (due to the idiosyncratic way that PSU currently cascades metadata and because I don't use sidecars in PSU), I've taken to assigning all labels and applying all details, GPS, etc to the RAW files in PSU before I process them in DxO. That way the metadata is embedded in the JPEGs when DxO generates them, so avoiding the need for any cascading.

[fbungarz]

I've taken to assigning all labels and applying all details, GPS, etc to the RAW files in PSU before I process them in DxO. That way the metadata is embedded in the JPEGs when DxO generates them, so avoiding the need for any cascading.

BTW - that is what I typically do as well. Nevertheless - the issues discussed here regarding the rotation tags show that even DxO apparently modifies some of the metadata. Not as big of a deal as PhaseOne, which apparently completely deletes lens information, but still...
That's why it generally might not be a bad idea to use the cascade metadata script to recover anything that arbitrarily got changed.
However, the claim that the script really cascades ALL technical metadata does not even seem to be 100% accurate. In a recent discussion sanphotgn manually versioned a Canon JPG as a subversion of a Nikon NEF and used the script to cascade the metadata from the Nikon to the Canon file. He says that two metadata fields did not get cascaded: ColorSpace and FlashFunctionPresent.
(here the link to that post: http://forum.idimager.com/viewtopic.php ... 7&start=30)
This is a bit disconcerting if someone specifically uses that script to recover potentially overwritten technical metadata.

@Ruhell - have you tested what happens with that tag when you cascade the original info back into the files processed by DxO?

[Mke]

the issues discussed here regarding the rotation tags show that even DxO apparently modifies some of the metadata

That's not exactly the case for me; many (maybe all) of the images involved are ones that I've deliberately shot as RAW files with the 'wrong' orientation. I leave the RAWs as shot (with the 'wrong' orientation) in PSU and rotate the JPEGs only in DxO, so in my case it seems that DxO may be writing the orientation metadata incorrectly, rather than modifying pre-existing metadata. (Since it's not been a major issue and I'm often pressed for time, I've not probed exactly what the problem is - now it's come up here I'll try to do so next time it happens).

The bigger issue for me after adopting this workflow was with PSU, not DXO, when I discovered that PSU was deleting metadata from the RAW files on versioning the JPEGs. Thankfully this is was rapidly patched after I reported it - see http://mantis.idimager.com/view.php?id=3062. Frank, you might want to check if your data has been affected by this if you've been following a similar workflow to me, since cascading from RAW to JPEG may not have done as you expected, if the some of your RAW data was deleted before your cascade.

[fbungarz]

The bigger issue for me after adopting this workflow was with PSU, not DXO, when I discovered that PSU was deleting metadata from the RAW files on versioning the JPEGs. Thankfully this is was rapidly patched...

Thanks for pointing that out. However, I don't think I was ever affected by this. I have only recently been using DxO more frequently.
I initially purchased Version 10 a little over a year ago, but constantly ran into problems with DNGs opening with a very weird color cast. DxO only fixed this now in version 11 and it has only been a couple of weeks since I have started using it more extensively...

[Mke]

in my case it seems that DxO may be writing the orientation metadata incorrectly, rather than modifying pre-existing metadata.

Or could be that DxO is writing the orientation to EXIF, and PSU is reading the XMP value, or similar...

[Mke]

Or could be that DxO is writing the orientation to EXIF, and PSU is reading the XMP value, or similar...

Well I was very close.
Over the last couple of days I've imported CR2s and JPEGs generated from them in DxO and there was no orientation problem.
I also imported a batch or smartphone images shot as JPEGs, plus a set of JPEGs generated from them in DxO - and there was an orientation problem.

Turns out that:
When RAW images are rotated in DxO it correctly writes the metadata to the subsequently generated JPEG.
When JPEGs images are rotated in DxO it updates the EXIF, but not the XMP, resulting in a conflict - and PSU obviously goes with the XMP value.

The workaround (as mentioned above) is to select the images in PSu, right click and select Metadata -> Convert Metadata to XMP, then Operations -> Rebuild Selected Thumbnails.

Now that I've pinned it down I'll be reporting the problem to DxO.