Integrating Dx0 with PS

[lcrl]

Hi, I'm another refugee from aperture, lured by PS versioning which is like Aperture's stacks. Im trying out the 30 day trial.

Here's what I'm trying to do. I import my pictures form a Leica M9 where I shoot both RAW + B+W jpeg. I want to be able to open the RAW file in Dx09 and have it saved back into the versions in PS. Currently I can selct a image in PS, open it from PS with Dx0, but I cant figure out how to save it back into PS. What am I missing?

[GrantCee]

I'm new to PSu as well, and like you an Aperture refugee using DxO to process the RAW files. (I too usually shoot a RAW + B/W jpeg.)

As yet I haven't found a way to process in DxO, then return to PSu and have the new TIFF automatically recognized. The only workaround I know is to re-import the folder to pick up the new image(s).

My workflow is Fast Raw Viewer (FRV) to do the rapid cull, then copy the files to their permanent folder. From FRV I navigate to that folder and batch-send the RAWs to DxO, directing the output back to the image folder. Then I import into PSu, assign to portfolio(s) and add keywords as necessary.

[fbungarz]

I have been using PSu (actually IDI) for years, but am relatively new to DxO. My workflow is relatively simple:

(1)
I am using a script available from the resource repository to import JPG+NEF pairs according to a renaming rule I have used in IDI v4, the precursor to PSu (for more details about this script see a recent discussion here: http://forum.idimager.com/viewtopic.php?f=57&t=24288).

(2)
Once the image pairs are in PSu I treat them as a version set. Traditionally I would open and tweak either the NEF or the JPG in Photoshop and save the developed images in the same folder adding the suffix "_print" or "_edited" to the file names.

(3)
Using Photoshop this is actually a bit dangerous. One can easily overwrite the original file, forgetting to add the suffix when saving the modified file. Also, tweaking individual files is a bit cumbersome. For the ultimate perfect image it may be necessary, but if I quickly want to fix a bunch of images it is a rather inconvenient way how to do things. So, I have been looking for an alternative...

(4)
DxO lets me open one or several images from within PSu directly. First it is necessary to add DxO as an External Application via Preferences - Other Settings. Then I simply select the images I want and hit the DxO button.

(5)
I wish I could have the DxO raw adjustments be seen already in PSu, when updating the thumbnails there. Unfortunately in practise rendering of Raw-thumbnails adjusted by DxO inside PSu does not seem to work very well, even when selecting it to be "approximate" under "Preferences - File Handling".

(6)
This means in practice I make the adjustments in DxO and have it develop a JPG (could also be a TIFF, but I think that is overkill) with the the suffix "_print" or "_edited" added to the file names.

(7)
In PSu I use the "verify folder" (= Shift+Ctrl+K) command on the images I exported to DxO. It detects the new image files and allows them to be versioned with their original files. .

(8)
Importing these images to PSu, I do not (!) import any data that changed out of PSu. I am using PSu exclusively for my image management and experience tells me that accepting changes of metadata made outside the program is risky. I may loose some of the PSU cataloging data.

(9)
Once the new images are versioned as a subversion of their original files I cascade the data from the main files into these new versions. Thus the newly imported files have all the same metadata and catalog tags as their originals.

Overall this works fairly well. I had some problems with DNGs not being rendered correctly in DxO 10, but this has been solved in version 11.

Cheers,
Frank

[tstoddard]

(9)
Once the new images are versioned as a subversion of their original files I cascade the data from the main files into these new versions. Thus the newly imported files have all the same metadata and catalog tags as their originals.

Frank,

At the risk of taking this conversation off topic, I would like to comment on point 9. Recently, I've begun experimenting with using Lightroom as my primary raw editor. I have had some issues with metadata getting mangled when going back and forth between the two applications. One thing I tried was to tell Lightroom not to write any of the raw image's metadata into the jpeg that it exports. I assumed that I could import the jpeg into a version set in PSU and then use PSU's cascade functionality to get the raw image's metadata written to the jpeg. Unfortunately, this doesn't seem to work, at least not for the technical metadata. I ended up with jpegs that didn't have any of the camera's original data in them. No exposure info, dates, times, etc. I've had other issues as well but won't go into that now. My point in mentioning this, is that cascading metadata does not necessarily transfer "all" metadata from one file to another in a version set. If there is some way to get it to do that, I'd like to know about it.

[sanphotgn]

There is a feature request to include the option of cascading Exif and IPTC to the version set:

http://mantis.idimager.com/view.php?id=3016

There is a script that will cascade everything (no options to choose): Exif, IPTC and XMP. From the description of the script: "This version will cascade the meta data to the entire version stack. The script will always take the main version for every selected image and then cascade the main version's meta-data to every sub-version in the version stack. Beware that this overwrites the sub version's meta-data (Exif, IPTC and XMP) and replace it with the main version's data
image and then cascade the main version's meta-data to every sub-version in the version stack."

http://repository.idimager.com/openreso ... 0C56713A28

Recommend testing on copies of copies to see if the results are what you are looking for.

[sanphotgn]

(2)
Once the image pairs are in PSu I treat them as a version set. Traditionally I would open and tweak either the NEF or the JPG in Photoshop and save the developed images in the same folder adding the suffix "_print" or "_edited" to the file names.

Frank,

Are you creating Custom File Masks based on your suffix choices?

For example, in Preferences - Catalog - Versioning, something like this:

Version_01.png (48.12 KiB) Viewed 9521 times

Version_02.png (32.07 KiB) Viewed 9521 times

Version_03.png (58.2 KiB) Viewed 9521 times

Thanks.

[fbungarz]

There is a feature request to include the option of cascading Exif and IPTC to the version set:

Yes, and I was one of the first people to vote for it
I was not aware of the script though.
Good to know it exists!

Generally, I think the default behavior should always be not to overwrite technical metadata and in fact, if an option is implemented that would allow for it, it should not be a simple checkbox (like the boxes that can be checked to cascade ratings, labels, etc.). Accidentally overwriting existing technical metadata is a high risk. It is quite possible to loose that information completely. So, a warning "Do you really want to overwrite the technical metadata of the subversion?" should be enabled with that option.

On a side note:
Until now I have not used DxO all that much, but it seems that unlike Capture One or Lightroom it does not mess too much with the technical data of a file, but stores its own adjustments in a *.dop sidecar. But I admit not to have done any careful checking of the technical data in the files generated by DxO. Always keeping the originals, I do at least have one set of images with the original metadata, I guess.
Apparently any software manufacturer these days seems to think they can treat metadata whichever way they like. Interoperability does not seem to be high on anyone's agenda. Even Adobe's DNG converter, which specifically claims to be the format to keep all the raw data, apparently messes with some of the technical data of the files...

Ah, well...

[fbungarz]

Are you creating Custom File Masks based on your suffix choices?

Yes, I do. Below a screenshot:

CustomPlaceholderSettings.jpg (131.16 KiB) Viewed 9518 times

Unfortunately they are presently not well supported in PSu. In my experience my custom placeholder assignments get messed up every time I use version detection. The three different ways of version detection all work differently with respect to custom placeholders:

(1) Import completely ignores them. It does not recognize any of the placeholders. I was told this is by design.
(2) Version detection (Shift+Ctrl+V) assigns some of the placeholders, but not all. Overall the process is unreliable and unpredictable. For example, sometimes all my DNG files are assigned to the custom placeholder Digital Negatives, sometimes only a few. Vlad kindly wrote a script to fix the custom placeholders again for my raw files. In my experience the file masks are not properly recognized. No idea why...
(3) Finally, version detection during "verify" folders correctly detects my files with the suffixes "_print" or "_edited", but it does not assign these to their specific placeholders. Worse: it removes all other custom placeholders from the version sets. And thus I then also have to run Vlad's script on these files again.

As a consequence I typically end up having to assign the placeholders manually, which is not particularly efficient. I have reported this to Mantis, but unfortunately it doesn't seem to be a high priority...

[tstoddard]

There is a script that will cascade everything (no options to choose): Exif, IPTC and XMP. From the description of the script: "This version will cascade the meta data to the entire version stack. The script will always take the main version for every selected image and then cascade the main version's meta-data to every sub-version in the version stack. Beware that this overwrites the sub version's meta-data (Exif, IPTC and XMP) and replace it with the main version's data
image and then cascade the main version's meta-data to every sub-version in the version stack."

http://repository.idimager.com/openreso ... 0C56713A28

Recommend testing on copies of copies to see if the results are what you are looking for.

sanphotgn,

Thanks for reminding me about that script. I have used it in the past but had forgotten that it exists. I may need to get it out and start using it again now that I'm using Lightroom.

[Ruhell]

This is how I do it.
1. I import my raw files from the card reader by using Idi.
2.Then I select those files I'd like to develop, click the "quicklaunch" DxO icon in Idi which opens those files in DxO. Adjust to taste in DxO, save back to original folder as jpg/tiff with _DxO10 as an addition to the file names.
3. Back in Idi, right click those selected rawfiles, select verify folder and the new files are read and added to Idi's catalog.
4. I think there is a setting in the verify dialog that lets them automatically be versioned with the original file, but of some reason I prefer to do it manually. So after they are imported I right click again on those raw files and select version selected raw - voila, done

I do notice that any picture taken in portrait mode will be rotated and shown in landscape mode when it's coming from DxO10. From DPP(Canon6D) they are oriented correctly, but I havent looked into it, just beeing annoyed

[fbungarz]

Hi Ruhell,
that is basically the same workflow as I previously described.

I do notice that any picture taken in portrait mode will be rotated and shown in landscape mode when it's coming from DxO10. From DPP(Canon6D) they are oriented correctly, but I haven't looked into it, just being annoyed

Out of curiosity: You mention the Canon files don't show this problem and are correctly orientated when they come from DxO? Which files have the orientation problem? Are they Nikon files?
I remember reading somewhere on the forum t´hat Nikon's orientation tag is a bit of a mess. Even without using DxO I constantly have problems with my Nikon files. I can rotate the thumbs in PSu. Once I edit them they are back to the wrong orientation. It even does not seem to matter how the camera is configured, whether I have enabled or disabled auto-rotate setting in my Nikon cameras. No idea what is wrong...

[Stephen]

@Ruhell + @fbungarz

Re. orientation, did you have time to check what the orientation tag looks like after the file leaves Dx0? Maybe it has been changed and PSu does not know what to do with the image?

[Ruhell]

Hi Frank, they are Canon 6d CR2 files.

With a high risk of me getting lost somewhere along the road...
I sendt one portrait oriented cr2 file to both DPP4 and DxO10 and saved them back as both jpg and tif.
In the Windows file viewer they are all 5 oriented correct. Skipping through them with both FastPictureViewer and Faststone Viewer both shows them all oriented correct. Idi shows the 2 from DxO rotated 90* left. Idi reports the cr2 and the DxO files to be oriented 90 clockwise, while the jpg/tif out of DPP indicates normal.
ExiftoolGUI reports the cr2 and DxO files orientation as Rotate 270 CW, while both DPP4 files shows orientation horizontal (normal), and now they all show correct orientation in the ExiftoolGUI preview window but the DxO jpg that is corrected 90* left ??

[fbungarz]

Very odd...
I have no idea what is going on.

[Stephen]

@ruhell
Have you looked at the orientation in the maker (notes) tab?