Velvia is only for the JPG…no impact on raw
Are you talking Display profiles or working profiles that you are setting this way??
May I still request that you click on the ‘write sidecar button’ in the darktable organizer , in both Linux and windows, and then share the created xmp files with us.
If possible - it would help a lot - with the raw photo in question.
Ah, sorry about this - I lost sight of your request. I’ll attend to this later, but just to be sure, I am assuming that “click on the ‘write sidecar button’ in the darktable organizer” actually refers to turning on the option for ‘write sidecar file for each image’ in the storage category of darktable preferences? That setting is permanently on anyway, as part of my backup strategy.
I should also say that the raw files that were giving me a problem under linux have been ‘fixed’ (or worked around) by the simple expedient of resetting the exposure module. Will you then be able to find anything significant in the history stack in the .xmp?
We might be lucky, as I don’t think I have processed all these raw files in Linux and, in addition, I still have the images on the SDHC card if needed.
He is just requesting a copy of your xmp by writing it…
Basically if you have one of the files edited you should be able to copy with overwrite that xmp to the file on the other OS …if you still see the issue then your display profile or a mismatch of your Darktable gamut settings must be producing that difference you are seeing…
Yeah, I think that process was one of the things I tried on first discovering the problem and was further confused to find that image appeared fine in Windows. Anyhow, I have just now found an image on this film roll which I haven’t touched in Linux, which still exhibits the problem and I’m in the process of delivering it to this forum.
Please find attached a sample .RAF and its associated .RAF.xmp
20211202_SWGC-Dec21_1830.RAF (28.2 MB)
20211202_SWGC-Dec21_1830.RAF.xmp (9.7 KB)
Is this adequate ?
I’m sure I’m talking nonsense; I don’t actually understand what a working profile is so I think I am talking display profiles; I set this by right clocking on the ‘soft proofing’ icon, between the clipping indication icon and the gamut checking icon, to the right and beneath the image area when in the darkroom. Having right clicked this icon the top line is labeled ‘display profile’. Here i have chosen linear REC2020 RGB for both installations
Well it should only be this for testing the gamut checking and only if your display profile is not unbounded…… Setting display working and histogram profiles all to rec2020 give you a pass through with out any colorspace mapping …that is what the pull release was explaining…. Setting your display to this will often give you a poor looking image.
Normally color management takes care of things but for DT because the display profile is processed before the data goes to the histogram profile if it is not well behaved it can clip the data and so the histogram profile is not accurate…
So you should be using the icc that comes with your monitor or the one intended for your monitor or better yet an icc created with a calibration device… to ensure what you see on the screen is accurate
Your data from the camera is handled first by the input profile which should be the correct one for your camera or again one from a calibration. The working profile is the space that your modules work in and so should be wide gamut….rec 2020 or prophoto…
Your output file will usually be sRGB for viewing on the internet or a pc . It will correctly map the wide gamut data to the smaller colorspace for output….
Histogram profile would normally be rec2020….this would show true data clipping while processing in the pipeline…The issue with DT is the working profile data passes through the display profile before going to the histogram profile and so this is where the problem can be with gamut……gamut warnings come from histogram profile data and if the display data is clipping then basically you will hardly ever see anything out of gamut as the wide working space gets mapped to the smaller display gamut before being remapped to the histogram profile……
To compound this as you noted there are different gamut warning and you can set the limits so when comparing you need to be sure all that is the same……
So basically normall operating conditions would be input profile ….as assigned for your camera by DT, or a calibrated one from a color checker, then working profile most often linear rec2020, output profile as needed but most often sRGB for most jpg exports. Display profile will be icc for your device or an icc prepared from calibration, and finally histogram profile will be rec2020.
From this you can swap linear rec2020 for your display profile…your image should look crappy but now this will be the true gamut reading. If this setup is much different than what you see with your display profile as it pertains to gamut then for sure you have issues with you display profile impacting data passed to the histogram profile…
Opening this …
I get this for full gamut check…
WHich all goes away when you disable color balance so you pushed it there…
Brightness left at your 1.09 EV…this is on windows…
Thanks for your continued analysis. If I have read correctly I think you are saying that my adjustments in color balance rgb cause the out of gamut colours in the sample I sent. Please this the following screen shot which is another image taken at the same time, but which I don’t think I have touched (history stack at default; no sliders in color balance moved; display profile set at 'system display profile, which I hope is the ICC for my BenQ monitor which I installed yesterday) but is showing out of gamut pixels right away. is this caused by the combination of shutter, aperture and ISO I chose the image?
I am also attaching the RAF and xmp
20211202_SWGC-Dec21_1824.RAF (30.3 MB)
20211202_SWGC-Dec21_1824.RAF.xmp (5.7 KB)
btw I purchased a Datacolor SpyderX Pro a year ago for obvious purposes but, having given it my best shot, I have been unable to make it work in Win 10, or in Linux, via the ArgyllCMS system, the documentation for which is utterly beyond my ability or patience to master. It seems that I don’t have big enough intellectual gonads to use this system - or to understand the language of responses to help requests on various forums. It seems nobody has the power to talk down to my level!
Edit: Hah! At the time I decided to take a screen shot the history stack did not - I think -contain the top 2 lines: the image opened in the colorbalance rgb module immediately after I double clicked on it in lighttable.
Well… the 'write sidecar ’ button writes a xmp file, even if that option you refer to in the settings is disabled . So you always get the latest fresh version, for sure.
Amd I was asking to do it once , under Linux. Safe the file you have there. Then do it again under windows, and safe that xmp file.
So we have two xmp files , for the same RAF . And I want to compare them , because I honestly think there is a local setting different in your darktable (preferences, system display profiles, etc… ) or there is a difference in the processing.
Maybe I’m just annoyed that I can’t think of anything that might be causing this :P.
By the way, I think people might want you to specify a sort or license for a raw file you post. Take a quick peek at a play-rae thread , and think if you agree with the idea (of putting your file out there in the public domain, or something stricter … ).
Thanks for the reminder about the licence requirements - I forgot because I couldn’t understand how to specify such a document (I last looked at software copyright issues in 1984, if I remember correctly).
Are you clear that I am running the linux and windows version of dt on two entirely separate computers, with quite different monitors? What I have sent is from the linux version. I have attached the windows .xmp for that same raw file, but I can’t be at all sure that it has been through the same modules, in the same order, with the same options/settings as the linux version you have. I assume this file, being open text, does not need a licence.
20211202_SWGC-Dec21_1830.RAF.xmp (6.5 KB)
You have black level compensation on in your exposure…you must have added that …if you go to duplicate manager…make a duplicate and choose original…there is no issue…so I started to look at your modules…and you have that tweaked in exposure…For comparing between systems just look at originals with default workflow…perhaps scene referred…don’t do anything …now compare them…you can get those on each system by doing as I said…make a duplicate and make it original…black level in exposure I think is only ever user adjusted so that must be something you added…it might not be on the other machine and that alone could be what you are seeing…
Your windows xmp has quite different exposure settings …black level is responsible in this case for your gamut… this edit also has lens corrections and your linux xmp has different settings for exposure (less and no black level adjustment) and you have cranked up most of the settings in CB…removing CB removes the gamut warnings…basically you are comparing apples and oranges not apples and apples between machines adding to any hardware differences you might have…
Windows…
Linux (if I have the xmp with the right machine)
EDIT: as suspected your black level adjustment has been added to 1824 as well so that is why it is triggering gamut warnings…
It‘s not about ‚intellectual gonads‘ it’s about wanting to run before learning to walk 
Be patient, there’s no shortcut to become a master of darktable
Your insights into my misuse of dt, and your continued advice, are greatly appreciated. Thank you. There is much for me to read here and in your previous comments, which will take me some days.
In an attempt to reduce the appearance of being more than averagely inept, I will say that from the sample you have shown, I sent, in error, .xmps which did have evidence of my stumbling about. But I thought that I had always sent the ‘version 0’ xmp for those images which I had duplicated, and which should have been untouched. Obviously, having duplicated an image, I then went on to edit the original…
Given this error, I think I will re-import some of these images from the camera SD card and examine them before and after resetting the various profiles which you advised me about earlier.
I honestly do not remember ever having adjusted the black point, in any of the thousands of images I now have within my dt db, because I am aware of the exhortation not to do so. My only explanation is that, because of defective eyesight (per Herr Göring), I am prone to poor cursor positioning, sometime moving the wrong slider and forgetting to reset it. This is one reason why I try to do most of my edits on an old monitor - it has a pixel pitch which is about twice that of my newest monitor, the designers of which have obviously been driven by the marketing people and the modern craze for 4K screens in a 24" panel. Poor design…
I can’t count the number of weird combinations and permutations I have inflicted upon myself 
Don’t be so hard on yourself…keep plugging away.
I’m not a dt expert by any measure, but it occurs to me you might want to demonstrate to yourself the consistency of the Windows and Linux versions by exchanging XMPs to see that the process consistently in both environments.
If that really doesn’t work, then color management is the likely culprit. Yeah, I just recently re-profiled my two monitors with Argyll’s dispcal, and the process is not straightforward. Now, this might make some cringe, but as an alternate you can use a regular sRGB profile as a display profile IF your display gamut and gamma is close to sRGB. Some displays actually have a ‘sRGB’ mode, which would help make this approach more precise. If your display is one of those fancy-schmancy large-gamut displays, an AdobeRGB profile would be more appropriate in this hack approach.
I’m actually using just that approach on my tablet right now, using this sRGB profile as my display profile:
https://github.com/ellelstone/elles_icc_profiles/blob/master/profiles/sRGB-elle-V4-srgbtrc.icc
Yeah, I’ll get around to making a proper profile… 
That’s valuable advice to me, thanks; I’ll work through that in the next day or two, but trying to get dispcal to even install, let alone understand how to use it will have to wait, pending a miracle re-activation of long since dormant cells in the brain.