Hi henry,
I believe there might be a few things getting mixed up here: namely d"isplay of raw file adjustments by foreign editors" within PSu and accurate interpretation of color profiles within the application itself.
PSU should either generate its own previews or take them from the underlying OS.
I agree with Michael that this comment is nonsense! No "underlying operating system" be it Mac or PC has previews or thumbs stored
within. Like any other application them operating system
also has to render these previews and for faster access typically stores them in its cache. So, if you browse a folder with image files in Mac's Finder or Window's File Explorer that application (as any other application) has to either render the previews on-the-fly or re-create them each time you access that folder or accesses them from the cache.
Rendering
accurate previews, however, depends, as Michal points out, on the software having access to any image adjustments made by any other software! Lightroom's algorithms are proprietary and I very much doubt they share them with MacOS so that the operating system creates these previews "de nuevo" using Adobe's algorithms. Much more likely the MacOS simply uses previews embedded by Lightroom into the files and displays those in lieu of its own (operating system) previews.
Now, PSu, as Hert points out, does
not use the Lightroom thumbs/previews, but it creates its own! This may be seen as problematic insofar as PSu cannot know how a raw file has been adjusted in Lightroom, it can at best only second-guess. Under "Preferences - File Handling Settings" you can see that there are currently three raw editors supported: DxO, CaptureOne, and Lightroom. I suggest, if you go back and forth a lot between Lightroom and PSu that you experiment with the different settings "none, elementary, approximate" and choose which particular thumbnail rendering is most appropriate for your workflow, i.e., which one most closely matches how you view these files in Lightroom. Theoretically "approximate" works best, but on my own system, where I use DxO I noticed that "elementary" seems to do a better job.
Color rendering is entirely independent of this!!! The metadata in your files
should have the color space that the photo was saved in and it
should then be only a matter of configuring PSu correctly to read these tags and accurately translate them into your monitor profile. This I admittedly I have also struggled with for years and unfortunately I have still not quite figured out how this actually works. So, take the following with a grain of salt:
I calibrate my monitor too. Of course you do NOT have to re-create the thumbs each time you do that! Suggesting this is absurd! The thumbs created by PSu should have their own color profile tag and one would assume that this tag would be identical to the one embedded in the image file. PSu color rendering engine then must simply translate this tag into your monitor profile and adjust the thumbnail/preview display accordingly. The next time you re-calibrate the thumbs stay the same, but the rendering will be done to agree with a different monitor profile...
Unfortunately, I have to agree with you insofar that I believe this does not work quite as described above in PSu. I still do not entirely understand how color preferences in PSu are supposed to work. So the following is just my own guess:
There is an input and an output profile that you must select, when enabling color management in PSu. The output profile makes sense. It would be the monitor profile and every time you change that profile (i.e., re-calibrate your monitor) you have to select the new one so that the thumbs are rendered correctly again. No problem so far...
What makes no sense to me is having to choose an input profile! In whatever application you can save the color space to a particular photo. All this does is telling the software how to interpret the raw data of that file. So, if your photo was saved in sRGB the software can match the colors from sRGB to your monitor profile, If it was saved in AdobeRGB then the color rendering machine has to interpret the data differently to translate them into your monitor profile.
Now, Hert's suggestion that you
have to update the thumbs after configuring PSu's color management to me suggests there is indeed something weird happening here. I can only assume that setting the input profile means that PSu creates thumbs and previews using that particular input profile specified, i.e., you might have a file that is in AdobeRGB but your settings are configured to render sRGB thumbs and previews. That to me makes little sense, because you end up with the thumbs/previews using a different color space from the underlying image file. So, instead of a simple one-time conversion (input original file in AdobeRGB - output Monitor Profile) you have a double conversion happening (input original file in AdobeRGB - converted sRGB thumb/preview - output Monitor Profile). Double-rendering, changing the profile twice is potentially problematic and could contribute to artifacts. If you have one of those very high-end monitors capable of displaying the full gamut of wideRGB for example, then these tiny rendering artifacts may indeed be visible; especially if you go from a small color space of your image file (say sRGB) to a far wider one that your monitor perhaps supports. Else, I very much you could spot the difference.
Also: if my assumptions are indeed correct, this indeed means, if you
ever change the input file in your setup you
will have to recreate all thumbs.
But why have that option at all??? Why does PSu not simply create the thumbs according to the embedded profile
of the underlying file (sRGB, AdobeRGB, wideRGB - whatever...) and then individually renders these according to the monitor profile you are using?
Again: no idea, but one reason might be speed
. If the system
knows all thumbs/previews are sRGB then it is not necessary to first
read the tags from the file and images can be rendered much faster. Unfortunately it comes at a price. If you keep changing the input profile without re-creating the thumbs, then you are in trouble, because then the system assumes all your thumbs/previews are in one color space whereas some are and others are not.
Ideally PSu would not have the option to select the input color space but generate all thumbs/previews with a default color space that the user cannot choose himself. I guess that is perhaps how Lightroom works, when you are suggesting you do not need to configure it (not a Lightroom user myself).
Anyway - my recommendation: Choose whatever input profile you prefer, but then NEVER change it again. Choose your current monitor profile as output and change that every time you re-calibrate the monitor (or a different computer). Then update all thumbs (only once, or if you for whatever reason change the input profile, you'd then unfortunately have to do this again).
For me that all works fairly well, though I am not perfectly happy how some thumbs are rendered. For an odd reason it seems that in PSu the DNG files render slightly different thumbs than NEFs or JPGs. I complained about it and Hert has tweaked the settings so the discrepancies are now a lot less obvious. But then: I use PSu as cataloging software not for color proofing. So I can live with that minor flaw...
FYI - that also means I have completely ignored the second one of PSu's tab, the one for setting up printing; I don't use PSu fro printing; I actually disabled color proofing for printing in PSu. I doubt you want to do critical print jobs from PSu anyway since the image editing/adjustment capabilities are fairly moderate. I doubt soft-proofing capabilities of PSu get anywhere near Photoshop or AffinityPhoto (but I haven't ever tested this).
Cheers,
Frank