You’re mixing up RGB space with sRGB gamut. Let me explain: a gamut is what a device (a screen, a printer) can display, and it varies a lot. And most screens that are just a couple years old cannot display all RGB colors — and compensate it with reduced saturation, lightness, or by shifting tint. You can open an image of an HSL circle/square and you will notice bands and strange luminous lines appearing on different screens at different places, if your eye is keen enough. (HSL is based on RGB color space, so the representation is valid.)
sRGB is a standardized gamut that is used as a baseline for most digital design. By using sRGB only, you make sure the colors will look the same on each device (relatively to each other, as average tint and lightness of each display will still vary). To make an image fit into an sRGB gamut, you will need to desaturate some colors and/or tweak their luminosity — and highlighted “problematic” colors are those that need such a tweak. My app decreases saturation to preserve luminosity and hue; other apps will change other properties to preserve another ones. Just one method of many.
Why Aseprite and PNG display colors not like the ones in the app? Because they can’t. And if the colors are not reduced to sRGB on export, they will look wrong in many other cases in a, let’s say, in an opposite direction.
Now, RGB space itself also cannot display all the possible colors that humans can see, is linear when human vision is not, and is just awful when interpolating colors — which is a staple in palette making and color gradients. Thus new color models were invented. The real goat nowadays is okaylch, which is the improvement of lch (luma-chroma-hue). My app uses lch, which is still perception-correct but a bit harder to use. Not the real problem for end users.
Most apps and formats still support RGB space only, though, which includes PNG image format (and many others!) and Aseprite. The real colors my app operates in are in lch format, not hex format with the leading #. lch works on the web, and in some image-editing apps. “Linear RGB” codes in the right column of the app were also invented to be used in 3D engines and rendering software, but it is still linear, though it can display brighter colors than RGB white, as well as brighter reds, pinks, blues, etc., which are a must have in emission/reflection display. These are supported in Unreal Engine for sure and probably in other 3D-related thingies, too. p3 is an Apple-invented older take on the problem and support for it can be found in Apple-made products and some other 3rd-party apps.
I really would like all this to be simpler, but color, behind the scenes, is not simple at all. There will also always be a gap between printing software and designs for digital displays, buuuuuut it’s another whole separate topic.
