Yes. And so far, disabling automatic sidecar import/export/sync has worked well for me.
Automatic actions, specially in case of exception handling, start with an assumption that may - or may not - be the one that is applicable in all cases of all users.
Just for fun: Assumption shares a few letters with jackass…
@joanna that doesn’t surprise me in the slightest neither does it deter me from asking for such features, they would be useful, ignored by many but used by some. They could be secreted elsewhere just so they are available is all I want!
and it is but it is currently also to be found in the DOP and while you see that as a point of failure I see that as the possibility to recover from situations that otherwise have no recovery at all.
Sorry but I not only believe in building and testing software robustly I also believe in building the product such that if part of it or part of the rest of the infrastructure fails I have options!
I do not like having no options, relying on the developer to come up with a fix in a suitable timescale is unlikely to work but having options built in (whether “pure” or “impure”) gives me a way out and I do like options!
Exactly and sadly that bad decision has come home to roost.
In fact it wouldn’t have necessarily caused any such compatibility problems but what it would have required is that PL5 started making .xmp sidecar files and that might have been in “violation” of user settings with respect to metadata handling. Without making that data available at the time we all carried on in “blissful” ignorance and some were sadly “painted into a corner”.
But I want the fix for the situation where I have no PL5 database but do have the photos and a handful of DOPs which could be of use but not without some changes to PL5!
I’m not going to hold my breath but if things don’t change then the more complex the product becomes the greater the risk that we will look back on the release of PL5 as the “golden age” of DxPL!!
I am also sorry we keep “meeting” this way and I need to reduce the amount of testing and writing up etc. that I do.
and it was 2 months too late!
The shock to many users is that this has never happened in the past and they have passed from one release to the next with no problems whatsoever! Then along comes PL5 and …
Sad because I find the interface for PL5 streets ahead of most of the other products for ease of use and the more I use them the more I appreciate the PL5 interface. I purchased IMatch and while it is rammed with potentially useful features it can be slow and ponderous at times and there is a mountain of a “learning curve” to climb to make use of the product or to work out which bits are useful to me and which bits to ignore for the time being!
The first thing is to continue testing at least for a little longer until hopefully PL5 settles down and then I can try using PL5 keywording for real and see how I get on with keywording in general and PL5 in particular (and IMatch of course)!
Why does that surprise you? Developers are a “strange” breed and I would probably include you in that statement (and me, once upon a time I used to help build systems now I “just” break them). To develop something you have to have a belief in what you are doing and the way that you are doing it, there is an inherent risk in the “pride” that you have that you become defensive when other other ideas and suggestions are made.
Commitment to your own product can blind you to suggestions from outside. I would “arrogantly” claim that when I went into a review meeting I would expect to defend my design but I wanted the best minds available to challenge that design, knowing that what emerged would be all the better for it or if it stood up to such scrutiny then there was a good chance it was at the very least O.K.
That is a “luxury” not always available to all developers because of time constraints, budgets, the pressure from sale personnel (I certainly had that and from project managers trying to stick to budgets and time constraints and to rash promises made to the customer - sometimes by me, oops).
All of those I can forgive but the one I cannot forgive is the developer who doesn’t listen to others because they believe that they know best. I was very good at what I did and welcomed a challenge, not so I could “crush” the challenger but rather so I could learn from their point of view. I went on courses where I new much of what was being taught but if I learned one new thing or it made me question a belief about something I thought I knew, I considered it time well spent.
I hope that the DxO developers have self belief, but only when it is deserved and are not so “close minded” that they ignore the odd “pearl of wisdom” that might be found amongst all the posts in this forum.
But therein lies a problem.
Just lately, since the PL5 release in particular, we have been churning out a huge amount of “stuff”. It trickles out at various points in a topic and also in a similarly named or a similarly themed topic!
Some test threads peter out, some discussions do the same but the accumulated “wisdom” is frequently dispersed in the posts and can only be discovered/re-discovered by reading through the thread and that can take some reading and some time (sorry, please don’t suggest that I am one of the main culprits because I am well ware of that)!
I agree that raw files aren’t sacrosanct - after all, they’re really just TIF files. However, it’s not totally irrational to be wary of writing to raw files. Once, some years ago I apparently used a poorly-designed metadata editor and the result was that DxO couldn’t open the image file. Of course, exactly the same thing could happen with a JPG or TIF - the moral is to avoid poorly-written programs.
I think almost all Nikon and (other camera) users ignore the in-camera Rating feature, if for no reason other than it’s difficult to actually use. And I think almost all metadata editing programs ignore the in-camera Rating also (or perhaps treat it as read-only), preferentially using a Rating in XMP sidecars. That’s probably a sufficient reason to treat the raw tag as read-only, just to avoid interoperability issues, even it’s actually no threat to the integrity of the raw file.
In case it’s of interest to anyone, I’ve attached an excerpt from the MWG document about Rating. MWG - Rating.pdf (408.8 KB)
But DOP files are not industry standard and only of value in a PL only workflow. If PL didn’t use either them or the database, we wouldn’t be in the current mess when trying to coordinate PL with other apps, especially when, all of a sudden, DOP files were the only holder of ratings and the database was the only holder of keywords in PL4 and somebody dropped the ball in not guaranteeing a migration path to PL5 where DOP files hold but are not referenced for ratings and keywords are now added to DOP files but not necessarily written immediately to XMP files, but possible to JPEG files.
Indeed. I see one source of the problem as not having a clear grasp of the difference between using metadata for searching and using it as a means of communication.
Were it not for the absence of a decent metadata management and search mechanism in Windows, something that Mac has in spades, there would have been no need to mess around with holding such metadata in the general PL database. As far as I can see, it is only there for ease and speed of searching.
I hate to bring it up again but, “my app™” doesn’t need a database for metadata because the OS provides and maintains one for me. The only advantage I offer is a more user-friendly wrapper around the Spotlight mechanism.
But it is not just DxO that insists on using their own database for metadata. Presumably for the same reason of needing to be multi-platform (Mac/Win), most, if not all, “DAM” apps do the same thing, except they more overtly call it a “catalogue”.
The big difference between DxO and the rest is that most of the rest don’t use a proprietary sidecar file as well as their database, as well as XMP sidecars, to duplicate that metadata and cause reconciliation nightmares.
Sheesh! let’s hope not. I still think the better idea would have been to provide a DAM “plugin” like FilmPack and ViewPoint, which would have had no impact on those who didn’t want such functionality or, more likely, already use an established DAM.
And I still can’t find this FAQ online.
There’s a part of me that hopes they will drop the whole DAM(n) idea. I spent months on the last beta working through what DxO were doing, and managing to iron out most of the standalone problems. But, with all that effort, nobody, including me, seemed to pick up on the problems of migrating from PL4 to PL5 that you have highlighted.
Yesss! I was called in to work as consultant/designer, over a period of seven years, on re-architecting a major retail financial and business management app, and was so fortunate to have the MD who called me in, who wrote the original app and was only too well aware it then resembled a bowl of spaghetti, agree that, if we needed to start from scratch, so be it. We also both agreed that we both had the right to insist our ideas were perfect and that the other had the right to tear them to shreds. One day we had a three and a half day “argument” over a key part of the design, which ended up with us both falling back in our chairs, wide-eyed and totally gob-smacked over the sheer genius and beauty of what we ended up with.
Not to mention the times we would work through a solution, code it and then scrap a couple of hundred lines of code because it became apparent we had either got it totally wrong or stumbled across an API that made all our hard work redundant.
Fortunately, the company was wise enough to carry on maintaining the legacy app, and limiting time and money spent each year on the new architecture, until we ended up with the new version, which was able to simply take over from the old and, if the client needed any customisation, it could be done by a non-programming consultant using the customisation screens we had incorporated.
Unfortunately these opportunities are rare and I look back with a warm glow at the day I was hauled into a meeting of the company’s staff and told that the new product wouldn’t have been possible without my input. Oops, head starting to swell 
That company is thriving more than ever today and expanding its product range, all based on the same principles we started with all those years ago.
Oh, and I forgot to mention that, if the MD ever caught me staring at the screen, trying to find an answer to a problem, he would tell me to go shopping, or a walk, or something. Something which often meant I would find the answer on the way to the shops 
And I was beginning to think what I call “constructive argument” was way out. I wish we had known each other a long time ago.
I deliberately made the point on the beta that I would argue and expect to be argued with and I think it sort of worked, until towards the end, when it became apparent, somebody had set a deadline for release without realising the complexities that no one person could ever foresee and that a “compromise” would have to be made as to what worked and what really shouldn’t have escaped.
All of this should have been discussed during the beta instead of ending up bleeding over the public groups. When PL5 first escaped was released, I kept quiet because I didn’t want to be cause any problems of confidence in an otherwise great product. When all further beta level communication from DxO ceased and it was obvious, from other people, like you, posting, that there were still problems. I then felt I could respond in an attempt to bring some opinions and input that might lead to all of us benefitting from a better understanding of where the problems were arising and how they could be resolved. I don’t claim to have all the answers but it would be nice if someone from DxO would communicate their opinions and reasons for the choices they have made.
In conclusion - if you think I am wrong about something, say so. You know how good an argument can be for finding the answer
@Joanna and @jch2103 sorry I started a reply to jch2013 and deleted the text and started a response to Joanna but …
Joanna thank you for your response to my post I was concerned that I went too far with personal background while I tried to politely request that DxO start interacting more and actually requesting feedback and possibly suggesting tests or investigations that would benefit their development.
Ultimately it is in our interests to help improve the product if/when we can but something (possibly the sheer amount of work fixing PL5 added to the preparations for PL6) seems to be holding DxO back!
If that does not change with PL6 beta testing then …
I can’t really help with testing photo editing techniques and tools, albeit I have favourite programs that I feel have individual features that are either unrivalled elsewhere or the rivals are way too expensive (for me). One bugbear that I have had for most of my photographing life is with colour and “easy” colour correction.
My Panasonic cameras (certainly the earlier models) went “cold” very quickly (blue cast) and were prone to the green cast when under the canopy of the trees and one of the best pieces of software I have used for that (with nearly a single click) is SageLight (which has had a very chequered life). I now have DxO Filmpack so we will see what I can achieve using that but I am looking for a one click (or almost) “fix”,
In the meantime I will attempt to get my spreadsheet analysis finished and post some tests that I have done where the results I find confusing (xmp sidecar ‘ratings’ settings versus xmp embedded ‘ratings’ settings and how different software reacts).
Then I need to get back to clearing and cleaning the loft and a partial re-decoration of the house pending putting it on the market.
Don’t apologise. I was fascinated to find your consulting ethic closely aligned with what I thought was “risky” but had brought such amazing results in my experience. I may be totally wrong but I have noticed that French management can be quite hierarchical, in that what a superior says is right should not be questioned. After my time with the company I mentioned, the MD issued an edict that the developers were not allowed to simply agree without justifying why they agreed and explaining the effects of the topic under discussion, to demonstrate they had properly understood what any ramifications might be.
I think you may well have hit the nail squarely on the head there. If I was able to contribute to project management ( 
) I would be looking at dedicating a small team to doing nothing but finding and fixing bugs before PL6 introduced too many more. Oh, and introducing regression testing to avoid the (all too often) situation where a fix for one bug breaks related code. Unfortunately, with too many software houses, release cycles often blind management to declining quality, which only ends up defeating the goal of increasing product confidence and, ultimately, sales/profit.
I also find myself feeling that the PL6 beta is being held back by not wanting to admit that there is still stuff that needs fixing in PL5 and not knowing what to prioritise out of new features (earning more money) and fixing stuff (earning customers respect)
That is a program that I thought everyone had forgotten about! It was my absolute favorite also for all its short life, just brilliant in how well it did things. And fast… amazing how speedy a program can be when it’s written in assembly language. Such a pity that it never got the attention or respect it deserved.
@sloweddie It was a good program albeit with more ways at doing the same or similar thing than you could “shake a stick at”! Amongst its followers it was got that attention but sadly the strain of the development took its toll on the developer and caused a number of hiatus (is that the plural of hiatus?) before he went off to find another “life”.
He returned so that Safelight 4 could live for those who had changed machine and could not re-register etc. (although a “hack” had been circulated to allow the trial version to be used again, and again and etc.) and anyone else that wanted to try it and promised a new Sagelight but that was back in 2019!
It is still installed on my machine and I compare other programs auto-colour fix with what is available from Sagelight in just a few clicks.
I have also been a fan of Pictocolor for years but when you can buy Affinity (and I did) for less than a mostly “one trick pony” from PictoColor I have resisted.
With so many of my photos being JPG (I only turned on the JPG + RAW option seriously on my G80 in early 2018) I need product(s) that can “fix” both and SageLight is not good with RAWs but good for JPGs.
Affinity is a very good example of changing a firm round. I used there products many years ago mainly publisher. It was a yearly product with many very good parts but became a bug nightmare made worse each year by a new load of new features and even more bugs. I and many others gave up and moved to the boring but stable ms publisher.
Between then and now they have been transformed and could show DxO and many firms how to produce and maintain software. I fear DXO could be heading to the old Affinity model.
@john7 I used to use Serif products, mainly PagePlus on and off, but I seem to have MoviePlus, CraftArtist and PhotoPlus still in my Software Library (but not installed on my current machines). All are now abandoned by Serif in favour of Affinity Photo, Affinity Publisher and Affinity Designer and as a result on my previous purchases from Serif I got an excellent deal on Affinity back in 2019 and one on Publisher a year later.
It took a while before Affinity made it from the Mac to Windows and it looks to be an interesting product if only I could understand how to use it!
It seems to be put together in a way that is alien to me (but obviously not to a lot of others judging by its popularity) and I can manage to do some basic things but …
So I want PhotoLabs to be “perfect” because I can understand that and get it to do most of what I want most of the time! The problem with the current release is that there are a number of niggling bugs and discussing them in the forum is useful on the one hand (other users can add additional information to the issues being investigated) but unfortunately this might be (slightly) off putting to other users.
I apologise if we sometimes seem to get “excited” when we finally (aparently) understand the nature of a problem and then seem to “relish” showing the inner working of the product as we (believe) we understand it, warts and all.
But while I feel a little sad that there are bugs to be found I work on the principle that the more that are found and the sooner they are found the quicker they can be fixed and we can return to using the product with renewed confidence.
So I apologise if the long posts and “excited” ramblings take some of the polish from the product and hope that the work actually helps DxO to fix them as soon as practicable and ultimately helps repair some of the damage to user confidence that has occurred with this release.
I would hope that such apologies shouldn’t be necessary In much the same way that “experienced” developers should never dismiss the thoughts of “apprentices”, neither should they dismiss the thoughts of (usually retired) older developers, who have been round the block so many time they have lost count and who have spent years pointing out woods to those who can only see trees? Wood blindness is nothing to be ashamed of - it is often the result of too much management pressure to “just get it done”, rather than allowing the time for things like regression testing, or even just sufficient testing.
Like you, I am an avid supporter and promoter of PhotoLab and spent more (far too much) time looking for the bugs that escaped the beta test, rather than simply enjoying using such an, otherwise, superb image editing tool.
@Joanna my comment was not intended for the DxO developers particularly but rather to the other users who might have become “spooked” by what we are turning up albeit in features that many (most) may not have used and never intend to use!
It is a shame that this release has been marred by avoidable bugs (although to be honest all bugs in all software are avoidable, certainly in hindsight!!).
It would be good if DxO could find a way for developers to “break cover” more often and engage constructively with users who might have something to offer, particularly in Beta testing. However, we (the users) are not a guaranteed resource and not working to a (DxO) timetable, i.e when family or the garden or the central heating or … “call” then the users’ priorities will change.
There is an old adage that “free advice is worth what you pay for it”; there is an element of truth in it but it is way too simplistic and to “waste” opportunities is just that, a waste, a potentially “valuable” opportunity lost and gone and in losing that opportunity on one occasion further such opportunities may never present themselves again.
@sgospodarenko @Lars @Musashi @platypus This Topic started as a “bug” report with respect to the Tag field not being read by PL5, specifically PL5 not reading a PL5 Tag field.
I initially misunderstood, misread etc. the post and tested PL4 DOPs moving to PL5 and as we have subsequently discovered PL5 treats earlier DOPs in a completely different way to PL5 DOPs!
The Topic then changed direction to ‘Ratings’ and the confusion there was that the ‘old’ (pre-PL5) handling of ‘Ratings’ was to use the DOP but in PL5 the ratings are expected to come from the .xmp data (sidecar or embedded) and presenting a DOP only to PL5 will not result in a ‘Rating’ being imported, this will only happen if there is xmp ‘Rating’ data available.
The table provided by @Musashi clearly show that ‘Rating’ data will not come from the DOP, however, it also clearly shows that the ‘Tag’ data (Red/Green/Grey etc) will come from the DOP because this field is unique to DxPL, hence it has no other place to go other than the DOP (for DOP please also read “database”).
So I did the following
This is clearly a bug and @Lars I apologise for not stating that before. The Table clearly shows what should happen and it simply is not happening!! The table shows that PhotoLab reads the ‘Pick and Reject’ from the DOP but that isn’t happening and my test was on PL5.1.3.
This is not as complex as ‘Ratings’ moving from the DOP to xmp data fields this is a case of the data never changing its place or role and simply being caught up in the ‘Ratings’ change and becoming a WOM (Write Only Memory) item when it should not!!!
So. I hesitate to revive this thread with another separate but definitely related question…
Why doesn’t PL store all edits in the XMP file with the metadata and completely dispose of the concept of a .DOP file? Why do we need two separate side car files? One to manage metadata and one to manage edits seems unnecessary.
As I understand it Lightroom saves adjustments in the XMP too, so other tools should already be aware not to touch sections of that file that don’t belong to them.
So…
Why can’t all of the data inside a DOP file be embedded in an XMP file. Then we avoid this whole issue of two copies of supposedly the same data in two different files.
TBH I’m naive to many of the workflows being discussed here. I do a lot of high volume stuff (events) and almost completely stick to one tool for the edits. So don’t flame me if its a crazy idea.
Personally, I think it’s a great idea but, unfortunately, it might be a bit late in the day to change and there are a lot of DOP files already out there, from various versions of PL, which might need to be maintained if they are being passed back to an earlier version, which wouldn’t support XMP for image edits.
Although - bright idea - why not change to XMP and provide an “export to DOP” functionality for files that have to be passed back?
For backwards compatibility new versions can import DOP’s and create XMPs… Or just read DOPs and if any edits, then create XMP’s and delete the stale DOPs.
I am sure there are cases, but perhaps not that many where people are going backwards from 5.0 to 4.0 or something earlier. I think in most cases, people understand when they edit on a newer version they can’t transfer back to the older version.
I just think all of this talk about synchronising keywords and ratings between XMP, and DOP, and database is unnnecessarily complicated because of this proprietary DOP format. So why not embed the edits in the XMP and dispose of the DOP completely?
I couldn’t agree more. I have lost count of the number of times I have mentioned SPOD (single point of definition) and am of the strong opinion that it really is about time it was implemented, rather than being ignored and yet another source added, so we now have the DOP, the database and an XMP file, with varying degrees of duplication.
@sgospodarenko Svetlana, has this kind of discussion come up before? I have no doubt such an integral change like this could potentially be a tremendous amount of work (depending how the code is structured) but I do believe this would provide long term benefit and perhaps worth the effort. If it makes sense, I can make this a separate “feature request.” But it really is tied to all this confusion in the 100 comments above about where the metadata comes from.
Within a DxO World, the SPOD is DPL’s database and exchange with other apps just recently came up with DPL’s .xmp sidecars… I’d rather have DxO get DB maintenance up and running than spend effort in the fusion of the sidecars, although this could be interesting in the long run.
It depends. For some the SPOD for edits is the DOP sidecar. I cannot bother launching PL every time I want to move an image file. And I archive image files to cloud storage and sidecars as well should I ever need to edit again. If they need to be edited they won’t be restored to exactly the same path as the database is aware of. So no. In my workflow The database is a temporary caching of the data including management of other temporary things like cache files for performance. That’s it.
