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.
2 Likes
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.
2 Likes
@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
- Set the ‘Tag’ in PL5 and the expected values were written to the DOP (‘ShouldProcess’ is 0 = Red, 1 = Green and 2 = Grey).
- Closed down PL5
- Cleared the database (changed its name) so there is no database entry to “block” the importation from the DOP.
- Re-opened PL5.
- PL5 started on the same directory and showed no Tags whatsoever.
- Manually importing the DOP sidecar does not work, the Tags remain unset.
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.
2 Likes
@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.
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.
I’m in line with that. With the looming fear of virtual copy doubling in the background and when using the photos on multiple devices, I usually delete the PL database before every start.
Plus, a file based “database” is a toy sollution as it does not in any sensilbly way scale beyond a single workplace. Move it (as an option) to a SQL server (at least the metadata) and we can talk.
Previous discussions about putting .DOP data into an .XMP file leaves PL open to issues if other programs damage or destroy the .DOP data in the .XMP files.
Personally, I rely on .DOP files to store all my edits. I would like to see JUST PL proprietary data in .DOP files and everything else in .XMP files. I do not want to rely on a single database when my photos are stored all over the place (internal drives, external drives, backup drives, archive drives etc.)
Until PL provides the facility to select different databases to work with (like Lightroom or Photo Mechanic Plus) I will not be using PL as my DAM.
That’s why I wrote somewhere correspondingly, stars and colour labels should be common ground with important software – and store them as xmp, not as proprietary data.
1 Like
A single point of definition (for all images) is also a single point of failure (for all images). I favor the concept of sidecar files as the leading location for edits and a database as a secondary and disposable method only used for convienence / performance. This is also the concept of darktable and Capture One sessions (not C1 catalogs unfortunately). Sidecar files are also better for integration with an external DAM.
I understand the .dop sidecar as DPL’s way to store whatever information outside of the database - which is perfectly okay for me. It’s perfectly okay if DPL writes metadata to these files and I’m quite happy withe the structured text (instead of a binary or encrypted) file.
In a perfect world, we could live with either the database or the .dop files because both would contain the same information* throughout and drives would be infallible, software bug-free…
Enter Reality
- The database can be corrupted by buggy software, drive failure or user action
- The .dop files can be corrupted by buggy software, drive failure or user action
- Database and .dop files do NOT contain the same information*
- etc.
If DPL should be more resilient, the following should be done imo:
- Database and .dop sidecars should mirror each other
- Information should be fully updatable, either from .dop to DB or from DB to .dop in a controlled manner and: all issues like the one mentioned in this thread’s title should be fixed
- Database maintenance should be established (consistency check, auto-backup…)
Note: information* mostly means the stuff that we’re interested in and that we can change and edit, but also the behind the scene stuff that is needed to keep the system live and healthy.
@platypus I am a little confused by your comments!?
What information are you referring to I would suggest that the DOP contains the vast majority of the information in the database, just in a slightly different form, The data in the database is just that i.e data the “metadata” that controls that data are the fields in the database that the data occupies, when that is externalised then some additional metadata has to be added but little or nothing is actually left behind!
Please identify what data is actually missing from the database data in the DOP, there is sufficient for the database entry to be recreated from the DOP, that statement is also true for the ‘Rating’ etc. fields that are currently “information” only (Write Only Memory) fields which PL5 currently does not use.
As for the corruption issues that is true but if DxPL manages to corrupt there own data then they can also corrupt the xmp data, albeit that might well be handled by library software that has a long pedigree for handling such data.
-
They do mirror each other in the only way that any external data can mirror a database, i.e. metadata plus data versus database fields + data!
-
It is controllable via the sidecar options in the preferences and the import and export options, these and the AS (auto sync ) and read from and write to commands are arguably mirrors of one another!?
-
Database backups are available but without the nagging prompts of other software, if you want the nagging prompts that can be very easily added I would suggest. As for consistency checks please read what follows below!
There are many things wrong with the PL5 release in particular but the issues highlighted in this post in this post are generally not amongst them! The issue of using the DOP [M]aster WOM (‘Rating’ , ‘keywords’ etc is a moot one and needs discussion with forum members!
Now to what might really be wrong with PL5 but which I have not seen any evidence of yet. The database software that PL5 uses is SQLite, the same database software that most other DAM etc. software uses, ACDSEE uses either DBase of one of the variants that sprang from DBase with a much longer heritage. This is possibly one of the reasons that people talk about loading 100,000s of photos into such a database successfully.
The only thing that worries me about PL5DB is that it is very “light” in structure compared with some other similar databases. The metadata is joined to the image data by a simple numeric key, i.e. the ‘metadatas’ structure is joined to the ‘items’ structure by a single number and you get from one to the other by an index. There appears to be no corroborating data between the two entries, they are linked by what “we in the database” industry would call an “unprotected” link.
The software I supported for 36 years provided such facilities directly to customers coders, it also supplied “protected” links and we could always store the associated data in a structure that could be accessed via an index.
The mechanism used by PL5 is very cheap on space but cannot be successfully policed (consistency checked) because there is no corroboration between the 2 structures, if a key was stored with the metadata e.g. the image name then some corroboration exists to be checked but in my testing I use the same image countless times!?
There are Uuids all over the place and one of those would be suitable to verify that the correct data has actually been accessed when a simple pointer has been followed. Without that **unnecessary duplication of data within the database it becomes difficult to police links between structures and potentially recover from any database damage or even detect that anything has gone wrong!
Much has been written about single sources of data and the dangers of replicate becoming replicake in posts on this forum but I am afraid there are places where duplication is arguably essential. I have not studied the databases of the other system in detail but they are way more complex that PL5 but in many instances they are also more sluggish than PL5 when updating!
PS:- @platypus I am sorry if the above is a little critical of your post, I concur with almost all you have written about improved directory management for PL5 in other posts but I feel that this one is being overly critical. You have not specifically identified what is actually at fault??
One area that has niggled me for a long time @sgospodarenko is the mostly useless item that heads up the ‘Advanced History’ palette, namely
That piece of information is held in the database and is present in the DOP and I believe I have seen complaints from a long time ago on the forum but I feel that it is essentially completely and utterly useless!!
What I want (very parochial!) is a record of the last preset that I applied, i.e. because arguably my edits will be based (to at least some extent) upon it, in addition the creation of any preset should also be added to the ‘Advanced History’ and I would like that stored (only the last one) and retrieved because those provide some “provenance” for the edits that I then see before me!