Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
81
I don´t think we have a lot of differences looking at this really. Developers can´t have that really but we need a system with one truth or at least a clear and more robust masterdata handling than DXO offers today despite it has got a little better now with the system always putting XMP-filedata first at least. We still need better fault tolerance, better tools to keep data in sync in a pretty messy environment. As I have described earlier there is nothing today that restores or repopulates all data automatically if a database crashes. It will continue to resync the metadata when the user opens catalog for catalog but there is nothing that restore all the data in the background.
There is also a confirmed problem I just revealed with the Projects. Let’s say you are a user using both the Projects and wanting to just use DOP and of that reason prefer to delete the database regularly. What then with the Projects and External Selections. You will lose them now every time you will kill the DB. The problem choosing between using a DB or not has to be handled in a more controlled way than the one you are pleading for today. I understand it works for you but it certainly doesn´t for a lot of others.
There is not just DOP or XMP but DOP+XMP+RAW and then there are three files that always have to be handled in parallell. Luckily for me Photo Mechanic do that transparently and safely after some configuration but not all software does and that happens to be a severe problem too. It is a source to failures if you don´t look up and the thing is that you have to look up continuously. Unfortunately, not all people have our knowledge about how Photolab handles their and our data either. DXO has created this mess and it is their responsibility to make Photolab as fool proof as possible when it comes to the data integrity issues.
I have never relied on the database to manage my photos for one simple reason: I cannot control what goes into the database and what does not!
I only want some photos in the database and not every folder I visit. Here is the reason: I manage photos in year folders, ie I have a top level folder for each year and then sub-folders for other things. This is mainly for archive purposes where I will archive a year to offline storage.
What I used to do with Lightroom was have a catalog for each year (and sometimes a folder for a special event like a holiday) which is just for photos in that folder. I could then choose which catalog to use and everything worked very well because I could choose which folders to import into each catalog and then archive the year folder along with the catalog - a very elegant solution.
Unfortunately I cannot do that with PL, so I choose not to use the database and delete it occasionally. I have never had an issue with losing a dop file but if I do I can simply re-edit the photo.
1 Like
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
83
Maybe it´s better for you to use Photo Mechanic together with Photolab then using ImageLibrary which I think you do already, don´t you? There it is a much better flexibility in PM than in Lightroom or any other Image Library really in the most common converters that all have the limitations to one database at the time active.
Then you really don’t need the database in Photolab at all if you don´t want to use it. PM Plus gives you all the possibilities you need to create “Projects” too. In PM there are Collections, Snapshots you can save and even a possibility to save really complex filters if you want too.
As you know but maybe some others don´t you even have the possibility to search over all your year-databases at once too if you want. No converter today what I know of have those possibilities.
Personally I have no problem with the fact that the Photolab ImageLIbrary is a metadata mirror of my images in my image folders that are indexed by PM. Infact, I appreciate that because I then have a possibility to monitor that the metadata is correctly updated. I also have the possibility to search the images without needing to switch between PM and Photolab of that reason. If you have an external software integrating with Photolab you even can control in detail what images you want to edit instead of always having to open a whole folder at once and maybe experience unnecessary performance problems.
Yes I do use PM+ and was part of their beta testing team too. What a difference that experience was - so responsive from their main developer, Kirk Baker.
I did find one issue that LR was better at and that was relative references to images. In other words, references to image locations on disk was relative to the location of the catalog, so moving the whole folder structure to any other location was not an issue as the catalog could still locate the images.
In PM+ this was not so easy or as elegant.
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
85
There is no one like Kirk Baker I think. He is just phenomenal. He has helped me a few times with the issues I had with the integration between Photolab and PM. Well there is also Ed Hamrick at Hamrick Software, the guy that made probably the best scanner program on the market - Vuescan.
Concerning the references I find PM rather flexible when it comes to indexing but a little unsmart since it´s static and not dynamic like some other DAM-software that for example automatically can handle appends and deletes and updates automatically as long as these changes takes place under the main topfolder that is the folder the index points to. I have asked Kirk if Camera Bits could fix anything like that but he has been reluctant to that since he/they think it might compromise performance.
Still I think it´s an advantage that you for example can have a database/index indexing USB-discs without problems since they have an off-line handling. You can still see and handle the metadata with the help of the previews even if the images are not accessible themselves. It´s a good feature for example when you need to demonstrate things without necessarily having to have the physical access to the image folders on the computer. It´s in fact easy to move a whole folder structure in PM too.
Many these days also have pretty small fast SSD-discs where they store PM Plus index databases and keep the images on portable fast SATA SSD or harddisks with a lot of space. These USB-discs are great value for the money and have got really cheap the last years and PM’s off line features are really perfect for this since they are developed with for example mobile sport photographers in mind.
I am still learning new things and today I have found out how fun, effective and useful the GPS-mapping tool in PM is. I have seen a few of these implementations through the years and this one is the first I have found effective enough to use. PM is all about speed. Sometimes the coordinates can be of great value.
There is more than one viable way to organize and edit RAW files and organizing the edit results, that’s for sure. And all of them have their own drawbacks, risks for (user) errors and also risks for developer failures, up to the point of “What to do if the manufacturer discontinues or abandons his product?”
@zkarj Perhaps but things are not as bad as they could be for DxPL(Win) users as I have “discovered” (finally seen what was right under my nose). I knew that the ‘Remove’ command was active for “missing” images and had verified that it worked but I had completely overlooked the ‘Fix path’ command.
Summary of what appears to happen with DxPL(W) with respect to the “lost” images I have encountered or contrived, which may or may not cover the situations that other users have encountered.
In the following examples all adjustments to the image or directory, existence and/or name, are made by the user with software external to DxPL(W), i.e. DxPL was not instrumental in making those changes.
Deletion (or renaming) of images from (within) a Directory:-
If a directory is open in DxPL(W) when an image or images are deleted from the directory, or the images are renamed, then the original image(s) are removed from the database (and the display) automatically.
If a directory is not open in DxPL(W) when images are deleted then nothing will happen, i.e. there will be no “garbage collection”, and those “deleted” images can be discovered via a DxPL ‘Search’ and/or via a link from a ‘Project’ or by navigating to the directory that contained the now “lost” images.
If/when a user navigates to a directory where images have been deleted or renamed then the adjustments will be made to the database (and the display) immediately to reflect those changes, i.e. garbage collection of database entries will occur automatically.
If the user locates images via a ‘Search’ or from a ‘Project’ and these images are “lost” (i.e. still in the database but not on disk) then the image(s) will be marked with an “!” and a thumbnail will be displayed if still available in the Cache otherwise a warning will be displayed. The main image of DxPL will indicate that the image is unavailable. Any further work to remedy the situation is user driven (please see below)
Deleting (or renaming) a Directory:-
If a directory is open when the directory is deleted (or renamed) then the contents of the directory is removed from the database immediately.
If a directory is not open in DxPL(W) when images or the directory are deleted then nothing will happen, i.e. there will be no “garbage collection”, and those “deleted” images can only be found via a ‘Search’ and/or via a link from a ‘Project’, or so I believe. Hence, the images within the deleted directory are “trapped” in the database and the directory cannot be found to remedy the situation because it doesn’t exist!
Remedying the situation of “Lost” images, when encountered:-
When a “lost” image is encountered via a ‘Search’ or via a ‘Project’ link then with DxPL(W) two options are available to the user (with respect to an image marked with an “!”)
The entry can be removed from the database using the ‘Remove’ command (please note that this command is also active when the image is present and will remove both the database entry and the image on disk and the DOP and any xmp sidecar if used, a warning is given!)
The opportunity to ‘Fix Image Path’ is also (only), offered in the case that the database entry is present but the disk image is absent (“lost”)
When attempting to ‘Fix Image Path’ it is possible to select one or a number of images to “repatriate” to the appropriate directory (new location) that the user navigates to via the command.
This appears to be another difference between DxPL(W) and DxPL(M).
When I did these tests I originally wrote “Sadly, DxPL(W) does not “remember” the directory from which the images were retrieved, a sad omission because that would make it easier to return to “retrieve” more”.
However, on a subsequent test I found that DxPL(W) returned me to the same directory to “collect more strays” so I need to do some more tests.
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
93
@Stenis perhaps but for many users reading this forum English is not their native language, which complicates things.
Unfortunately, the text gets longer when you feel that you need to be totally unambiguous and leave nothing to guess work for the reader i.e. “dot every i and cross every t” as an English expression goes.
But it provides a reminder to me of what I think I saw at a particular point in time and this is with respect to DxPL(W) 6.3.1 and I am not exactly sure how long the command has been available
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
95
Well Bryan, I don´t think it would have helped with the native language, because it i would have been exactly the same if it had been swedes writing to swedes here. This is more a matter of which generation and social class you belong to and if you have been thought how to read and write properly or not.
Sometimes it is hard to analyze and describe complicated causalities in a few words. There are often no short cuts to find really - it´s just to read and try to understand - and if we don´t we have to ask questions.
We can always translate with Google Translate. It´s just fantastic and works surprisingly well most times even if it´s not perfect. Part of my family emigrated to America early in the nineteen hundreds and the can read my blogs despite they are in Swedish. After they activate the link in the blog, everything they do on the site will be translated on the fly which is pretty amazing.
Just click on the translation link if you will see how it works:
DPL on macOS seems to be a much simpler animal as far as DB maintenance is concerned.
Case A: DPL is open and pointed at “Folder X”
Rename, add or remove a file in “Folder X” with Finder and DPL tracks the change
Rename, add or remove a folder in “Folder X” with Finder and DPL
a) tracks the change if “Folder X” is displayed in DPL’s sidebar, starting from the user home folder
b) does not track the change correctly if “Folder X” is displayed in DPL’s sidebar, starting from a direct link (in the Finder sidebar) to that folder, but that’s a Finder update issue
Case B: DPL is closed
Any change that was done
a) is ignored as far as database contents is concerned
b) will not be cleaned up by DPL automatically
c) can lead to things that DPL’s search finds, even though they were deleted
d) can lead to seemingly new things which will be imported (indexed) even though only the path has changed by moving or renaming things
c) etc.
Remediation
Delete files to remove them from DPL’s DB…which does not work, if the files that should be deleted are absent (or renamed as in case B above)
No other option (menu item) available in DPL versions 6 and before
Restart DPL to remedy the Finder update issue mentioned above
Delete the database
Possibly other manual exercises that could easily be omitted
if DxO provided proper DB maintenance functionality
Update: I found that DPL seems to clean up the database when I delete missing files (first item of "Remediation section) even though I got that error message…but folders keep proliferating: Several “siblings” can be found in the DB, even though only two folders exist on the drive.
