mpetroff

My initial instinct is that finding 12 colors that are visually distinguishable for all users is likely impossible.

Without going to lightness extremes, I agree that this likely isn't possible, at least when trying to accommodate all three types of dichromacy and for small color patch sizes (like those typically used for line and scatter plots). For example, you could take the 10-color accessible palette from work I've published [1] and add black and bright yellow to get twelve colors, but the lightness extremes of adding these colors would result in significantly-different visual weights. Based on a validation survey I conducted, I think even ten colors is pushing the limit of what's reasonable when lightness extremes aren't used.

could share what colors in the 12-bit palette...are problematic

#9d5 and #4d8 is the color pair I find particularly problematic.

[1] https://arxiv.org/abs/2107.02270

While not completely identical, it looks very similar (I also only have strong protanomaly, not complete protanopia, so I wouldn't expect it to look identical).

Color-vision deficiency simulations collapse colors along the confusion lines, but this can be done multiple ways. These different mapping will all look the same (and identical to the original) to a dichromat but will appear different, with different perceptual differences between colors, to a color-normal individual. Simulating in a way that accurately portrays perceived color distances is still an open research problem.

Please don't use rainbow-type palettes, as they generally have poor accessibility for colorblind individuals. With my red deficiency, the middle two colors in this palette look virtually identical.

I wrote a simple web-based night sky viewer a while ago [1], which renders the 750 brightest stars from coordinates in a data file (along with the moon). It uses D3.js to do fully client-side SVG-based rendering for interactive use, but it could be simplified to render server side to an SVG file. I think the main complication is that by adding stars, a projection needs to be decided on, and you'd need to consider the aspect ratio of the browser window.

[1] https://github.com/mpetroff/nightsky

Figure 24 in Paul Tol's Notes is a reasonable thing to try: https://web.archive.org/web/20250201164619/https://personal....

However, to properly screen for color vision deficiencies requires calibrated spectra. Thus, even a color-calibrated monitor is insufficient, since color calibration assumes that the standard cone response functions are valid, which isn't the case for anomalous trichromats (which encompasses the most common types of colorblindness). This is why screening, such as with the HRR test, is done with plates printed with spectrally-calibrated inks in controlled lightning conditions (again with a known spectrum).

Always fun to bump into Polies here :)

Definitely! I wasn't expecting to see a mention of BICEP while reading HN from Pole, particularly not on something as arcane as its star camera.

With images taken at night, you can run the images through Astrometry.net, which is a blind astrometric solver and will provide you with RA / Dec for most images, as long as you have at least a dozen or two stars visible. The code compares asterisms formed by multiple stars to index files built from Gaia or other similar data. This is the technique that's used more frequently for microwave telescopes located where there's a normal diurnal cycle, e.g., CLASS. The smaller the field of the view, the higher the precision, but it also works fine with a camera with a zoom lens.

BICEP, however, is located at the South Pole on a moving ice sheet, requiring frequent updates to its pointing model, and has six months of continuous daylight, so daytime star pointing observations are required. This requires a different technique. Instead of looking at asterisms with multiple stars, the optical pointing telescope is pointed at a single star using an initial pointing model, the telescope pointing is adjusted until the star is centered, and the offset is recorded. This measurement process is repeated for the few dozen brightest stars, which acquires the data needed for refining the pointing model.

BICEP3 actually uses a >20 year old CCD camera with analog video output (BICEP Array uses newer cameras, with more modern sensors). Daytime star pointings are possible by using a low-pass filter to block visible light and take advantage of the sensitivity of CCD / CMOS sensors to the near infrared, where the daytime sky is more transparent, combined with baffling.

the default color palette is colorblind-friendly

No, it very much isn't. The second and third colors, the orange and the green, look extremely similar to protanopes (red deficiency). Fortunately, there's a plan to fix this for Matplotlib 4.0.

I implemented it as part of a GSoC project a decade ago, which was first included in the 0.91 release in 2015.

You're correct, and the other responses saying otherwise are misinformed. Protanopes do not have long-wavelength cones and thus have reduced sensitivity to that end of the visible spectrum, i.e., red light appears dimmer to such individuals. This is also why red on black (or vice versa) is a color combination with poor accessibility, since it has reduced contrast for protanopes as the red appears darker and thus closer to black.

That's to be expected since the Coblis methods, particularly the v1/ColorMatrix version, are known to be very inaccurate. Unfortunately, it's usually the top search result for "colorblindness simulator," which leads folks with normal color vision who try to check for color vision deficiency accessibility to conclude that the images they're checking are accessible in cases when they're not.

It applied a linear transform to RGB values, like the current method, but the original matrices were the "colorjack.com matrices" [1] that have been floating around the internet for a while. They weren't derived scientifically and are quite inaccurate, at least for protanopia.

[1] https://github.com/MaPePeR/jsColorblindSimulator#the-colorma...

For those interested, I've done some recent research on this topic [1], which tries to find cycles of colors that optimize both accessibility for color vision deficiencies, using simulations and minimum perceptual distances, and aesthetics, using crowd-sourced survey data.

[1] https://arxiv.org/abs/2107.02270

The simulation technique [1] currently used by the Firefox / Chrome dev tools is reasonable, so it's definitely much better than not checking for color vision deficiency accessibility at all. Ideally, color should only be used for progressive enhancement; if your UI can be used in grayscale, it's probably fine.

However, the method originally used by both browsers, which is also used by some other tools, had no scientific provenance and produced clearly incorrect results, so one needs to be careful about this sort of thing in general.

[1] https://doi.org/10.1109/TVCG.2009.113

I'd argue that the 147 named CSS colors are still too many (but definitely better than the ~16.8 million sRGB colors). Regardless, since hex codes are used in practice, they would still need to be dealt with.

This would be true if the CSS color names were actually reasonable, but many of them are not.

One would be better off using the results [1] of Heer & Stone (2012) [2] (or a similar analysis) to assign names to sRGB colors. You end up with 33 unique names instead of more than 100, and the number of unique names can be reduced further by merging synonyms.

[1] http://vis.stanford.edu/color-names/analyzer/ [2] https://doi.org/10.1145/2207676.2208547

The WCAG also define the contrast ratio in terms of sRGB, which is not a perceptually-uniform color space. This makes the WCAG contrast ratios somewhat meaningless in terms of human visual perception. It's accessibility by edict, not science.

There's a rather lengthy discussion of this on the WCAG issue tracker [1].

[1] https://github.com/w3c/wcag/issues/695

The issue isn't with referring to colors on a chart by name but with using a color name as the sole identifier. Referring to parts of a chart by color is fine, and provides additional information, as long as a line style or shape identifier is also used, e.g., the "blue solid line" and the "orange dashed line" in the case of a line plot or the "blue circles" and the "orange squares" in the case of a scatter plot. Ideally, I think color swatches should also be included when referring to colors, so it isn't necessary to match the name to the color [1].

[1] https://mpetroff.net/2019/11/figure-caption-color-indicators...

The key would be to spend an absurd amount of time carefully cataloguing good colors – by hand – and training it to extrapolate from that information.

It's a bit more nuanced than that. Not only do you need to catalog good colors (and color combinations), you need to have it done by a large number of people, since different people perceive color differently and have different aesthetic preferences. This is something I've been working on in the limited context of color cycles for data visualization and plotting [1][2]. Based on my preliminary analysis, these data are quite noisy.

[1] https://colorcyclesurvey.mpetroff.net/ [2] https://mpetroff.net/2020/01/color-cycle-survey-update/

I linked to the supplementary information [1] in my previous comment, but here's the link for the paper [2]. The method is implemented by the Colorspacious library [3] for Python, and the source for my color picker [4] contains both JavaScript and WebGL implementations.

[1] https://www.inf.ufrgs.br/~oliveira/pubs_files/CVD_Simulation... [2] https://doi.org/10.1109/TVCG.2009.113 [3] https://colorspacious.readthedocs.io/en/latest/tutorial.html... [4] https://github.com/mpetroff/color-cycle-picker

Adding to this, the Chrome (83+) and Firefox (81+) developer tools both do a reasonable job at the simulation, using the method of Machado et al. (2009) [1].

Unfortunately, the linked to simulator, like many of the online simulators, does a very poor job. When simulating protanopia, reds should appear darker, due the lack of L cones. However, many simulators incorrectly display red as bright green instead.

I've also written a color picker that uses the Machado et al. method to enforce CAM02-UCS minimum perceptual distance for normal vision and color vision deficiency [2].

[1] https://www.inf.ufrgs.br/~oliveira/pubs_files/CVD_Simulation... [2] https://colorcyclepicker.mpetroff.net/

It's possible, but the markup is very, very messy. I made a proof-of-concept by hand a couple months ago [1], but it would require quite a bit more work to automate it. It's probably best to just wait for browsers to implement CSS Text Module Level 4, which includes a property for enabling use of better line breaking algorithms.

[1] https://mpetroff.net/files/pre-calculated-line-breaks-demo/

Bertin's Semiology of Graphics?

I have `hyphens: auto` set for the browser default comparison in the demo, which is roughly equivalent to inserting soft hyphens for Firefox (where I was doing most of the development), as well as for Chrome on Android and macOS.

While browser hyphenation (either auto or soft hyphens) is definitely an improvement over no hyphens for narrower column widths, I think it generally makes things worse for wider columns, since it frequently adds unnecessary hyphens.

Edit: I updated the demo to use soft hyphens for the browser default comparison so the text is hyphenated in all browsers.

This had me wondering about whether it was possible to use pre-calculated line breaks to implement improved text justification in current browsers. I was able to come up with a demo [1][2] that does so, although it falls back to default line breaks in Safari due to lack of support for `text-align-last`.

[1] https://mpetroff.net/files/pre-calculated-line-breaks-demo/ [2] https://mpetroff.net/2020/05/pre-calculated-line-breaks-for-...

The problem is that CSS uses greedy line breaks. In theory, this should improve once browsers implement CSS Text Module Level 4, specifically the `pretty` value for the `text-wrap` property [1][2]. Until then, we're stuck with poor-quality typesetting, or JavaScript solutions [3].

[1] https://www.w3.org/TR/css-text-4/#text-wrap [2] https://github.com/w3c/csswg-drafts/issues/672 [3] https://github.com/robertknight/tex-linebreak

Thanks for passing this along. I also commented on the relevant Chromium issue [1] (as well as the relevant Firefox issue [2]). It should be a simple fix, since the transformation matrices just need to be updated.

Edit: I should have looked at the Chromium issue again today. It's already been fixed!

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=100370... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1564993

Unfortunately, this uses a horribly inaccurate algorithm that's been floating around the internet for more than a decade [1]. It seems that the Firefox dev tools do the same thing [2]. As far as I'm concerned, this is worse than not having such a simulation at all, since it gives people a false sense of accommodating individuals with color vision deficiencies.

The Colorspacious Python library [3] does a proper job, using the algorithm of Machado et al. (2009) [4], which is what's considered state-of-the-art.

[1] https://github.com/MaPePeR/jsColorblindSimulator#the-colorma... [2] https://hg.mozilla.org/mozilla-central/annotate/tip/devtools... [3] https://colorspacious.readthedocs.io/en/latest/tutorial.html... [4] https://doi.org/10.1109/TVCG.2009.113

This is a common misconception; both were recommended because they performed equally well on available data at the time [1]. While CIELUV does have the advantage that additive mixtures fall on straight lines in its chromaticity diagram, it does poorly at predicting color differences and has a flawed adaptation transform, so CIELAB is generally preferred.

[1] https://doi.org/10.1002/col.5080150308