Acknowledged

Red Shift Mode is not playing well with red colors

I see following on my watch (Fenix 8) when I switch on red shift on:

  • the location icon in the circle style menu (long press the top left button) where you can turn on the red shift mode is displayed in full red no matter if red shift is on or off
  • when a watchface is using a red color though, the red gets somehow "faded" like in following picture

Also, it would be very nice to know if the red shift is on or not - example use cases are described here: https://forums.garmin.com/developer/connect-iq/f/discussion/354812/any-way-to-know-watch-is-supporting-red-shift-mode - it may be necessary to use different colors in red shift mode or to use a single color only e.g. to get a good result...

In my case the red color does become hardly readable in red shift mode - I think red should stay full red or all colors should become the same red - the garmin cirlce menu does handle it like that...

  • I know there are different algorithms and the implementation is probably doing everything right considering the name "red shift", BUT I mean that there is following problem:

    The red shift mode is not implemented in a way that a custom watchface does not have to react to it in any circumstance - I think you have written once it is (like "the developer does not need to do anything differently if the red shift mode is active"). Currently if the developer wants to provide a usable, readable and beautiful result in red shift mode he can't... personally, I would be very happy if I could simple check if red shift mode is active or not.

    Regarding algorithms, e.g. on android there is a wide spread thing inside google's UI elements called tinting - heavily used for icons e.g.. There the implementation is "switching" the base color with the tint color and alpha/luminance is kept as is. Solid blue would become solid red, solid red would stay red, semi transparent blue would become semi transparent red, semi transparent red would stay semi transparent red and so on...

    My wish is following actually:

    Nevertheless I would be happy with the most simple solution - I don't see anything speaking against exposing a flag to access the current state of the red shift mode (and the current shift color) and this would solve all issues because then everyone can adjust their code to achieve whatever someone wants to achieve.

    Alternatively using a tinting algorithm may be a good alternative solution as well but I don't know if garmin is open to changing something at that level and I even don't know what that would mean for garmins code so I assume that's something that won't happen - but this would go more in the direction "the system does everything and the developer does not need to know anything about it".

  • I have not looked at the code, but it is possible that the controls page is checking the color shift mode and doing shenanigans (using greyscale icons when in color shift mode) to ensure that the user is able to navigate critical functions of the device.

    My assumption is that the color shift is based on source pixel luminosity. Using standard luminosity calculation, this means that a full red pixel in color shift is going to be 22.16% the intensity of a full white pixel in color shift, regardless of if you are using red, green or orange color shift. A full blue pixel will be 7.22% the intensity of a full white pixel.

  • Really? So you think red shift works like following:

    Garmin circle menu: red/green/blue/violet/ becomes solid red

    Watchface: red/green/blue/violet/ becomes solid red and red becomes some faded / lighter red

    Result:

    If you use a solid red inside your watchface and the user enables red shift, red content becomes hardly readable. But inside garmins native circle menu, red stays red and is readable?

    For me this is a bug that can be solved if garmin handles red differently or if they provide access to an "is in red shift mode" flag that allows developers to use e.g. white instead of red if the red shift mode is active... => this is way I combine a bug and a feature request inside one report, the feature allows me to solve the bug on my side. But the bug means that currently, its not possible to do nothing if read shift is one...

    Screenshots:

    If you check the garmin menu, the red icon on top stays red, if you check my watchface, the red 08 becomes faded... And people keep writing me, that my watchface has a bug because every color but red works in red shift mode so many people to think this is a problem as well... And so do I. If garmins menu is the reference on how it should look like in red shift then the solid red FF0000 on my watchface should stay a solid red FF0000, but it doesn't.

  • I don't really understand this report. How is this a bug? This is how red shift works. You could open bug reports (probably rather feature requests) about specific things (i.e: app/watch face) to provide a color scheme that is better fit for redshift mode. However note that there's also other color shift modes, not only red...

    So if you mean to ask Garmin to add an api to query if the watch is currently in red(or other color) shift mode, then maybe rephrase it as a feature request.