I sometime use HQ too.
With low iso and well lighted scene it is still usefull and way faster than AI denoising.
I sometime use HQ too.
As a rule, I use HQ in most, DeepPrime for high iso and XD in rare cases.
For a while, I used DP as default, but reapplied some grain (needs FilmPack) to make things look like Photos.
which build version do you have as test?
it could be something what’s not right,
i experience also some problems sins update. my specs
I don’t think that is my issue. Id did pretty good when I turned off DeepPrimeXD and turned out I didn’t need it.
I just ordered a Mac Mini M1 16G w/10GBE that popped up on Apple Refurb for a good price. If I end up getting an Air later, I have a really old Mac Mini that I use for a DVR that I have wanted to upgrade so this will have a home one way or another.
Well I might have ordered that Mac prematurely. I just found this thread - Win/Mac & Database - #15 by platypus which explains that you can’t share your database between Mac/Windows machines (I’m not even sure you can share it between same type machines). I may need to start a new thread for this, but figured I’d come back here first.
I keep my master RAW files in a NAS, organized by year and then shootname-shootdate. Its pretty simple and been that way for a long time. I have always kept my LR libraries synced from the NAS to all my computers. I don’t use them at the same time and assure they are allowed to fully sync before switching devices.
Now the plan with PL6 was going to be to continue this as I have been and the side cars would just get dropped into the master folder. Now my question is if I do that, and allow each computer to have its own database, will the changes to side cars accomplish migrating changes from one database to another? As an example, I load an image to the NAS. I open it in PL6 on my SurfacePro. I make an edit and close it. I later go to the Mac and open the same file on the Mac. I would expect the sidecar to update the Mac database. I make an edit to the image on the Mac. I then close it. I go back to the SurfacePro and open the image again. There is now a newer sidecar with the file then what the SufracePro database has, so I’d expect it to be updated.
Will this work?
Database doesn’t matter.
Just copy the RAW files with the corresponding sidecar files, and the database will be reconstructed.
Been using PL for 4 years now, and I have never cared about the database: the sidecars are all that matters.
Only true if you e.g. don’t want to find images through DPL’s search functionality.
Try it! Can’t help you there, both my computers are Macs.
Please note that DPL on Win and DPL on Mac have slightly different features. → Expect some hiccups.
Absolutely! For me PL is a RAW editor, and the absolute best there is (not perfect, but the best). Full mark, and stop.
Search and cataloguing functionalities mean nothing to me, there are much better programs if one is interested in those functionalities. For me, a RAW editor/developer must do what a RAW editor/developer should do, and no more.
Agreed, and naming the scope (your needs) is even more important than the statement (doesn’t matter) itself, if the subject of the discussion has a wider scope than one’s own.
OK, so then I would select the setting on all computers to turn off the database, right?
I have never used that functionally in many years of using LR. I use the database to store my edits in LR, nothing more. I don’t add keywords to the images. My catalog mirrors my NAS folders which are very simple. For sports, I have folders organized by sport and then by shootname/shootdate. For everything else I have folders organized by year and then by shooname/shootdate.
The one feature I use extensively with LR is refinding a folder. I initially work with the folder in scratch space on my local SSD for speed. It is backed up to the NAS immediately. Over time I let it get purged from scratch and if I need to reaccess it then I can refind it on the NAS. I think with PL6, if I only use the sidecar files, then I will be able to do the same thing and make sure that I’m backing up the sidecars to the NAS folder as I use them. That is a little more work. I will experiment with just working straight from the NAS as the new Mac is 10GBE and the NAS is 10GBE. Depending on what I can do with this, and possibly adding SSD cache to the NAS with the 10GBE, I may not need to mess with a local scratch space.
And that may well be the approach DxO is taking with PhotoLab. For me, I’d like a more integrated workflow that maintains a consistent user interface and eliminates any kinks and seams.
Well, no, let it reconstruct the database from the sidecar files after the migration to the new computer. It doesn’t hurt, it’s completely transparent. My collection of raw files and sidecars is organized in folders more or less like yours (name of place, year, session), and I have deleted the database several times. It has always been reconstructed automatically.
I might have too many thoughts going here, so to be clear on what I’m talking about on that last bit, let me clarify. I am talking about adding a Mac Mini to my Surface Pro and running PL6 on both of them, leaving images and side car files on the NAS. Editing could happen on either machine. If the database were left in tact, my understanding was that it would potentially cause problems when it conflicts with the sidecar.
Now I went back into settings and don’t see a setting to not use the database so not where I got that from… so I suppose I need to just test this and see what happens trying to use the Mac and Windows machines on the same image file in a NAS folder (not at the same time).
No, you should be fine! The sidecars on the NAS take priority on the database. Actually in your case on the two databases (which would reside on the two machines).
@convergent The database is an integral not optional part of the product, which some users consider to be redundant and “destroy” the database whenever possible using the DOPs to hold (and transport) the edits.
@Lucabeer I don’t believe that is the case, if the UUid of the DOP does not match the UUid of the image in the database then the database entry is the [M]aster and the DOP becomes the Virtual Copy, e.g.  not the other way around and deleting the [M[aster results in the [M]aster and any/all VCs being deleted in one operation. Deleting a VC results in the loss of the VC only, i.e. the [M]aster entry is just that!
@convergent as I described above we have the potential for UUid clashes leading to Virtual Copies!
Hence, the principle that some users adopt where the database is considered to be an inconvenience/irrelevance and treated as a temporary structure and is effectively “destroyed” after an editing session and replaced with an empty database before the next editing session.
The databases are different between Windows and Mac and not interchangeable whereas I believe that the DOPs should/may be interchangeable but since I only have Windows machines I cannot explore/confirm that issue.
The Windows database can be located “anywhere” and the Mac database resides in a fixed location (I believe).
Windows does not maintain editing history beyond a “session” unlike the Mac version.
If you can live without having the Advanced History of the Mac and the projects of the Mac and Windows then you may be able to co-exist between the two systems otherwise you will provide an ideal candidate for us to ask when we want to know what does and does not happen on “the other side” but …
I destroy physically before DxO is fed with a raw - below is a part of my shell script that launches DxO from FRV
MODE CON COLS=16 LINES=1
REM next we delete a folder from RAM disk ( mine is Z ) with .DCP camera profiles used by DxO PL6*
RMDIR /S/Q Z:\DXO.DCP
REM next we delete a folder from RAM disk ( mine is Z ) with DXO database
RMDIR /S/Q Z:\TEMP\DXO
REM next we extract camera model from raw passed as a parameter using exiftool and put into a variable*
FOR /F "tokens=" %%i IN ( ‘exiftool -s -s -s -model %1’ ) DO ( SET MODEL=%%i )
REM next we remove ALL spaces from the variable - it makes easier to compare later*
SET MODEL=%MODEL: =%
IF /I %MODEL% == ILCE-7RM2 ( xcopy /E /Q “C:\Program Files\DxO\DxO PhotoLab 6\DCP\A7R2*." Z:\DXO.DCP\ 1> nul 2> nul )
IF /I %MODEL% == X-H1 ( xcopy /E /Q "C:\Program Files\DxO\DxO PhotoLab 6\DCP\XH1*.” Z:\DXO.DCP\ 1> nul 2> nul )
IF /I %MODEL% == CanonEOSR5 ( xcopy /E /Q “C:\Program Files\DxO\DxO PhotoLab 6\DCP\R5*.*” Z:\DXO.DCP\ 1> nul 2> nul )
REM prestart photoshop if it is not running already as this crap takes time to start
tasklist /nh /fi “imagename eq photoshop.exe” 2>nul | find /i “photoshop.exe” >nul
IF NOT errorlevel 1 ( goto PSRUNNING )
START “PS” /B “C:\Program Files\Adobe\Adobe Photoshop 2023\Photoshop.exe” -NoSplash
etc., etc, etc
I realize that some people have more complicated editing environments, with multiple machines and multiple software titles, and for them the database seems to get in the way. However, for those of us like myself with more simple requirements, e.g., using only PhotoLab and the other DxO products on a single computer, the presence of the database is rarely an issue at all. I have never had a single problem with the database in the almost 7 years of using DxO’s software on almost a daily basis.