Version 7.1 and 7.2 - Fixing some bugs? ... while creating new ones!

@Stenis

I am sorry but it works fine and has done, in spite of the “messy” way that PM goes about making even a simple change longer than it needs to be, for as long as I have tested it!?

Nearly all my tests these days use either Folder Monitor or my Python Folder Monitor (or both) to monitor the File and directory activities that are triggered by one program making changes, which are then detected by the other program which should take account of the changes appropriately, if those programs are watching the appropriate directory.

If the events are not trapped by the programs as they occur then the programs need to be able to detect that an image has changed the next time that they review the image, e.g. using File timestamps, size etc…

What has changed between when you used PM with DxPL successfully in the past and now, I do not know but I do not believe that DxPL has changed significantly, if at all, in its ability to detect changes and update its database, DOP etc., i.e. DxPL only uses the 'Date Modified" timestamp as far as I know.

If the problem does not lie with DxPL (and I believe it doesn’t), then it must lie with PM Plus or your configurations of DxPL and/or PM Plus or the way that you are using them?

The forced write has always worked for me .

So with XnViewMP and PM/PM Plus closed.

Set up a folder with two images one jpg and one RAW, check your settings in PM and make a change to ‘Rating’ in DxPL setting 1* in the JPG and 3* in the RAW with the DxPL settings you show in your first mail.

Start PM/PM Plus and XnViewMP and navigate to the test folder in both programs and what do you see?

This is what I suggested but with DxPL and XnViewMP and the images already contained keywords from PM from earlier tests

yes
I use Photo Mechanic Version 6.0, build 6890 (latest update) and it work fine, data is/still there even after processing in PL7.2 latest update, it also worked with PL7.1.0 built 38. i can even check exported tiff file and all my data is there.

I’m on MAC not PC, maybe it’s a Windows issue. sorry!

@Stenis do you have situations like this and this is not to do with the problem you reported here, it is caused by the way that PM goes about making a change to the metadata of a JPG, and looking at the number of “rogue” DOPs it doesn’t seem to happen every time i.e. I have done more tests than the number of such DOPs shown here.

I had this issue with ACDSee support. The Nik Collection plug-ins used to work with ACDSee edit mode. But they have now stopped working, and there is really nothing I can do because DXO does not support integration with ACDSee.

It is always unfortunate when something that worked previously no long works. I know It is frustrating to realize that as it is unsupported software you won’t get any assistance from DxO.

Mark

what version of NIK?
did you asked ACDSee if there was work in progress?

The last version of Nik Collection that worked was 5.something (can’t remember the exact version). DXO made some change in one of the version 5 releases and now some Nik plugins don’t show up in edit mode anymore (silver FX being one of them). I spent a lot of time trying to figure this out but to no avail. So I don’t think this is anything ACDSee can fix, or if it was it would not be a high priority. You can still use the plugins as external applications in ACDSee, and I have changed my workflow accordingly.

When I have tried to use the Windows version and 7.1 and 7.2 doesn´t I have seen that neither of these versions read the XMP from the files and that is really the main problem. I have even tried manually without getting it to work.

There is no need comparing with Mac because that is not the same code. Mac might work but the Windows code doesn´t what I can see.

I have no problem at all with the earlier Windows version 7.0.2

The synch has worked without problems for me for years and suddenly it didn´t with version 7.1 and 7.2.

I also have something to say about some recommendations I have seen (maybe it was BAYT Bryan who wrote it) that suggested a few new solutions to how the Reference Synchronization ought to work.

I have no problem really at all with the synch as it is BUT I think it ought to be redesigned any way. DXO once designed the present sych solution originally for the synch with Lightroom.

I think they just shall have two different setup options:

In both cases the master XMP-data should always be the XMP-metadata in the files regardless if it happens to be stored in XMP-sidecars or in XMP-compatible files like JPEG, TIFF or DNG.

  1. XMP-data owned by Photolab (as default) basically as it is today but with Synchronization ON

  2. XMP-data owned by “External Software”

In this case there should be two options:
2.1 One way synch and in this case the metadataforms in Photolab should be totally inactivated (greyed out)

2.2 Bi-directional synch and in this case the metadata forms in Photolab should be opened
There also ought to be an infotext present that informs about that bi-directional synch might affect the dataintegrity of the “External software” and should be avoided if the user isn´t absolutely sure that will not happen.

Best practise will always be “One way synch”

… and for those who are too scared to use auto synch at all there can always be a special check box to turn on or off synchronization too even if I don´t see that as anything necessary as long as the synch works as flawlessly as it has done before version 7.1 and 7.2.

Yes it is a Windows problem only as it seems

I am now leaving DXO Photolab for good for Capture One 23 (16.3.5)

I have finally made a complete migration from Photolab to CO after some testing last week. I decided to subscribe for at least a year. They seem to have fixed the synchronisation problems with PM I have seen with my old version that was a show stopper before.

I can say I am totally happy so far because in CO I can really work precisely as I want, which I strongly felt I couldn´t really in Photolab 7 and it even got worse in the two last updates and after that DXO have continued to ghost their users. No Global and Local rubbish and problems either, just all the layer functions I need inclusive of AI masking that really saves me time when doing precision work. It is really surprisingly good.

In fact, there are quite a few things they have done in CO to address especially productivity issues. I remembered @Joanna and when she cried out about her cloning issues. Guess what Joanna, in CO there is a function called “Dust Removal”. Unlike Photolab,s Retouch Tool where you sit and click and click and click you just push a button called “Remove Dust” that with one single click removes all dust marks.

We also get new functions when they are ready to roll out and don´t have to wait for them forever like with Photolab. As an example, they implemented support for the new Sony A9 III from day one with the last version that I downloaded last week. When I bought my A7 IV I have to wait 6 moths for thar camera profile.

I can now have it all in one single application too. Earlier the main reason to also use CO in parallell with Photolab was the tethering functions. I still do a lot of tethering when repro photographing old color slides and now, I will have very few reasons to open Photolab anymore.

Still, I hope DXO will get their act together and fixes at least the most flagrant problems with Photolab, despite I,m not all that convinced they will do before next September/October.

anathema ! somebody bring us a pitchfork, tar und feathers !

on a serious note - C1 just needs to add AI NR ( even w/o that you can dump DxO’d linear DNG w/ NR applied [ and optics corrections if you are so inclined ] to C1 and work in it futher ) … and leaving DxO fully behind even as a NR preprocessor most people will do just fine w/ their choice between (or both for a user to decide) embedded manufacturer’s optics correction data in raw files and their own profiles

of course = How is Dust and Scratch Removal done in PhotoLab 7 Elite? - #5 by noname

known for ages literally

And for “ages” it didn’t work satisfactory (LCC or the tool in ancient Capture NX).
The new “AI” version is still very young (IQ=10 ?). Will it remove electric socket inlets?
How about freckles?

C1 : / removes dust /

DxO : … how about freckles? … will it remove electric socket inlets ? …

C1 : / makes a kiss sound /

DxO : :scream:

I’m guessing your sensors must be really filthy If having an auto dust removal tool is so critical to you. It is rare for me to ever have more than a couple of dust spots that need removal and most of these can be removed directly from my sensor using my Goitto Rocket blower when changing lenses. If your images are that full of dust spots I can understand the advantages of auto dust spot removal for you, but for me it is an non-issue and would certainly not be a reason to switch to Capture One.

Mark

Of course, my dust removal needs are from scanned 4" x 5" negatives or transparencies, so just a bit more work and no sensor to clean, just large sheets of film that seem to create static just by looking at them.

it always makes me smile when i see people changing lenses on windy days =]

DxO aficionados promptly closing the ranks :speaking_head: : “shield waaaaaaaaaaaaall” (c)

I understand your issue with copious amounts of dust on scanned negatives. Do you know if @Stenis’s need for auto removal of dust is also a result of scanning negatives?

Mark

I seem to remember he is involved in archiving, so logically, yes. That, is if he is who I think he is :thinking: