Originally Posted by zoyd
The internal generator has selectable colors by column when the user is in either the grayscale page or the primaries/secondaries page, any other page is not supported.
I propose a consideration for changing this behavior. I understand HCFR is, for lack of a better word, for "advanced" users, but some aspects could be improved upon.
Some examples of candidates are:
1) How Continuous Measure & Test Color interact with eachother and other measurement pages. Since grayscale or primaries/secondaries would most likely be one of the first pages a user would interact with, and are supported, one would expect things to behave just as they have up to this point, as there is nothing informing the user that functionality has changed.
2) The arrow buttons that add/remove rows to the measurements window. I like pressing all the buttons and seeing what does what, in general, but until clicking them I would never know, let alone expect, that those arrows were for another window table. I first assumed it was a generic next/previous/up/down button linked to the drop down menu because of their relative location and being in the same window table.
3) Zooming when viewing charts/graphs. Mouse wheel support and working keyboard shortcuts (Num pad +/-, while identified as a shortcut for zooming, does not work for me.) The CIE chart does have mouse wheel support, the scroll/zoom action is reversed (Typically it's user relative instead of display relative). A higher maximum zoom would be nice to have as well.
Please note that I am not demanding these, only proposing these and other quirks be given consideration for some point in the future.
Originally Posted by zoyd
If the test patch has a different value than the full screen output that's a bug.
I think I'm misunderstanding your response, so please bear with me as I try to clarify my observation. And to help, see the attached picture.
I've added a magenta box to highlight the color values shown in the Test Color window.
Ignoring the difference in naming (50% white vs 50% grey), you can see that there is a discrepancy in the values listed between the 50% white grayscale table listing and the 50% grey palette preset swatch. As I mentioned previously, this difference applies to the 10/30/50% columns of the Test Color palette.
Another quirk I've discovered is the Advanced>Test Patterns>Display Patterns do not comply with the primary monitor selected by either the system or the active HCFR file (changing the internal generators Target Screen does nothing).
The Animated white/black tests behave as expected (changing the target screen works).
Originally Posted by HDTVChallenged
In yet another of my "controversial" positions, I've come to the conclusion that schemes such as "local dimming" or "auto iris" do more harm than good. I think it is more important to have a stable transfer function that's been well tuned wrt black-level of the set. IMO, "dimming" is counterproductive, giving the illusion of "better" blacks, when it's actually just increasing the crush-factor of shadow details.
I may be misinterpreting you, so let me apologize in advance.
Note that this is my opinion, and solely based on how MY display, LG 55LM7600 (WLED IPS panel with edge-lit with, I think, 12 or so local zones), behaves in regard to local dimming.
Using my ColorMunki Display, and backlight increased to produce white at ~100 nits/cd m^2 for my viewing space, black measures 0.14 nits/cd m^2. This is extremely noticable, and being an edge-lit display you want to puke anytime the overall screen is dark from the uneven backlighting. You want that local dimming. Three settings (low/med/high), and off, are your options. High and Medium are very aggressive and signifigantly change the screen, and while I've not fully explored their effects outside of a few that produced banding on gradients immediately, I think one should stay away from such aggressive settings as they appeared to affect ALL stimulus levels with a variable range depending on apl and how much black per zone. I thought about trying to log this behavior, but I lack the experience and knowledge to even know how to observe useful information.
Low, however, is much nicer to the displayed scene, only effecting ~≤30% white levels. Using the same settings as above, black now measures 0.045 nits/cd m^2@field, 0.071 nits/cd m^2@10%window 20% APL. High with fields and lower backlight for a darker room can get low enough to not measure with my ColorMunki.
With my display, Local Dimming is not producing the "illusion" of better blacks, it actually produces better blacks by lowering the backlight in zones but not turning it off (the latter of which I would consider an illusion. Since Local Dimming at Low only affects the the bottom end, I think one should take that into consideration when adjusting grayscale/gamma if one plans to use said feature AND it their display behaves similar to mine.
If you use Local Dimming, with similar behavior, you might as well adjust that affected area for dark screentime to preserve as much white balance/gamma as you can, I mean if that zone is dark enough to trigger dimming then adjusting for SOME dimming has to be better than not doing so (read: higher chance of crushing) and all the screen zones that don't dim aren't effected.
I'm still exploring options to account for this dimming myself, unknown if Local Dimming is triggered by zone APL, luminocity, average zone black level + contrast, a mix of the mentioned or something else.