I am new to DXO and would like to maintain my current workflow which is the following.
Import,rate, tag etc… using PhotoMechanic
Export images to raw editor
When I do the culling in PhotoMechanic and export to DXO I have noticed the following:
DXO does not see the color codes, I’ve Applied
DXO does see the star ratings
All of the files from the folder are dumped into DXO and not just the ones I selected for the export from PM.
Does anyone else use PhotoMechanic for there front end culling? If so, are you able to apply some settings that will accomplish the following?
Allow DXO to see the color codes applied in PhotoMechanic
Prevent DXO from importing all files in the folder that were not selected in PhotoMechanic .
To avoid opening the whole folder instead of a selection ensure that you use a link that does not have a “-openwith” parameter, like in the link, which is created as default by PL setup on the desktop.
Did you export XMPs out of PhotoMechanic to the same directory like the raws? I think, it is the only supported way to exchange raw metadata.
Stars should work, they are displayed in a different color (yellow I mean), to show that this is an externally read rating.
Labels I don’t know exactly. What I know is that labels are language dependent and can be user defined. What is saved is a string like “red”, “rot”, “rouge”, “idontknow”. The target software must then map this strings to colors, which is often not possible without user feedback.
Thank you for your reply…Don’t know what changes I made but I can’t duplicate my first problem which was opening the whole folder in DXO vice the selected photos.
Now, when I select a group of photos and use the option “edit selected photos with” command in PhotoMechanic DXO only opens 1 photo.
I selected the option in PhotoMechanic that directs the program to do the following when writing xmp/iptc files
Allow raw files to be modified
Add embedded metadata xmp and iptc
Always create or update xmp sidecar files
So, when PM sends the files to DXO to edit I am assuming it is creating and updating sidecar files.
I will also ask for clarification on the PM forum today.
Found this old thread about Photo Mechanic. Since I use both Photo Mechanic (one year) and Photolab (three or four years), for Photo Mechanic users who might find it I’ll share what works and does not work between Photo Mechanic and Photolab.
As of August 2021, Photo Mechanic 5 and 6 (both tested) have no issues opening up specific one by one in Photolab 3 and 4 (both tested). It’s possible to do one’s full culling and labelling in Photo Mechanic and then open photos one by one in Photolab using the E key (if DxO Photolab 3 or 4 is set as the primary photo editor).
Stars of course work. Labels do NOT have any equivalent in the image browser in Photolab but they do show up in metadata strangely enough, even when exporting.
Metadata/IPTC
Headline/Title meta data field is read by Photolab but Caption metafield is not. Most author/copyright fields do come over.
Interesting about the caption data not coming across from PM to PL4 - I have today just added a question to the forum about that very issue.
What is the reason for that? Why does PL4 pick up most of the metadata added in Photomechanic but not the description/caption tag which is arguably the most important. Doesn’t make sense to me.
I note also that the crop feature in Photomechanic does not translate to PL4 (i.e when opening the image in PL4 the photo is shown at its full size, not the cropped version carried out in Photomechanic), whereas that is not the case with Lightroom (or at least Lightroom 6.14 which I am still driving), where the image is first opened in the crop carried out in Photomechanic.
It would be nice to have this feature in PL4 also.
That is a decision DxO is making. The data from the crop function in PhotoMechanic is available for Photolab to read from XMP just as successfully as Lightroom. It’s this kind of small nice touch which would endear DxO to large new pro audiences (Photo Mechanic users who don’t use Photolab). I wish DxO would be more pro-active building bridges and partnerships with other co-operative software.
Hi Alec, the crop data is in the Lightroom section of the xmp file so I don’t know if DxO want to try and start interpreting data intended for other software. That would open up a huge can of worms!
DxO have decided to store all their PL data in dop files and only read specific data from xmp files.
There’s no can of worms to be had here, Keith. There is data in the XMP file. DxO can read that crop data with all the success of Lightroom or Photoshop. Crop data is not that complicated, particularly what Photo Mechanic is putting out which is without keystoning or perspective. I’d say it’s basic math but it’s more basic than any math. It’s rotation and crop coordinates.
Yes, I’d like to see DxO pick up their socks and improve compatibility with other software instead of taking an egocentric French attitude that Paris is the center of the earth and the entire planet should revolve around France. In this case, DxO is the center of photo management/processing/DAM and photographers should revolve around DxO. It would be far better for DxO to co-operate with other medium sized players, strong in their own domain. Through such co-operation and compatibility to improve the user experience.
DxO has just created real trouble for Nik in Nik 4 by cutting off or additionally limiting compatibility with:
Affinity Photo
Capture One
Photoshop CS6
There is a tendency to avoid here. I’d like DxO software which plays well with others. When I arrived that seemed to be the direction DxO was going in. There’s been some steps to improve cross-compatibility with XMP ratings (sometimes an external change does show up these days) and some ups and downs with keywords and other IPTC data so the record is not all black. These are easy wins, which don’t complicate the software or do any harm and make DxO software far more appealing to new audiences.
Hi @uncoy , I don’t want to get into an argument but the can of worms I am referring to is the fact that if DxO start supporting proprietary data from one tool them there will be a cry for it to support more and more. If the other tool changes something then DxO will be obliged to fix it on their side and this will become a bigger and bigger hole for themselves to dig themselves out of.
From years of experience in IT, this is something I would not take on board as you have no control over other tools and you can better use your resources on improving your own software.
XMP have standards as well as providing a faculty to allow software to store proprietary data in their own sections of the file. Just search for Lightroom in an XMP file created by Lightroom to discover what data they store there.
Photo Mechanic crop data is not complicated Keith. It’s a grade school level rotation and crop based on pixels. IT managers who are unwilling to take anything on no matter how simple as they don’t want to take any risks are the bane of progress.
In fact, the team at Photo Mechanic are responsive enough that if DxO came to Photo Mechanic and said:
We’d like to support your crop tool but we don’t like the way Adobe specifies the data, could you write it for us in this simpler way?
There’s a very good chance Photo Mechanic would do so as the new simpler format could be supported by other apps.
Let’s be clear what we are not talking about. We are not talking about Photolab permanently storing its crop data in XMP format. We are talking about reading Photo Mechanic crops on import. For the moment any crop support would have to be one way as Photolab would have no way to know if Photo Mechanic crops or Photolab crops are canonical. As culling comes before editing, the obvious choice is to only adopt the Photo Mechanic crop at first import.
Photolab/Viewpoint crop information is complex unlike Photo Mechanic crop information, involving keystoning and distortion correction. Two-way compatibility is not viable.
But one way import of Photo Mechanic rotation and cropped pixels would be child’s play.