I've tested it briefly with Night Shift and F.lux and could see flicker, especially on lower brightness settings, but I'll try to catch it again on the video. Basically what F.Lux / Nightshift does is adding a little amount of red color to the tone (or removing amount of blue, which gives similar output), and it results in making red pixels brighter. In case red component is already there, it might be fine (as I couldn't see flicker on higher brightness of pixels), but if only blue / green subpixels are used, it can add more flicker as it will probably activate red subpixel in low brightness (which seems to equal additional flicker). I'll check different color profiles, I'd guess, if "Color LCD" is tuned for this particular display, they should add more flicker due to missing sweet spots.

The problem with observing whole pixels instead of just subpixels is that it's harder to see the flickering - three subpixels at once are brighter than individual ones which somehow misleads camera. You can check it on the second part of my video where I browse a webpage - there is some flicker, but it's not as noticeable as this on isolated "red" examples. It would be great if someone had better equipment, maybe then we could see the flicker on higher brightness and also observe whole pixels without issues.

Thanks for your comments guys, many useful ideas, just need to find time to test everything properly 🙂

Thank you! I have a few questions to understand this better -

-it only shows in certain areas when you decrease brightness, so you wouldnt see it everywhere on the screen?
-isnt the light that lights the pixels still the backlight? But the pixels can dim I understand, so even if the backlight is flicker free, the pixels make it appear as flicker?
-is it software controlled?
-if it is, we need to send this to a few people, if you dont wanna do it I can do it - mostly Daniel Georgiev, who programmed iris and could be capable to use this information to program a cancellation of this effect into his software too.

    martin

    martin it only shows in certain areas when you decrease brightness, so you wouldnt see it everywhere on the screen?

    Based on what I saw - it depends on how bright given subpixels are. Each color in HTML and on screen (as a pixel) is built of Red, Green and Blue components whose shades range in value from 0 (pure black) to 255 (full brightness, clearest shade of R, G or B ). From what I've seen - flickering is usually noticed by my phone's camera if subpixel shade goes below 100 (around 40% of 255 max value). So it seems that if you go below 40% of native brightness every pixel/subpixel may start flickering. Also if pixel is generally bright, but contains deeper shades of specific colors (like a touch of red provided by F.lux or night watch) these deeper shades will probably flicker.

    martin -isnt the light that lights the pixels still the backlight? But the pixels can dim I understand, so even if the backlight is flicker free, the pixels make it appear as flicker?

    I'm not sure what the nature of this flicker is - it may as well be pixel inversion mentioned by @KM . I'll have to read how LED / LCD screens are built, but I believe that there might be set of overall LED lights behind whole screen, but pixels may also have their own brightness, or control how much light they let through by FRC, dithering or other ways.

    martin -is it software controlled?

    I'd like to test it - guys in other comments suggested checking different OSes or tools like Ditherig. I also know @JTL has been working on some dithering disabling options. I hope it's software-controlled as it would mean that the technology itself isn't broken, just needs a good driver, we could then count on creation of an optional driver that stops flickering sacrificing color quality on screens.

    martin -if it is, we need to send this to a few people, if you dont wanna do it I can do it - mostly Daniel Georgiev, who programmed iris and could be capable to use this information to program a cancellation of this effect into his software too.

    I'd be glad to send this and other findings to our known contacts that may at least tell us if it's dithering, FRC or other stuff, so we know what causes our issues. I'm not sure if it's 100% accurate, it may be another wrong path, but at least correlation between screens that are usable for me and visibility of flicker in tests is promising.

              martin could be capable to use this information to program a cancellation of this effect into his software too.

              Maybe, maybe not. It's either controlled by the GPU dirver or firmware, which iris works "above" so any workarounds would reduce visual quality further compared to a lower-level fix. What I think might be of interest is testing my hypothetical dithering fix after I get it working with a microscope or capture card, etc.

                Just a small update - I've just tried decreasing the camera brightness in phone's settings and it seems to be able to see whole pixels behavior, even on high brightness of target screen, so that's a good sign as it should allow for tests on the whole spectrum.

                I've quickly checked Mac screen with Windows 10 again and while on slowmo it shows flicker, when observing it with bare eye there seems to be another layer of dithering where pixels change their colors slower. It's like fading in and out between two shades every 0.5-1s. It might be the same thing, but perhaps there is both some PWM-like behavior on subpixel level which gives flicker in slowmo and another - dithering-like that can be observed without 120fps. I'll have to check if Ditherig can stop this slow dithering and if it's visible the same way when I record it in standard, (non-slowmo) mode.

                  andc We should also send this to notebookcheck.net, they did PWM tests and seem to care about this issue.

                      martin
                      I've been thinking about it too, it would be great if they performed similar tests during their reviews. It could allow us, "the affected ones" to check which devices may be fine, which we can't do apart from PWM.

                      Let me finish the second round of tests (will happen around weekend) which may reveal more issues and as a result provide more details to share with 3rd parties. I'd like to confirm what exactly this observed issue is first. There's still a small chance that it's caught by camera, but is irrelevant to our problems.

                          4 days later

                          Short news after further tests on W10. I've tried these options (Macbook Pro with Win10 over Bootcamp) on rgb(0,50,0), i.e. deep green in full brightness:
                          - Standard view (no modifications)
                          - Ditherig on
                          - Intel graphics powersaving settings disabled
                          - Intel Iris graphics driver disabled in Device Manager (it should equal going to standard VGA driver)

                          All of these variants produce the same flicker that can be seen on two videos above. It might be dithering on screen level as neither Ditherig or standard VGA can disable flicker on this thing. Does anybody know if Ditherig should work on Macbook's Iris cards?

                          • JTL replied to this.

                            andc All of these variants produce the same flicker that can be seen on two videos above. It might be dithering on screen level as neither Ditherig or standard VGA can disable flicker on this thing. Does anybody know if Ditherig should work on Macbook's Iris cards?

                            How about trying a REALLY OLD build of Win10? I think the oldest Windows you can install is 8.1 or Windows 10 build 1507.

                                JTL So now we're sure that Eyestrain is from Flickering, Flickering is from PWM Rate, or Color Dithering, PWM Rate is from Screen, Color Dithering is from Driver/GPU/Screen. These are all major possible causes, right?

                                What is eyestrain:
                                Flickering = Eye Muscle Tired cause Eyestrain
                                Two flickering source: 1. screen flickering = PWM, 2. pixel flickering = Color Dithering

                                EYESTRAIN <- Flickering <- PWM (higher is better)
                        <- Color Dithering (disable it)

                                    eDenon-2 Plus still unknown type of alleged pixel flicker in specific software/apps/games on otherwise known-good setups. Plus maybe DC ripple. And maybe blue light or other parts of the spectrum (this probably belongs to "brightness").

                                      andc Thank you for this work. Yes please as suggested try older win 10, like 1511 was reported to be good for pretty much everyone.
                                      About the 3rd parties sharing, basically you dont need to have complete proof, the point is sending an incentive for them to research this also, they might have better tools.
                                      Also I cannot believe Intel not only closed the thread about eyestrain as "solved", but they dont even want to share the results. I wrote to the guy asking for the lab results to be published.

                                        eDenon-2 (maybe) LED Blue Light

                                        I would change maybe to "yes"

                                          Ok, I’ll have to try 1511 if it could end up in different results. It will mean I’ll probably have to wipe my instance since there seems to be no easy way of installing 3rd OS on Bootcamp.
                                          By the way - here’s interesting video I came across through YT recommendation:

                                          https://youtu.be/3BJU2drrtCM

                                          These guys seem to have great cameras that can both make a proper zooming in, and film with 100kfps - this should see the actual processing in action, maybe even PWM on Macbooks 😉

                                          • JTL replied to this.
                                          • KM likes this.

                                            andc maybe even PWM on Macbooks

                                            A good oscilloscope can do that.

                                            • andc replied to this.

                                                JTL A good oscilloscope can do that.

                                                I know it can, but camera would show what really happens, especially how dithering is made on individual pixels level, whether it happens on all the brightness levels, etc.

                                                cont-temp One thing that I am curious about is that if different color profiles on the macbook change the flickering at all. For example that deep-red with not the default screen color profile (color LCD) but for example with Adobe RGB (1998). And maybe with truetone/nightshift on and off if you have one of the newer versions of OS.

                                                I checked various color profiles on MacOS yesterday (around 8 of them including Color LCD, Adobe RGB, Universal RGB, sRGB, Display P3). Each of them flickers on static deep-green color (rgb(0,50,0)) - some are better, some are worse, but differences probably come from the actual representation of this color on different profiles - it ranges from standard green (for brighter profiles) to almost black (for darker ones). Turning off font-aliasing didn't stop the flicker. Running Night Shift didn't change it too, although results were a little bit different than I expected - there was no added red subpixel component visible this time, maybe it's too subtle for camera, but I'll have to recheck it.

                                                I also made a test with shades of gray getting down from 255 (white) to 0 (black) which shows obvious flickering at lower levels.

                                                Another test I tried is checking how lagom's pixel inversion examples (http://www.lagom.nl/lcd-test/inversion.php) look under the microscope. There weren't any anomalies, they were shown as standard static pixels in different configuration.

                                                I'll upload shades of gray and lagom's videos later, just for reference, although they don't seem to reveal too much.

                                                Next step is checking browsers - Firefox Quantum vs. Safari vs. Chrome on MacOS - maybe some differences in font rendering will be easy to be spotted if one of them is using non-standard shading on the edges.

                                                Edit:
                                                Here are 2 videos with grayscale and Lagom.nl tests:

                                                https://vimeo.com/294115665 https://vimeo.com/294115542

                                                    I've checked various webpages in Firefox Quantum (62.0.3), Chrome (69.0.3497.100) and Edge on Win 10/Macbook setup and haven't seen major differences between them so far. I'll try to write another script that will scroll the same way through some example text in different fonts so we can compare them 1-1 between these browsers, current browsing video is too chaotic to be reliable comparison input.

                                                    What's interesting is the fact that every font seems to use some antialiasing stuff, i.e. it isn't just black, but also has some shades on the edges, the bigger the font the wider this shade is. As can be spotted on previous videos - shades equal dithering. And this dithering happens exactly where our eyes try to get focus (at the edges of characters). It may mean that our eye strain may be a result of focusing exactly on things that are constantly changing. I didn't think this shading will be happenning in such extent on retina screen which is quite sharp, but it does.

                                                    • JTL replied to this.

                                                      @andc when you started your research with your MBP 13'' 2015 which OSX version were you using?

                                                      I noticed that I get migraine like symptoms when using OSX 10.13.5 and up (including Mojave). When I reverted the graphics driver to the one in OSX 10.13.4 it got way better (even on Mojave). The blue light is still an issue, but hey, no migraine 😃

                                                      Edit: Ok, Apple does something on 10.13.6 and up that cannot be fixed by reverting the graphics driver. So I need to go back to 10.13.4 (or 10.14.5 with old driver) to get my head straight again...).

                                                      • andc replied to this.

                                                        deepflame

                                                        Replied in the other thread. Started having issues after High Sierra on 2015 model. Now as I put it under scope it’s on HS probably, I’ll have to check it since I don’t use it on regular basis.

                                                          dev