I have made a new default preset for PL 8. But when I open old RAW files already been open before in PL, it is still using the old preset. I have to manually change to the new default Preset for every photo I’m coming back too.
Is it possible to find a way for it to automatically use the new default for all photos?
I’m getting this for images I haven’t opened before in PL too.
You are sure that you have selected your new preset as default?
No, you can not.
- You must manally
- You can rename your folder BEFORE launching PhotoLab to simulate new photos.
Pascal
Yes, quite sure.
Yes, that’s how it works.
- PL applies the default preset only to “newly encountered” images.
1 Like
As @John-M has stated the preset is for images that are new to DxPL.
Even if there is no DOP created, and my testing has shown that the application of the new preset is not enough to cause the creation of a DOP (at least in my testing), the original preset applied the first time the image was discovered by DxPL, is retained in the database entry for that image and that image is not new because it has an entry in the database!
You can select an entire directory of images easily yourself , but beware any images that you have applied additional edits to, and apply the new preset but that is the best I can suggest.
If you delete the directory in DxPL then it will be well and truly deleted, from the database and from disk.
If you make any edits after the “new preset” has been applied or simply export the image with just the “new preset” applied you will have a DOP as well.
So if you decide that is a “cunning” plan then
- Back up the directory, if there is a mixture or images without DOPs and images with DOPs you need to decide if the DOPs (and the edits contained within) should be retained or purged (deleted).
- Delete the directory using DxPL, it will be gone from the database (except once in my case, many years ago) and from disk.
- Copy the backup to its original directory.
- Rediscover with DxPL with the new initial preset which should then be applied to all new images in the restored directory, i.e. all images that don’t have a DOP in tow (and you might have deleted those from the backup anyway)
I just did this by deleting the PL database. Choose new default preset. Open PL.
Then each time you open an image, new default will be applied. Or you can just index your entire folder structure an it will apply new default to all of the images.
1 Like
@OldFartAtPlay That will work after you have completely destroyed all the existing database entries.
I felt that it was unlikely that you would be prepared to throw all the existing DB entries away just to fix some entries but if you want all the existing entries to adopt the new edit then your solution will do it for all images that don’t have a DOP.
Thanks a lot for all your suggestions, but I feel the solutions are more work than the problem. So, I guess, I just have to live with it.
Anyway, thanks for trying!
Luckily, NO. You would not like your previous edits to be overwritten. New preset is automatically applied to all new photos, rather than to all photos, where new means not in the database and DOP file missing (as far as I know).
Personally, I use ‘6 - No corrections’ automatic preset. This is because I do several types of photography. Usually I select all new photos in a “session” directory and apply a matching preset, but for vacation photos I have to make several selections (btw, using color labels is a good idea in this case). In some of my main, initially applied presets, I don’t use Distortion correction, so the “OCO” auto preset is not good for me, hence I use No Corrections (which is also safer, if some strange bug was introduced in PL update, which could prevent you from starting PL).
User defined presets change only the settings which were enabled just before saving the preset. You may find it in Help searching for the so called partial vs full presets. For example, I would never leave White Balance, Crop, Horizon, or Perspective tools enabled in my preset, because it would potentially destroy my most hated work 
.
As a side remark, in a preset you may set some settings in a group but keep the group disabled. If you apply the preset to an already edited photo, and the group was not active, you’ll see your new values set but inactive. If you wish, you can activate them with a single click by activating the group. I use it for some of my presets and HSL or Selective Tones, not sure if this feature would be useful to you.
I have just modified one of my presets, which was prepared using the above precautions, and I just applied it to the whole directories, or photos with selected colors only. It’s Ctrl-A + Apply preset only. Another way would be to apply a new preset to one photo only, copy adjustments, select the photos, paste selected adjustments only – e.g. if your preset was full preset, or if you didn’t want some specific corrections to be overwritten.
1 Like
Yes, that’s correct … I added the emphais on “and”
If there’s a dop file then it is not new.
If there’s no dop file it can be new.
A new file doesn’t have a dop file. An imported file with a dop file is to be considered as not new.
George
I quite like that emotive language! We could spice up menu entries by using ‘destroy’ instead of delete, eg ‘Destroy File’. And maybe replace the trash can icon with a nuclear cloud!
All of my many thousands of images had the ‘DxO Natural’ default applied when I indexed my photo library. I have only edited a handful so far - and those will have dop files. I have no projects or keywords yet, so I haven’t ‘destroyed’ anything except the application of defaults that I didn’t want.
Cheers
@George Your original post was short, and to the point and mostly accurate, particularly with respect to this topic.
My additions below make it less easy to understand but I believe are slightly more complete (but I cannot guarantee that they cover 100% of all the variations possible).
True in that DxPL of one release or another has been used with the image, with one database or another, and a DOP has been created.
But it still might be “new” to the database that is currently in use.
At which point, if then discovered, either directly by the user or indirectly via indexing, the contents of the DOP should/will be applied to the image, providing the DOP is from the current or an earlier release of DxPL.
In this case the new (default) preset, as defined in ‘Preferences’, will be ignored i.e. it doesn’t apply because the image isn’t “new”.
However, if it is from a later release the DOP contents will be ignored and
- The image will be treated as “new” and the appropriate preset for new images will be applied and the image will be assigned a new UUID.
- The current DOP will be overwritten by a DOP containing a new UUID and the initial new preset, + any edits the user may then have added.
- But that (new) DOP created at step 2 cannot be carried back to the future release without causing an “Unwanted or unexpected” Virtual Copy. Or rather cannot be carried back to the future release with a database that holds that original edit because the new UUID in the DOP will clash with the UUID in the database… One of the dangers of moving backwards and forward between releases.
Even if it is from the current or earlier release the DOP may not match the database entry, (typically) determined by whether the UUID of the database entry matches the UUID of the DOP.
If that test fails then “Unwanted or unexpected” Virtual Copies will be the result. Typically the database entry becomes the [M]aster of DxPL(Win) and the DOP edit becomes VC[1] but that is further complicated if there are also user created VCs in either the DB entry or the DOP entry or both!
What I haven’t tested is what happens if the UUIDs match but the edits are actually different, i.e. how is that determined e.g. using modification timestamps or not!?
Agreed, it can be new and it will be new providing the database doesn’t contain an entry for the image already. What happens if the image timestamps do not match the database entry timestamps I am not sure but I think DxPL will simply ignore that fact and the newer edit will not be applied, I believe, i.e. the database will take precedent over the DOP.
Sorry but that is where the pedant in me added the statements above.
A new file can have a DOP file as I explained above, i.e. it is new to the database in use but providing it is not from a future version the DOP edits will be applied to the image as it is imported.
But an imported file with a DOP will be treated as new if it comes from a later release otherwise it can still be new to the database and result in a new database entry but typically with the same UUID as the DOP (unless that UUID is already in use) and will adopt the edits from the DOP and not invoke the new preset edits.
I preferred the simplicity of the original @George but the devil is sometimes in the detail.
@OldFartAtPlay It was intended to remind the user of what is at stake (or not!)
@OldFartAtPlay For once I didn’t mention those “risks” associated with destroying the database and with DxPL(Mac) I believe you will also lose the ‘Advanced History’ which is preserved across restarts which simply doesn’t happen with DxPL(Win), i.e. ‘Advanced History’ only survives for each “session” on a Windows system.
The loss of ‘Keywords’ isn’t a given because the keywords can be stored in three places depending on the settings a user chooses, i.e.
- The database
- The DOP
- The image (directly for RGB images) and in a sidecar for RAW images.
The first two are automatic unless you suppress the creation of DOPs, which would not be one of my recommendations.
Item 3 is more complicated because you cannot have an automatic metadata read without also having a metadata write. Some users object to having the format of the meta data in the image being “adjusted” by DxPL.
It is possible to do manual Reads, and if required manual metadata writes.
The metadata in the DOP will be read and used only under specific ‘Preferences’ settings, which I can provide but this post is too long already!
Regards
Bryan
Thanks for taking the time to explain that, interesting. Cheers
You did dig in the database, I didn’t. But so far I could explain things for myself with the key path/filename.
PL reads per directory. Opening a directory is adding the path/filenames to the database. When adding the new path/filenames to the database, then the preset is added. This is not seen as an edit but more as a part of the demosaicing proces as I may call it. When PL sees a new dop file compared to what is in the database then a VC is created.
About indexing, I’m not sure but it might be possible that PL first reads the image and stores the path/filename in the database and is indexing the data from the database. I haven’t checked anything. But when working in this way the indexed new files will get the native preset.
Again, it’s not checked but I can explain things with it.
George
When the user selects a directory the contents of that directory are checked against the database to see if they are already present in the database. If not then the directory is imported into the database and the ‘Preferences’ initial preset applied at that time. DxPL then continues to watch that directory for anything of interest until it is closed down or the user moves to another directory.
Originally the indexing process was an asynchronous activity, i.e. the user could continue to use DxPL while the indexing was taking place but with PL7 that all changed, on Windows at least. When indexing is now running the user is “locked out” until it is finished indexing or is terminated by the user.
Both processes are essentially identical (or so it appears), i.e. a user selecting a directory versus the indexing process selecting a directory, and since I frequently use images with the same name in test after test after test DxPL appears to handle items with the same name but residing in different directories perfectly happily.
I do dig into the database and frequently clear the database before starting a test so that the data is easier to find in a much smaller database, the program I use is “DB Browser for SQLite” and is freely available to anyone.
I also capture and analyse DOPs and use a program called Folder Monitor to monitor directories in much the same way that DxPL monitors directories watching for a change in the status of the contents and then investigating whether that change is of interest. Folder Monitor is also freely available.
As I indicated above there is no difference in what happens when an image without a DOP is discovered on disk for a directory or image not already in the database by either of the two discovery mechanisms, i.e. user selection or indexing.
If the “discovered” image is not already in the database then it will be added and the preset selected by the user in the ‘Preferences’ will be applied just as if the user had applied that preset themselves.
I had/have no “complaints” about the summary you wrote and stated that in my post but decided to use the opportunity to add all the things I and others have discovered about the fringe conditions that can exist in and around the discovery process.
Providing the conditions you stated in your original post are upheld then whenever an image is discovered, without a DOP, that is not already in the database then the ‘Preferences’ preset will be applied.