Colours appears to not be the official HEX values

[ianyepan]

Something is wrong here, the Dracula theme on my Visual Studio Code looks just a tiny bit too saturated. And when I checked the HEX values -- sure indeed, the hex codes are not the same as the official colours defined in the Dracula home page. But when I look into your source code (yml file), I noticed that you are indeed using the correct HEX values...

I'm a bit lost here, could it be that vscode applies a sort of colour-filter-layer above my theme?

[dsifford]

Are you referring to the colors in the integrated terminal? Because those are set to match the values we have defined in the running spec that were agreed upon after some discussion around terminal readability.

[dsifford]

Also, make sure you don't have "dracula-soft" enabled, which is a variant that we made in vscode because macos renders the colors far too saturated, which many folks stated was too hard on the eyes.

[ianyepan]

Thanks for the prompt reply. I don't have dracula-soft enabled, and I didn't mean the terminal colors either -- I meant the actual code editor with standard dracula theme.
It could be a macOS or VSCode issue, since others have mentioned that VSCode seems to be using a color-saturating trick to make users think the editor is more "vibrant/exciting" after an update.

I'll attach a side-by-side screenshot, with VSCode Dracula on the left, and another editor (Emacs) with the Dracula theme on the right.
Taking green for example, I have checked the HEX values in Emacs to be #50fa7b, which is the official value. However, note that in the bottom corner of the VSCode, the Color Picker app shows a value of 00ff69 for a green that's supposed to be #50fa7b.

[dsifford]

Very strange indeed.

So I assume this is likely out of scope then? Is this issue safe to close here?

[ianyepan]

Very strange indeed.

True. I'll close this issue as I don't see it as a problem with your repo. Hopefully, someone in the future could find this thread and provide us with a reasonable explanation.
Thank you for the reply and the work!

[ianyepan]

@dsifford Apparently this is a known bug in Electron: electron/electron#10732