Since Noel is back with us, I thought this header might catch his attention. He was the one who first reported it six or seven years ago.
The reason I'm bringing this up now, is that someone in the Lightroom forum had this problem just yesterday (he was sending ProPhoto files to Photoshop and couldn't understand the cyan cast in his dark grays). There's no doubt it's the same issue.
This made me dig up my old ProPhoto test gradient file. I don't use ProPhoto all that much, so I haven't really looked for it in a while. To recap, this is an example of what it could look like (this is an old screenshot that I've kept). Open and view against a darkish background:
But when I opened the test gradient now, there was no trace of it, zero. The gradient is smooth as silk. That surprised me, because while the effect can vary, it always seemed to be there in some form.
Technically, this is an inaccuracy in the conversion from ProPhoto into the monitor profile. This conversion is performed by OpenGL in the GPU when you have the PS preference set to Normal and Advanced modes. In Basic mode it's shifted back to the CPU, which is more accurate so the problem disappears. And you only see it in ProPhoto files because ProPhoto is very compressed in the shadow values compared to other color spaces. The stratospheric gamut has a price, and that's it. With this compression, inaccuracies get amplified.
So what has changed on my system over the last 12 to 24 months? Not much. I still use Eizo Colornavigator as I did then, still producing similar matrix monitor profiles. But one thing has changed - going from GeForce to Quadro, and with that, 10 bits per ch output.
So Noel, if you're reading this - I understand you have Quadro GPU too, and running displays at 10 bit. Do you still see it?
Anyone else?
Since Noel is back with us, I thought this header might catch his attention. He was the one who first reported it six or seven years ago.
The reason I'm bringing this up now, is that someone in the Lightroom forum had this problem just yesterday (he was sending ProPhoto files to Photoshop and couldn't understand the cyan cast in his dark grays). There's no doubt it's the same issue.
This made me dig up my old ProPhoto test gradient file. I don't use ProPhoto all that much, so I haven't really looked for it in a while. To recap, this is an example of what it could look like (this is an old screenshot that I've kept). Open and view against a darkish background:
But when I opened the test gradient now, there was no trace of it, zero. The gradient is smooth as silk. That surprised me, because while the effect can vary, it always seemed to be there in some form.
Technically, this is an inaccuracy in the conversion from ProPhoto into the monitor profile. This conversion is performed by OpenGL in the GPU when you have the PS preference set to Normal and Advanced modes. In Basic mode it's shifted back to the CPU, which is more accurate so the problem disappears. And you only see it in ProPhoto files because ProPhoto is very compressed in the shadow values compared to other color spaces. The stratospheric gamut has a price, and that's it. With this compression, inaccuracies get amplified.
So what has changed on my system over the last 12 to 24 months? Not much. I still use Eizo Colornavigator as I did then, still producing similar matrix monitor profiles. But one thing has changed - going from GeForce to Quadro, and with that, 10 bits per ch output.
So Noel, if you're reading this - I understand you have Quadro GPU too, and running displays at 10 bit. Do you still see it?
Anyone else?
So if I understand you correctly, you are asking why you don't have a problem? 
So this is the same issue as when I export from Lr to Ps via Edit In?
I'll try one in Basic mode and update the previous post.
Update, I can't seem to edit the previous post so here's with Photoshop in Basic drawing Mode
And here are the 16bit files. I always work in 16bit but since yours wasn't I wanted to test with the same settings.
You shouldn't get this in Basic mode. You obviously know that changing drawing mode requires relaunching Photoshop, so I will not remind you about that 
Is the banding cyan colored (that's the smoking gun), or just regular banding? See my original screenshot at the top.
OK. I suppose everyone has more than enough to chew on these days, between color blend bug, constrained scaling and file associations, so I won't stress this too much now. I was just curious. Also, I need to mind my job inbetween...
See whether Use Graphics Processor is enabled or disabled in your Performance Prefs, and what Drawing Mode you're set to use. As I recall setting the latter to Basic moved the color-management tasks into the CPU and that worked around the problem.
I just reproduced the problem here on 20.0.0, 30 bit color, with the nVidia 391.89 driver. For a gray graident in a ProPhoto RGB document going from levels 12 to about 90 I see concentric rings of cyan and gray. They look nice and smooth with the 30 bit color, but the color inaccuracy is definitely there. Here's a saturation-enhanced screen grab (which necessarily reduces the image to 8 bit color)...
I know you've recently updated your nVidia display driver, Dag, to 4xx.something. I've been meaning to do that myself. I will do so shortly and report back.
-Noel
It looks compressed but isn't this because the image is dark and has more a lot more information in the ProPhoto space?
As you already guessed though I'm not an expert in this, by far, I wish though so I could solve this problem. I certainly know my way around Lr and Photoshop where image editing is concerned but this stuff makes my head spin.
Adobe RGB vs ProPhoto RGB
Now I'm deciding between ProPhoto RGB with Basic or Adobe RGB with Advanced. This is with RAW files, final export to sRGB or aRGB, depends on the library I submit to. Do you think I won't miss much by using Adobe RGB? If I was shooting JPG then sure it would make no sense to work in ProPhoto although.... I've read you can get smoother gradients (or other edits) when converting to 16bit and then save back to 8bit.
Oh and WELCOME BACK NOEL!!!
I cannot believe we're the only ones noticing this issue, this is in B&W....or is it color?
I've been using Basic drawing mode for ages now because of this and even bought a new GPU a week ago to solve this.
Alright I'll do some more testing to see if I can make the switch to AdobeRGB working space (advanced)
https://forums.adobe.com/people/D+Fosse wrote
You shouldn't get this in Basic mode. You obviously know that changing drawing mode requires relaunching Photoshop, so I will not remind you about that
Embarrassed time. I was thinking it was the same as GPU on off and just needed a new document start. I'll retest later tonight 
Dave
Hi Dag,
Oops, got nVidia 411.81 here. Apparently released today. I'm still on Windows 8.1 by the way. The problem remains.
Whatever you've got going on, treasure it. In all seriousness, it's good that you've picked this issue back up. Maybe the difference will lead to a discovery.
-Noel
By the way, do you have the Use native operating system GPU acceleration setting available and checked in the Advanced Graphics Processor Settings panel. It's grayed out for me; I imagine it's only available for the very latest OS versions.
-Noel
Indeed, Web (converted to sRGB I suppose) and Ps version side by side
Btw are we in a private room listening to our own echos or are Adobe engineers actually looking into these threads?
We really need to get our hands on one of those engineers asap, I'll bring the chair, you bring the rope, D Fosse can ask the questions!
My inner geek voice has always whispered a suspicion that there must be a stage in the transform calculation in which, even though GPUs use floating point math, a number near an integer may be subtracted from a nearby integer (e.g., 1 - 0.9999999), which is a sure way to cause precision loss. Another thought is that maybe there are tone curves that differ by a very small amount for each of the colors. An amount some profile designer thought was inconsequential 20 years ago.
It is possible the monitor profile is involved, though I have verified seeing the issue using anything from the age-old sRGB v2 profile to newer v4 display profiles as a display profile.
It's clearly got to do with using the ProPhoto profile as a working space, because another, similar profile (e.g., ColorMatch RGB) doesn't cause it - which led me to wonder further... Could there now be more than one ProPhoto RGB profile around? Could you have somehow gotten an updated one, Dag, that no longer causes the precision loss?
I looked on my hard drive and I saw that I actually have accumulated multiple copies of the ProPhoto profile (not surprising), BUT... I do have two different renditions. Most are ProPhoto.icm (including the one in C:\Windows\System32\spool\drivers\color, which is the one that matters), dated anywhere from 2005 to 2015. the one that's different is ProPhoto.icc (note the different file extension) dated 2012, and located in a folder created by a different photo editor (ComputerInsel Photoline). Turns out it's described as "ProPhoto RGB (linear)" and it isn't another rendition of the same profile, exactly, but its existence DOES support the possibility of there being alternate versions of ProPhoto.icm running around in the world.
Dag, is your copy of C:\Windows\System32\spool\drivers\color\ProPhoto.icm the same size as mine?
If so, next we can devise a way to see if they contain the exact same binary data.
-Noel
Yes, down to the last byte (940/4096).
But even if the gradient looks fine, there's something funny going on all right. I drew a marquee and cranked saturation all the way up. Why is it consistently red when it should just be neutral with increased color noise? What's that cyan peak in the histogram?
Yeah, it could be the PP profile spec in itself. Now, I'm a practical man. I know how things work, but whenever someone tries to drag me into the Hogwarts Color Science Lab, I'm off chasing butterflies. I know nothing about the internal anatomy of a profile - except the broad principles of Profile Connection Spaces. I know there's a table somewhere (way up in the Scottish Highlands), which can be based on either XYZ or Lab. Could this be where the dragon is buried?
I have both an .icm an .icc ProPhoto RGB profile on my Windows 7 system, but in PS Color Settings I only see one ProPhoto RGB selection. They appear to be identical so it shouldn't matter. The date showing in ICC Profile Inspector is 1998/12/1.
Hm, that might imply your gradient isn't pure gray, Dag, BUT... There is definitely some additional weirdness going on!
I tried raising the saturation of my grayscale PNG to +100 and got this:
Then I did it AGAIN and got this cute little result.
After undoing all the above, I did Image > Adjust > Desaturate it, then two iterations of +100 saturations and got this:
This implies the PNG actually has some values that are non-gray (by a tiny bit). And here I thought PNG compression was lossless - but I guess not! The funny thing is that this little revelation seems to be entirely separate from the ProPhoto cyan cast display bug.
The plot thickens! I'm going to save my test image as a PSD and use that from now on. I hope THAT's lossless.
-Noel
These are my Performance settings
Multiple applications of the +100 Saturation makes no difference—the RGB values remain equal, which is expected.
If you add Color Sample marks to your Saturation selection do the RGB values change? Saturation shouldn't have any affect on equal RGB values. Are you testing in 2019?
I tested above in 2019, but I've seen the ProPhoto cyan cast issue before in 2018 and earlier versions, going all the way back. Apparently it's appearance is dependent on something we've yet to nail down.
The second issue, which I just uncovered above, may be my fault. I re-opened the PNG file I posted above and I haven't been able to reproduce bringing out any weird colors with any number of Saturation steps. I may have opened a different test file from my History to get the effect with the neat patterns.
Here are reproductions of the ProPhoto cyan cast problem, with settings like yours...
Photoshop CC 2018 "girl in drug cloud splash screen edition":
Photoshop CC 2019 "cloud headed dude splash screen edition":
As you can see, even with the same settings you're using (e.g., no 30 bit in my case) the color banding remains.
The samples all show equal R, G, and B values, whether or not point samples or averaged samples are made. It must be purely a monitor display issue.
The cyan banding issue doesn't show up in the Navigator display, by the way. I believe Photoshop must always use CPU color-management for that.
-Noel
No. Could be on Mac; not on Windows. Unlike MacOS, Windows doesn't touch this stuff. It's strictly application.
(EDIT: what made me pick this up again now, was a Mac user on the Lightroom forum three days ago having this exact issue. He's on Mojave and PS 20.0)
Anyway, Noel, you were right of course. Once I punched in the numbers and double-checked with 16 bit readout that R=G=B, I got this, and that's 100+ saturation on the actual finished screenshot. A few stray pixels, that's all:
On the upside, this is as close to perfection as it'll ever get. So yes, it can work.
It has to be somewhere in the conversion from ProPhoto source to monitor RGB.
but going to ProPhoto is jumping off the edge of the world. It's huge.
When it comes to CMYK print output I can see some advantage of the larger ProPhoto gamut, but I'm having a hard time finding the downside.
Here's the shadow gradient we've been looking at, which is obviously in gamut with both ProPhoto and AdobeRGB, and is also inside any CMYK gamut. The three color swatches are inside the ProPhoto and GRACol Coated CMYK gamut, but are out of the AdobeRGB gamut. The bottom capture is a Relative Colorimetric conversion of the Prophoto file to AdobeRGB.
If I convert both to GRACol I get identical output numbers in the shadow gradient, but the numbers for the saturated colors are different—the AdobeRGB colors have been somewhat clipped.
https://forums.adobe.com/people/rob+day wrote
If I switch to Adobe RGB the results are considerably different and less accurate (reds more saturated). Not sure why since there is very little image area out of Adobe RGB gamut.
That would be expected if you capture the same RGB values but then assigned (rather than convert to) different profiles. Try capturing with ProPhoto and then do a Convert To AdobeRGB.
Nope. I'm using 'Covert to Profile' for the ProPhoto RGB conversion to Adobe RGB.
It probably is due to the Auto Curves function rendering the image differently due to RGB channel differences (see below). Processing color film images in LR/PS can be a PITA due to the mask and color characteristic differences of the various color film types. However, using ProPhoto RGB with the Auto Curves function works quite well to color correct the film images.
https://forums.adobe.com/people/rob+day wrote
On a conversion I would expect the histogram and image RGB values to change as you are showing, but not the color appearance. What happens to the histograms if you convert the two versions to the same CMYK output profile?
'Convert to Profile' U.S. Web Coated (SWOP) v2 for both produces identical Histograms with Cyan and Black channels clipped.
At this point I'm convinced there's something special about the ProPhoto profile itself.
A (small) new piece of info. I had thought that my own software was rendering the grayscale completely as gray, but lo and behold (and this is something I see in @rob day's post above as well) with extreme saturation there are tiny color errors in single pixels right at the transitions between adjacent levels (in the 8 bit screen grab world). That probably made no sense. This hyper saturation-enhanced comparison may help (Photoshop display on top, what I *thought* was a correct rendition on the bottom, but look closely):
Those tiny lines show up in @rob day's screen grabs above if you push the saturation way up.
Dag, please do a screen grab of the gray gradient as displayed on your system, hyper-saturate it, and post it here.
I wonder if these color inconsistencies are just a matter of magnitude, always there (because of something about the ProPhoto profile) but being (mostly) covered up by roundoff error in some cases and not in others.
-Noel
I had thought that my own software was rendering the grayscale completely as gray, but lo and behold (and this is something I see in @rob day's post above as well)
My (OSX) capture is monitor RGB with my monitor profile assigned. Before I uploaded it I converted it to sRGB, so the values are no longer perfectly equal after the multiple conversions.
https://forums.adobe.com/people/Noel+Carboni wrote
Dag, please do a screen grab of the gray gradient as displayed on your system, hyper-saturate it, and post it here.
OK, this is a screenshot of the original ProPhoto file as displayed.
Then I put 6 hue/sat layers on top, cranked them all up to 11 on the dial, and flattened.
To minimize random errors in post-conversions, this is a 10-bit screenshot pasted into a 16-bit file, monitor profile assigned > converted to sRGB, then converted down to 8 bit and saved as PNG. Phew.
My own sneaking suspicion, echoing Noel's, is that ProPhoto is simply too large for its own good. Insert a dust grain of a tiny imperfection, and bam - it blows up.
https://forums.adobe.com/people/D+Fosse wrote
https://forums.adobe.com/people/Noel+Carboni wrote
Dag, please do a screen grab of the gray gradient as displayed on your system, hyper-saturate it, and post it here.
OK, this is a screenshot of the original ProPhoto file as displayed.
Then I put 6 hue/sat layers on top, cranked them all up to 11 on the dial, and flattened.
To minimize random errors in post-conversions, this is a 10-bit screenshot pasted into a 16-bit file, monitor profile assigned > converted to sRGB, then converted down to 8 bit and saved as PNG. Phew.
I followed the above procedure and see no artifacts other than normal banding due to 8 bit display path.
WIndows 7, PS 19.1.6, Quadro 600 GPU, No 30 bit mode
https://forums.adobe.com/people/rob+day wrote
I get similar capture artifacts no matter what the profile assignment is, but they never show in the file that's being captured, either in appearance or the numbers. I'm not doubting that it's a problem, I just can't reproduce it.
Curiouser and curioser... Yes - I also see that with any profiles that don't match my reference sRGB monitor profile only when CPU-based color-management is being done, not when GPU-based color-management is being done. This is a surprise to me; I've always assumed the grayscale was pure, because without so much extra saturation the errors are not perceptible.
Each of these are gray gradient fill layers expressed in the listed profiles, displayed on my monitor, screen grabbed, and saturation of the screen grab increased to +100 twice.
This forum botches up image attachments, but note the major color inaccuracy in 1 of the 4 images in the first set, and tiny pixel-width lines in 3 of the 4 images in the second set.
As displayed in Photoshop CC 2019 with GPU color management:
As displayed in Photoshop CC 2019 with CPU color management:
-Noel
Further experimentation reveals the results are changed by the choice of color engine one makes in the Edit > Color Settings... If for example I choose the Microsoft ICM color engine instead of Adobe (ACE), I see a noticeable shift in the color inaccuracy and brightness of the dark parts (they're brighter with the Microsoft ICM). I don't see a difference by tweaking the 3 checkboxes, but I haven't done an exhaustive test.
Here's what I've got for color settings:
Note that closing and restarting Photoshop is required to see the change take effect.
-Noel
This is the one I have; looks to match yours, Todd, though of course we're not seeing all the detail in the tables.
-Noel