Let’s hope for the best. And in the second or third step they could remove DOP altogether and put the development settings also into XMP, like it is done with the crs tag (Camera Raw Settings) by Adobe. Two sidecars is one too many. And as I said, on XMP two separate options for auto saving / auto loading is needed, because XMP can be altered by anybody.
So, if someone uses an external DAM, he want his XMPs most likely not be changed automatically by PL. But if PL is the primary DAM, many will set auto write to true. Auto read allows to have full control on whether/when the PL database content is altered through external changes. I would set auto read on XMPs to false (after initial indexing).
I save .dop file as I work on raw from my internal SSD, and after some time, I archive raw on an external HDD.
So the DB is then loosing reference to the raw/dop, and need the .dop to retrieve the modifications.
And sometimes, I may prefer not to take them, so now I can uncheck the Preference, while continuing saving new .dop.
OK, I could also apply the No corrections preset to start from scratch on this images…
So not really important, but as some why there is a need to change that. If it’s for something much better why not, but without knowing, it seems more like a less easy thing.
@Tilmann and @John-M => Thanks for your feedback. We definitely weren’t aware of better things to do and appreciate that reasoned people return us to the right path.
On a more serious note, I know some of you are definitely angry at us, and take any opportunity to let us know your state of mind. We got that. Really. But I’m sure we’d all be better off if we can stay on a more constructive level.
You see a post with a poll, on a “small” thing to you, and you immediately jump to the conclusion that :
we’re only focusing and doing that at 100%
we don’t care about or don’t have others “more important” things to do
we’re not able to discern what is irrelevant in our work.
Wow. Well… if that’s what you truly think, then there’s not much we can do at the moment.
As I’ve posted on another topic recently, at the moment, our teams are working on a balanced load of tasks, at least as much as we possibly can, and those tasks include:
finally tackling long time users requests
UX improvements
new features, including DAM functionnalities.
general maintenance and bug fixes
At the moment it’s all words on a forum, but as I’ve already said, you’ll see the embodiments of all those efforts in the upcoming updates, and I hope, finally be reassured that we’re hearing you and that we may know what we’re doing.
But yes, I must confess that I’m somewhat disappointed about the way things appear to develop currently. So please excuse me if my sarcasm was too strong, that was not meant offensive.
(Also, I did not imply that you’re doing nothing else. On the other hand, this issue really is the least urgent one could think of in the current situation, IMHO.)
Please note that I really like PL, and I keep recommending it to other photographers.
Besides any emotions, the arguments are still valid. It doesn’t make any sense to remove a working functionality (and even put effort and ressources in this). If only one single user prefers to have two separate options here, you should simply leave it “as is”, unless you have strong arguments to change it. (In that case, it would be fine to share and discuss such arguments.)
All those users who always have both boxes checked or unchecked, will continue to be fine with clicking twice to change this setting(s) if necessary. However, the other users simply would not be able to configure this according to their needs if there’s only one checkbox.
Personally, I currently have both boxes checked. But if I was to change this, I definitely would turn off only auto-save, not auto-load. So please keep both checkboxes.
Let me add my technical view on that topic. I hope it’ll make you understand a bit more what’s behind the poll and the corresponding changes.
The way sidecar are handled is not as simple as one could imagine. One of the goals of sidecar files is to let people share correction settings on image across several computers, for ex. when images are stores on a network share or on an external drive. In addition to correction parameters, it also stores ratings, tags, virtual copies, etc. Every time an image is displayed in the filmstrip, or when you re-index a folder, we synchronize the sidecar file with the content of the database, so that we ensure that you’re working on the most up-to-date version of your image and that your sidecar reflects this most up-date version. In some scenarios, this synchronization ends up in creating virtual copies of your images because we cannot figure out if the sidecar and the database contain 2 different virtual copies or 2 different versions of the same corrections.
Some people got in touch with our support because of that issue happening sometimes with their workflow and we want to address it. There are different technical solutions to this issue but the cheapest one to solve some of the scenarios is to avoid letting users enable sidecar reading without enabling sidecar writing. Hence the poll.
To summup the situation :
by working on that feature, we’re addressing real issues faced by real customers. It’s not because you don’t face it that other don’t.
by creating this poll, we’re trying to know if the basic solution, that would solve most of the cases, will not bring pain to some other customers. The idea here is to save time of the development teams, so that they can work on more “interesting” feature.
Finding the best balance between implementation costs and value brought to users is at the heart of our daily activity. We’re always trying to bring the most features we can, as fast as possible, to provide you with relevant solutions to your photographer’s problems.
Nicolas, although I have both options “on”, I’m one of the users affected by the problem of unwanted virtual copies.
As far as I remember, DxO creates virtual copies if I modify image+sidecar pairs on another computer and copy them back to a local disk. It does not happen if I’m working on a external disk or a network share.
I don’t understand what the DxO developers had in mind when inventing this logic, maybe you can explain the reason behind.
Therefore, I delete the database always when transferring image+sidecar pairs (as John-M dioes). The sidecars are my primary place to store the information.
Instead of brutally deleting the database, I would prefer an additional switch in DxO not to create virtual copies if the sidecar is changed externally, or a dialog asking the user if external modifications are detected.
There are other problems with the sidecars I already described in
Please consider also backup or version control scenarios. If DxO scrambles the sidecars at every opportunity without changing settings, this creates unneeded pseudo-differences or backups.
And keep entries in a predictable order. Since the sidecars are text, it can be very useful to compare two versions with a text compare tool to find the differences in the settings.
thanks for the detailed explanation. This makes it much clearer - if the poll would have contained at least a small portion of that background, this would have saved much discussion…
(This again shows that the communication by DxO could be better, which has often been mentioned.)
For me, only the sidecar files have (ever) been relevant. I don’t mind the database, and for me it wouldn’t matter if there wasn’t any.
If you change anything here, please take care that it must be possible to use PL exactly that way.
Please never do so (unless you are the market leader with jester’s licence - SCNR).
XMP is a (halfway) standardized container mainly to make image metadata like description, keywords, geotagging etc. available for different applications over a long time.
But the RAW developer settings are very application specific IOW incompatible, you can’t share Lightroom settings with Photolab and vice versa.
Maybe somebody can explain me an advantage (for the user, not for Adobe!) of Lightroom RAW develop settings kept in the same XMP sidecar as my valuable metadata.
At the moment I see mostly disadvantages for the user, and advantages only for Adobe.
Indeed it used to be the default support solution to nearly every thing to delete the data base! Those of us using a DAM already have two extra files to each image already, whats the problem?
I think nobody eats up your meal, only because he sits next to you on the same table. Metadata is everything that is not core data. Development settings are product and image specific metadata. Nobody needs more than one sidecar.
@Asser, Should Photolab, Lightroom and the other RAW developers then contain options to remove the product specific develop settings from a XMP sidecar?
No, why? They do not hurt anybody or each other. PL should not touch LR development setting tags, and vice versa. I have many LR development tags in my XMPs, although I do not use LR anymore.
…no-one actually wants sidecars but it is the current state of things, along with the fact that different sidecar file formats exist that are not really interoperable…
I need sidecars, because I want my metadata to lie outside of a company specific database in a human readable and convertable format, like XML. XMP and the existance of the ExifTool ensure that my metadata will survive the lifecycle of every product specific database.
I would not even bother to enter a single metadata information into a database, which cannot store this metadata into XMP. It is like putting your valuable things into a tresor, without having a key for it.
Hi Fabrizio - - I’m echoing @Tilmann here by assuring you that I’m not at all “angry” with you, or with your team.
In fact, I have nothing but respect for the excellent work you are doing in the on-going development of the best RAW processor out there (ie. PhotoLab). Even if some of it is of no interest to me (case in point: the DAM additions), I do understand why you are adding these features to PL.
However, I did promise you (in my response to your earlier post about the “balanced load of tasks” that you are working on) that I would persist in reminding you about the list of long-standing, outstanding requests that many of us have voted for … particularly because I reckon a lot of user frustration (such as we saw in comments made about content of the major v2.0 upgrade) is directly related to these long-standing, outstanding requests not being delivered.
Yes, that helps a great deal: with this background we can see the purpose of Fabrizio’s request for feedback - - and we can understand that it’s not simply a frivolous whim. … Thank you, Nicolas.
Ahhh - - I have seen that happen - - Now I understand why it occurs (and your dilemma).
OK, gotcha ! … On this understanding, I’d be happy to change my vote …
My reasons for preferring to keep the 2 options are minor. I’d be happy to give-up that flexibility if it meant that this issue could be addressed at “cheapest cost” - - and, thereby, free-up resources for attention to outstanding user requests.
Perhaps others may now see this in similar light (?)
