0.5 update: added experimental multithreaded mode (-j).

Experimental because it's currently 8% slower than singlethreaded for some reason.

@marcomics, the analyse subcommand will stay, of course.

It should support all common image formats, I think.

Having observed your palette, I decided there should be an additional mode where a big (like 1280x1280) gif would be generated, showing slowly rotating 3D CAM16UCS representation with the important graph structure of the palette (ramps and cycles).
But there're some other things I need to do before that.

@marcomics, the colours look really good, and the art is nice!
Some recommendations:

• For close colours, remove one in a pair instead of shifting entire ramps to preserve the general structure;
• Once you have a few free colour slots, populate these with purples or whatever else you desire. Maybe there could be additional orange shades as well, or a variant of violet with more chroma;
• Whether to exclude certain turquoise shades, I can't say. It can be one of palette features, and it looks fine to me.

Concerning logos, I'd recommend one of numbers 12 (but there're many similar logos already) and 13 (could benefit from making it a bit bigger).

P. S. By the way, keep in mind that palette examples on Lospec shouldn't contain any text except for palette name.

@marcomics, thank you!
I checked this, and Visual Studio Build Tools are indeed required for Windows installation of Rust toolchain with default options. I'll add a note into readme.

Probably I should start generating binary releases for all platforms at some point.

0.4 update: daemon command parser is upgraded, now it's using the same library as for the command-line interface. In particular, it means that it can finally do ~everything the command-line app could.

@b236, the contour and RGB primaries are now added.

@pixel-potter, if you mean the program, it wasn't very hard (and I already had the 0.1 version written in Python). As you can see from the source code, it's quite straightforward. XYZ to CAM16UCS conversion is one of less trivial parts, but I just followed the algorithm from the CAM16 paper. A couple of metrics/distributions used are described in other threads of this forum section.

I sampled some colours from an image of von Luschan's chromatic scale and here's the result:

Looking at the plots, I doubt that there can be a vectorscope-like line for skin tones: the range of hues is at least 60°.
I could still add a curve approximating skin colours, but it seems it won't be visible for most palettes because of low chroma.

The range of wavelengths in spectral distribution is currently 4100-6650 angstroms (in other words, 410-665 nm).
It was supposed to be wider, but I had issues in the 0.1 version (which was in Python) with computing CIExy hues because XYZ values were near-zero and lack of precision made the hue function outside of those boundaries non-monotone. I'll test if switching to f64 in Rust will allow to expand it again.

Yeah, marking hues could be ok.

I'll test some skin tones and add the line.

Alternative UI colours are already added (the -g flag).

@b236, thank you for the feedback!

1. One of my primary goals was to make all the widgets as perceptual as possible. As a result, I don't want to use RGB saturation anywhere - it's perceptually misleading. Breaking possible assumptions about how colour analysing software works is fine then, I guess?
2. Oops, I forgot to invert the Y axis there. I'll release a bugfix soon.
3. Do you mean making the central foreground colour closer to skintones or adding a widget to show possibilities for skintones in the palette? I have some plans for analysing what materials could be depicted with the provided colours, but it'll require some time and work. Concerning the foreground colour, it's chosen automatically to be visible in context of other UI colours for an arbitrary palette. I don't see any good way of adjusting it without sacrificing some readability for certain cases.
4. I'll think of how primary colour marks could be added while being visible even for a 256-colour palette.
   Probably I'll add a contour showing the area where the colours might be.
5. In this example, the green was chosen as an approximation of 50% grey. It does affect the perception of the palette but I'm not sure it's bad. Well, I can add alternative UI colours as an option.

P. S. I considered making distribution lines colourful, but that'll cause problems for darker colours, such as barely visible segments. But maybe adding marks like under the rectangular lightness-hue widget will work?

Source: https://github.com/Quickmarble/censor.
License: MIT.

Censor is a standalone command-line palette analyser inspired by DawnBringer's Palette Analyser for GrafX2 and having a compatible layout. Among numerous differences,

• All widgets use CAM16UCS with perceptual colour distance;
• You can load palettes from command arguments, text files, images and Lospec;
• Daemon mode can be used for larger numbers of analysis requests;
• There will be support for using the analyser in web pages after compiling it into WASM;
• Palette metrics can be computed and printed without producing an image;
• It is swift. As of 0.5.0, hyperfine benchmarks show that a 256 colour palette is processed in 64ms-on-my-machine (for comparison, the same palette is processed in 442ms-on-my-machine by DB analyser running with luajit through a shim by PureAsbestos).

Examples:

You can find more detailed description and installation instructions on GitHub.

An announcement.

The submission period is closed. Additional announcements will follow.

An announcement.

Due to community events limiting potential participants' ability to invest time into participating (namely, Lospec Jam 1), the deadline is extended.

New deadline: August 11.

Rules and submissions.

This thread is a proper place to share ideas, discuss entries or find a team.

This thread is for submissions and should not be used for discussion.

Discussion thread.

Unlike other collabs, this one will not require creating art. Instead, you are encouraged to do some theoretical research that would be useful for restricted art of any kind.

Your result does not have to be impeccable or have great impact to be valid.

It could be:

1. Colour theory. Metrics, algorithms, properties, transforms, classifications, guidelines with theoretical ground and more, applied to colours, to colour combinations and to restricted palettes. The entry may be a palette or a group of palettes given that those are obtained as a result of documented theoretical work and also have high general use value. In particular, such palettes shall meet Lospec palette requirements.
2. Dithering (including temporal dithering and 3+ colour dithering). Metrics, algorithms, properties, transforms, classifications, guidelines with theoretical ground and more, applied to dithering patterns, to combinations of such patterns and to their usage. The entry may be a group of patterns given that those are obtained as a result of documented theoretical work, have high general use value and also are not the simple well-known ones.
3. Theoretical results in other areas - you got the spirit.

How to choose your direction? Think of something related to restricted art that you think you could systematise in a more formal way and nobody seems to have done that already.

Still no ideas? Ask others: many of non-participating artists might have thoughts of what could be done, and some of participating ones could have spare ideas as well.

Rules:

• Your result should help creating, analysing, systematising or evaluating restricted art pieces, palettes etc., or provide a foundation for further results in these areas.
• You may use any sources given that your results are explained well; it is also advised to cite the important sources.
• Your result may be something well-known in other areas given that it is not such in restricted art, like an overview of existing results and their applications.
• You may freely discuss your entry anywhere.
• You may work in a team.
• You should not copy other entries - but you may explore other aspects that were not considered in those entries to extend an earlier result or get another.
• You may submit multiple entries.

A submission is a message in this thread (you may also want to publish your result in a distinct thread). It should contain:

• A title summarising your result.
• Team members, if applicable.
• An abstract with a proper statement of your result and some context.
• The main text. Graphs and illustrations could make it easier to understand.
• Cited sources, if applicable.

You may post a PDF instead of formatting everything in Markdown.

Deadline: August 11.

When the collab is over, a selection of results will be chosen and presented in a way that will be determined later.

So the algorithm is taking the main 5 colours of each image, building a k-d tree in 15 dimensions for the whole dataset and then searching for the nearest points?

Some general feedback:

1. It'd be nice to have Pinterest-like UI with piece titles and other basic info displayed.
2. It'd be nice to have other colour choosers, preferably some perceptual ones. CAM16UCS to RGB conversion isn't very complex, for example.
3. It'd be nice to have links to the original source.

Indeed, the initial motivation was to filter palettes with very close colour pairs.

For a less sensitive version, you could use minimal kNN distance instead of minimal pairwise distance. Let's see an example:

k=2, n=3. Let's say the colours are A, B and C. d(A, B) is nearly zero and d(B, C) = d(A, C) = d >> 0. min_kNN ~ d/2, mean_d ~ d * 2/3. Then kISS ~ 0.64, which is a low score (while the usual ISS will be astronomically large).

Considering kISS for different k together could be sufficient. Maybe just use maximum of kISS for k in {1, 2, 3, 4}? I'll test it later.

The minotaur looks great! Especially I like how the background was done.

Have you tried https://lospec.com/palette-list/spaff-8?

You could also try one of my unfinished palettes (probably I'll still be adjusting it for some time before publication):
#310440
#571802
#917e01
#e06309
#c408b2
#006fde
#11bda0

Real spectral distributions of colours are lost whenever conversion to XYZ happens, yet some tricks may produce certain correlating characteristics of a palette.

The procedure

Given a white point (x, y) in CIE xy, do the following:

1. Define the illuminant ill using (x, y), according to CAT16 transform.
2. For each colour:
   1. Using ill, convert it to CAM16UCS and extract chroma C (in [0; 1]).
   2. In CIE xy, determine its hue angle relative to (x, y).
   3. Based on hue, find the nearest spectral wavelength w or determine that the colour is in the non-spectral area. If the latter is the case, ignore the colour.
   4. Add w to the statistics with weight C.
3. For each wavelength in statistics, define a gaussian function with a fixed standard deviation of choice and a multiplier equal to the weight of the particular wavelength.
4. Sum those gaussians and normalise the result.

Choosing the white point

Considered options:

1. Use something fixed (like D65).
2. Use the centroid of the palette in CIE xy.

Issues

Many colours could map to the non-spectral area. If they are ignored, much information concerning the palette is lost.

Usage

Currently, probably just as a characteristic to evaluate certain aspects of the atmosphere the palette creates and compare those between palettes. Still, in pieces using the palette, distribution of colours is very flexible, which affects how the illuminant will be perceived.

TODO

• Explore more possibilities.
• Test with palettes composed of spectral data (Pantone?).

https://lospec.com/palette-list/tomioka might be good, I'll test it when I have time but finding the time may take some time, so I'm posting it here for now.

Minimising ISS can be restated the following way. We have n spheres of specified radius min_d/2 (which can be fixed as we can scale everything as we desire) and we need to position them to minimise mean pairwise distance between their centers. Then the problem is quite close to sphere packing (minimising the radius of the minimal sphere containing all of those), and solutions to sphere packing seem to be at least good approximations for minimising ISS, if not exact solutions.

Well, I'll look into that later.

Lospec is a moderated resource relying on submissions, so many palettes that could have lower ISS might be rejected or not submitted for various reasons.
And yes, if many colours are similar, it may result in ISS being low. In any case, they seem to be spread more or less well in the analysis.

Indeed, DawnBringer's weighted brightness can be used to improve RGB distance, which wasn't really designed to be perceptual. But is it so important for modern uniform colour spaces like CAM16UCS?

@hapiel, thank you!
According to my data, a month ago the palette with the lowest ISS on Lospec was https://lospec.com/palette-list/resurrect-32, with ISS around 0.39.
Concerning generating palettes to minimise internal similarity, I doubt it's something that should be done. When ISS is too high, the palette quality suffers, but once you're in the safe zone, you have some degrees of freedom to shape the atmosphere, and there is no task more important. Moreover, ISS is just one metric and you should consider many to understand the palette better.

I'm looking for musicians. The entry will be an app, not a game, but there's a need for background music and sound effects.
Contact Azathoth#1893 on Discord.

Obviously, there is no sense in choosing a contextless colour because there is chromatic adaptation. A context could mean:

• Specific illuminants under which the colour is observed
• A specific palette which interacts with the colour under specific illuminants
• Something else?

That said, people memorise a number of illuminants they frequently encounter. Moreover, many get used to thinking of colours in context of those illuminants and consider some colours pleasant or not with no context references, which sometimes is a cause of colour-related communication issues even without considering psychological preferences.
Anyway, let this be my current choice in my implicit colourimetric context:

Definition

One of reasons a palette is of limited usability is that it has colours that are too similar in context of their structure. In particular, it means that there is some pair of colours such that the colour distance between them is much smaller than the mean distance between colours in the palette.
I suggest a metric that would allow detecting such cases with computation.
Suppose we have a colour distance function d. For a palette of size n>=2, mean_d and min_d would be mean and minimal pairwise colour distances. Then Internal Similarity Score is defined the following way:
ISS := (mean_d/min_d) / n^(2/3)

Explanation

While the mean_d/min_d is the part one wants to keep limited, we need to keep in mind that with greater number of colours there is the same volume to position them, and min_d will be systematically lower while mean_d suitable for art would be quite stable. To compensate this effect, the ratio is multiplied by a rough estimate of expected minimal pairwise distance between n random points in a unit cube, which also gives a reasonable asymptotic estimate for non-cubical perceptual colour spaces.

If mean_d = min_d, ISS = 1/n^(2/3). It will also be the case for n=2.
If all the colours are multiplied by a non-zero constant, ISS is intact.

Choice of distance function

It is desirable to choose a colour distance function that would reflect perception well.
Tests were made with CAM16 Jab and basic euclidean RGB distances. While their outputs generally correlated, there were many palettes that had considerably different ISS.
The results also looked much more stable with CAM16, but are also ~acceptable with RGB.

Data

Two data sources were tested. One is a dump of Lospec moderated palette database (labelled as all) and the other is https://sites.google.com/view/rejected-palettes/palette-list (labelled as rejected), which contains a mix of rejected and accepted Lospec palettes that seemed poor to moderators of rejected. A few number of palettes with extreme values were omitted in some graphs to make them legible.
ISS comparison shows that many of rejected palettes have considarably higher ISS values:


Typical ISS-CAM16 values for palettes from all range from 0.4 to 1.9.