@Wolfgang I bought DxoO 11 because it had the best, most sensible export features of any program I had seen and the DxO 7 adjustments made a real difference to my JPGs with just a few tweaks once I had worked out what I wanted.
PhotoLabs 1 saw the demise of my favourite quick adjustment and the start of ‘Local Adjustments’ which in the early releases were mostly a “joke”. However, in spite of the demise of my favourite option I have stuck with it.
But what I see in the forum topics is “infuriating”, when DxO are justifiably seeking increased market share, which benefits us all, otherwise the product goes down with the ship, but steadfastly turns a deaf ear to issues that could be resolved quickly.
They would improve the usability of the product by avoiding issues in the first place or providing facilities to overcome obstacles when they occur.
I will continue to use DxPL but also continue to “complain”, but hopefully in the most professional way possible, in the hope (however slender) that someone is listening and adding suitable “fixes” to the schedule, preferably this side of …
and when have you known me be “faint of heart”. I will test it on Windows later.
I have some way to go with Python and then I need to learn the Python to SQLite interface before I can write a script to do the necessary processes automatically. On my old DMS II database with COBOL it would be written already, but testing would take a bit longer!
But DxO could do it in hours @Wolfgang, if they had the will!
DxO could offer to make an incoming DOP the [M]aster replacement, or the [M]aster but keep the old [M]aster as a VC or preserve the current situation, whenever there is a Uuid clash between a discovered DOP and the database Uuid, within hours (and I am being generous) thereby avoiding some of the need for “promoting” VCs but the facility would still be useful.
They really need to do something, the promotion of VC with soft proofing exposes all users to an un user friendly process needing copy and pasting. I just processed 60 images, DxO would have me create all 60 as VC and then copy and paste all changes where needed onto the master copy. Its just not going to happen and I can see why with the changes soft processing is based on it needed but as usual one big change hasn’t been though through to its implications in this case a poor version of VC.
At present it’s a mess as far as I can work out you can’t just copy from the virtual copy to the master as that then becomes soft proofing copy. You have to close down all the virtual copy’s them copy and paste between those edited and wanted and the each master copy then you can delete the now unneeded VC, it’s a mess!
@platypus so much easier with no “false” coding rules in place!? I wonder if the coming of keywords (was that DxPL3) had anything to do with the change?
The master/copy implementation was introduced because many posters requested it. While DxO was programming the change, I came to realise that the “mirage” paradigm worked for me…but master/copy came anyway.
There wasn’t originally a master. You could delete any VC you wished. In PL3 or PL 4 I believe, DxO changed it to include a master. A number of us argued against it at the time, but we were told that it was a user expectation. I thought they might have done it to support some planned future enhancements to the functionality, but so far there have been no additions to VC processing, at least on the Windows side. The Mac version has supported unique VC renaming since PL 5, so perhaps the master is needed for that feature.
Naming isn’t a reason for distinguishing a master either: a name is just another property to store in a common dop/db. I guess enough people expecting something could sway them, but hard to imagine given the number of other popular requests that are consistently ignored.
Hi folks
I have been out of town. Let me put the record straight:
• My legacy pics edited with OpticsPro
I started with OpticsPro in 2017. Very soon I organized my workflow this way:
When I import a new batch of pics my first move is to select them all and to make VCs. At that time they were numbered “1”, “2”, etc. and there was no status difference between them.
I always kept the “1” unchanged and did mods on the “2” and in some cases on more VCs if I needed to test different edits. I didn’t change this rule of thumb to this day. So I implemented the Master feature before DxO did.
To make things clear at first sight I rank 2 stars the copy I edited and which is the one to be exported if needed. It proved to be a smart move. The “master” remains unranked. (When I review a new set I rank 1 star the pics I want to delete, so it’s easy to toss them in batch. I allows me to make a last review in case I have second thoughts)
With DOP you could erase the “1” copy without erasing the “2” which then became “1”. Since I still own a DOP on an older Mac I just did the test and it works. Hence to trash a picture I would select all the copies and remove them.
• My legacy pics edited with OpticsPro and viewed in PhotoLab
I was at first surprised by the change to the labels “M” and “1” but it makes sense… well, to a certain point.
Here is a view of a collection of old pics edited with DOP first:
As you can see the VC situation with the first photo is normal: the “M” is unranked, hence unedited, and the “1” ranked 2 stars, it’s the one to be exported.
You’ll notice that the second photo is abnormal. The one ranked 2 stars, hence edited, is labelled “M” and the other, unranked, is labelled “1”.
You can see that this situation is randomly applied to the complete set. It has no consequence as far as edition is concerned.
• The removing of VCs with DPL
I am sorry folks, it happened to me several times that by removing a VC I saw the complete photo deleted. It happened recently with a TIFF that I had created with a panorama soft. I did some edits on it (perspective, crop, etc.) and exported it to have a clean, compressed, TIFF version (so I could toss the huge panoramic version). Then I had an afterthought and made a VC (labelled “1”) of my compressed version, did some new edits, eventually didn’t like them and removed the VC… and the “M” was gone too. I retrieved the file with its .dop sidecar from the bin and tried again with the same result. Eventually I retrieved only the file without the sidecar and got the image without a VC. It didn’t matter since the “M” was unedited. It has no consequence, besides just a waste of time.
That was what made me create this thread.
What the Master is for?
I understand the Master concept yet I can’t get the point. Is it possible to disable it? With DOP I would create VCs at will, being confident I could delete the one I didn’t need any more. With DPL I don’t feel confident especially with the old pics.
@saint-112 Nick, I started using OpticPro 8 as a free version, the 9 also free, played with 10 and in those days you could continue to use a trial version for experiments for as long as … but you couldn’t export! With 11 came ‘ClearView’ and I bought the full release but never really used VCs much until DxPL 5.
With the metadata handling with 5, or for some other reason, the Trial Version rules changed and now when it expires then it ceases to work!
I only worked with VCs with the [M]aster scenario having ignored it in previous versions until @platypus took a trip down memory lane and I “discovered” the “old” way which you used to your advantage!
During DxPL5 “testing” (post release) I and @platypus and others have expressed concerns about ‘Unwanted Virtual copies’ etc. where the latest updates frequently wind up in VC[1] with no formal way promoting them to [M]aster status, nor of deleting the [Master] without losing ALL the VCs!!
Sorry that is the current reality of all versions since DxPL3 I believe and we are “stuck” with it, apparently because users voted for the change!!??
To swap edits and safely preserve them you need to do the following
Scenario [M]aster + VC[1]
Create VC[2] from the [M]aster copying the edits and the metadata. This step is proposed only for safety!
Copy all the edits and metadata from VC[1] to the [M]aster.
The [M]aster is now a “clone” of VC[1] and you can remove VC[1] and VC[2] (the "clone of the original [M]aster) at your leisure or not.
BUT ‘Removing’ the [M]aster is the end of all edits and copies on disk
@saint-112 Agreed, great minds think alike (you and DxO) and when you create VC[1] now you will effectively be creating VC[2] as per your old working.
Now an absolute No-No as all the posts in this topic have made clear. I just ran a test on DxO 11 and any VC can be deleted but the last one remaining “loses” its VC mark and becomes the “original image”!
At that point the ‘Remove’ changes from (just) being the deletion of a database entry (and associated loss of that data from the DOP) but will also result in the loss of data from disk, as well as from the database! For some time a number of us have been asking for the deletion of the [M]aster to also be (optionally) made a database-only operation.
The is arguably one of the simplest changes to the program logic @Musashi, although it then poses the issue of whether DxPL should immediately rediscover the image afresh and what rules should that rediscovery follow.
So we would have a ‘Remove from Database’ command as well as retaining the existing ‘Remove’ command (provide new alongside the retention of old, provides continuity not disruption) which would
Remove the database entry from ‘Items’ and all associated structures, erase the DOP (saving it with a changed name might be useful but …)
Rediscover the image which is still present on disk
Without a DOP any metadata would have to come from the image (embedded & sidecar) and that means that the “only” risk will be to any metadata that was maintained solely within DxPL (database and DOP) environment, which will have been destroyed with the ‘Remove from …’ command! But still way less damaging than the current strategy that will remove all disk elements as well!!
Well done it looks as if you have found a bug, i.e. DxPL 6 importing VCs from an earlier time and generation of product!
It did not happen to me in my simple test using my test directory used by DxO 11
I believe that the order of images in the DOP is what determines the order of “absorption” into the database on Win 10 but in your case
I don’t understand how it can reverse the order as shown @DxO_Support-Team!
UPDATE:- 2. but also [M] should be matched with [2] there should be no [1]'s in existence
That was me having a “Senior moment”, was that [1] moment or [2] moments!
[M] should be matched with [1] just not in the order shown!! Which brings me to moment[2] @saint-112 although the images are obviously showing in pairs what is the sort sequence in operation on these images it looks like ‘Rating’ order within image name but that is resulting in an odd order of images which doesn’t tally with you processing style. Do you still have the Opticspro DOP available for one of those images that definitely breaks your workflow rules. If so please post it on this topic so that I can look at its!?
You were lucky!
To be honest now that I realise how it worked “way back when” I prefer the old scheme but I wasn’t a member of the forum, I would have even been too “timid” to complain etc. etc.
A lot has changed since I volunteered for the PL5 Beta Test except that I still think banging my head on a brick wall would be better than trying to communicate with DxO!!
While I am at it I was trying to explore different edits using VCs on my own images earlier today and even knowing the "complications " involved from a database perspective I would like the following ( no-one listening anyway)
The ability to alter the order of any and all copies [M]aster and VCs.
To move into the twenty first century and be able to move the copies around, to re-arrange the order, with the mouse (what an outrageous idea)
The ability to name the various copies (not available of Win10 certainly) and/or
The ability to attach descriptive text to each copy (stored in the DB and DOP) but potentially related to the notion of Version “metadata” rather than anything else. I currently use “unused” IPTC fields for that purpose but …
I fear that really sums it up, I am looking at upgrading phones , better camera but age catching up as well, and really now understand the problems of DxO refusing to add DND/Apple support. My wife just uses a phone now and if I have to battle with a mix of accepted and rejected formats I can see me tipping into giving up on PL after many years. And from many comments over the years from others many others have probably already been driven away by their refusal to listen.
@John7 sometimes it seems they listen but then don’t bother to engage with users to determine how something should be done.
They appear to be incredibly reluctant to change any part of the UI, localisation would certainly hinder quick and easy changes but there is rarely an honest exchange of ideas. I have come in for a certain amount of criticism from other users for proposing new designs, via mock ups etc. but that is driven by a hope, not that they will follow what I propose but rather that they might consider any issues the “design” raises if/when they decide to make their own changes.
The smart phone issue is one that I share with you! My Pixel4a RAW images are a complete no-no on DxPL but FastRaw Viewer produces images from them with no problem, albeit not with the DxO lens fixes etc. but not to be able to apply any DxPL fixes or even see the images is …
and the issue is not simply that they don’t support the phones, or a given feature or … but that the issue is never discussed pro-actively/
Sad
Nevertheless, I started to edit some of my own images earlier today and DxPL does much of what I want but leaves me trying to work out when to stop editing.
This is the RAW shown by FRV, Monday was a day of cloud then Sun then … and this photo was taken with the Sun behind me!
but which of these is better and are all of them “too much” (only the first used DP XD) the rest only HQ for speed and yes it would be good if DxPL could snapshot the rendered images on demand and store them for side by side or quick full screen comparisons (and I have voted in the appropriate post some time ago).
Having read somewhere, that DxO changed the handling of “Master” and “VirtualCopy” … … is it possible, that your problems with the ‘disorientation’ from the recent PL version(s) has to do with that change – in other words – incompatble versions ???
[ Sorry, if it sounds silly – I just don’t remember details with OpticsPro (?), which I must have been trying long long time ago, and then started 2019 with PL2 / 3E. ]
When I started this thread I didn’t expect it to be so controversial. I have no major issues with DPL and this one is no big deal.
So my question is: what is the purpose of this “master” feature in the first place? I am at a loss understanding the benefits. It seems to have only unwanted side effects.
There is a motto in French called the Shadock principle: “Why should you make your life more complicated by making stuff simple when it’s so simple to make it complicated?” (“Pourquoi se compliquer la vie à faire simple quand il est si simple de faire compliqué?”).
Nick
I am afraid it might be the case. Since DPL messes up DOP’s labels “1” and “2” with the new “M” and “1” what looks like a VC may be a master in the database. Yet this doesn’t explain why the issue exists with new pics that were treated with DPL only.
Nick
I don’t know DxO’s motivation or possible former user requests. All I know, how it works today.
And no, I’m not interested in controversial debates.
It’s just an idea that came up when I read that you opened old versions in new PL.
So again – could it be some incompatibily from old dop-files / old database?
Wolfgang
I think the best is to ask DxO and send them some files with it.
There is no backward compatibility between DOP and DPL. I did the test: if you view in DOP photos that were edited with DPL they are all reset so you loose the edits and the VCs are erased. It’s just as if you were looking at them for the first time. And forget about retrieving your edits in DPL. I suppose that DOP can’t read the sidecar files created by DPL and just erases them, replacing them by its own.
In the old times I tried sending feed-backs and requests to DxO: very frustrating.
Here are my 2cts about your suggestions:
Why not.
You really want to live dangerously.
Definitely not. It’s already available in the Mac version:
When you select the master only and choose Rename Image… you get a dialog box where you can type the new name. In the film strip only the master’s name is changed. The file itself has also the new name as well as the sidecar file.
When you select a VC only and choose Rename Image… you get the same dialog box. In the film strip only the VC’s name is changed. The file name is unchanged.
When you select the master and a VC and choose Rename Image… you get a different dialog box. In the film strip both images’ name arre changed. The file itself also has the new name as well as the sidecar file.
IMHO: danger ahead, proceed at your own risks.
Good idea. I may not use it very often but it can be handy. It would be good with a better management of metadata.
Nick
Testing virtual copies in DPL versions 1 and up, I found that the DOP sidecars do not label anything as a master or a copy. DPL6 happily imports DOP files from e.g. DPL2 and creates the virtual copies. The difference is in the numbering and the behaviour attached to the “M” copy in the application (apart from different entries due to tool changes).
BUT: The order in which DPL6 displays the VCs can vary…
VCs in DPL2, marked with stars according to VC number
