0.8.5 "Mix Things Up"

This release mostly changes how SimplePalette.parseDescription() works for all color spaces with a SimplePalette. Now you can specify weights for colors by adding a number after any color name (this can be space-separated as in red 5 blue 2, or can use most punctuation, as in red^5 blue^2). These examples should be exactly equivalent to red red red red red blue blue, but I definitely prefer the way with numbers! Lightness and saturation modifiers also changed how they are evaluated in some places. Lightness changes generally work by lerping towards white or black now, instead of just changing the L component for Oklab and CIELAB, or the I component for IPT_HQ. This seems to produce a meaningful change more often when a color had (in Oklab) an L value that was very close to 1 already, and you wanted to lighten it, such as light yellow. Saturation changes take effect after lightness changes, so even though lightening or darkening makes a color closer to grayscale, you can enrich it to counter that.

The other big change here is that Oklab now calculates lightness extremely closely to how RGB and YCwCm calculate lightness, which had been my goal with the last change to the light adjustment, but I hadn't obtained it until now. It turns out that no complicated formula was needed, and I already essentially had this adjustment done in the Oklab shaders -- now converting to and from Oklab is just equivalent to a Math.pow() call on L (using something like Math.pow(L, 3.0/2.0) to convert to Oklab, or Math.pow(L, 2.0/3.0) to convert from Oklab). In practice, this seems to smooth gradients quite well, and doesn't seem to have much speed difference.

As usual, if you're downloading these via the .JAR files below, you probably shouldn't be, but if you are.... you probably don't need the ones with -pure in the name (plus, those have more dependencies).

0.8.4 "Bright Idea"

This release mostly exists to add four more color adjectives to the four there already are. This brings most of the SimplePalettes here to compatibility with the adjectives TextraTypist was already using on its own, as was SquidSquad. The four adjectives (bright, deep, pale, and weak, plus -er, -est, and -most suffixes to amplify them) just combine two existing adjectives in equal amounts. Perhaps more importantly, the mixing formula for how much adjectives affect colors has changed for some color spaces, to try to match it to the change in lightness for Oklab. This is not at all a "necessary update" for users; it changes more features than it adds. The lightness changes in Oklab's SimplePalette may be useful, at least, as should HSLuv's SimplePalette.

As usual, if you're downloading these via the .JAR files below, you probably shouldn't be, but if you are.... you probably don't need the ones with -pure in the name (plus, those have more dependencies).

0.8.3 "Been A Long Time"

This release has taken a while longer, but there's some important changes here. The change that required the most work to implement was for Oklab; it makes pure-gray possible to represent, instead of having gray be always slightly bluish-green. Various other changes range from renamed fields and methods in Shaders (where quite a few names were incorrect or misleading), to fixes for several floatGetHSL() kinds and RGB's toEditedFloat(), to more lightness changes in Oklab. TrigTools now uses current code copied from my digital library, and the old oddly-named methods like sin_() and atan2_() are now called sinTurns() and atan2Turns(). Oklab's ColorTools also has distanceSquared() and distance() methods for comparing the similarity of two colors. That's about all here; it's quite spread-out, but I hope this release is useful!

The colorful-0.8.3 jars are most likely the ones you're after. They require libGDX (any version 1.9.13 or newer; 1.11.0 is currently recommended). You probably don't need the colorful-pure JARs here unless you know you don't want a libGDX dependency (such as for some servers), but if you use them you will also need the JARs for digital, juniper, funderby, and jdkgdxds. Please consider using a project management tool, like Gradle or Maven!

0.8.2 "Hassling With HSL"

This release mostly concerns the recently-added HSLuv code, particularly its ColorfulBatch, and makes its shader act correctly (it didn't before). This took a lot of time and frustration to get right, so I really, really hope it works without any strange graphical glitches. There's also a GWT bug fixed in the rgb, oklab, and cielab packages, with the ColorTools.toEditedFloat() method and affecting alpha.

The colorful-pure JARs now depend on jdkgdxds 1.0.2, juniper 0.0.2, and digital 0.0.2, all available at repos under the same user as colorful-gdx (tommyettinger).

0.8.1 "Faster Than Light"

Less than an hour after the (official, GitHub) release of 0.8.0, here's 0.8.1, with a simple fix for the lightness used by color constants in HSLuv's Palette and SimplePalette classes. The need for a fix was clear; in the comparison demo, HSLuv almost always displayed a lighter color than any of the other color spaces. The implementation of the fix was even more clear; I only needed to re-generate the large blocks of color constants from the source data using PaletteCodeGenerator (a tool in the tests) and update those two palette classes. This significantly improves the accuracy of the color descriptions in SimplePalette, and makes the actual colors match their docs.

For more info on the new HSLuv color space, see the README.md or the release notes for 0.8.0 (where they are summarized briefly). This also includes the lightness changes that were applied in 0.8.0 to Oklab, so updating from 0.7.0 would see Oklab colors change as well as the new option for HSLuv.

As before, you probably want colorful and not colorful-pure if getting the JARs below. If you don't use libGDX, then colorful-pure is potentially a good option. The colorful JARs depend on libGDX 1.9.13 or higher; the colorful-pure JARs depend on jdkgdxds 0.2.8 or higher.

0.8.0 "Luv Hue"

This is a fairly major release, adding the HSLuv color space and adjusting Oklab's lightness again (though less significantly). HSLuv is a nice color space for user-defined colors, since just about any combination of Hue, Saturation, and Lightness is valid (only saturated white and saturated black are somewhat invalid, but even those can be handled). It tends to have a much more even lightness estimate than standard HSL, and internally it has a computable gamut rather than a large table (saving some memory and code size). I acknowledge that the HSLuv lightness estimate is still probably off in this release, and 0.8.1 should follow soon when I figure out how to better handle this. Oklab's lightness estimate, on the other hand, seems extremely close now to the one used for RGB colors.

As before, there are colorful-0.8.0 JARs below and also colorful-pure-0.8.0 JARs; you probably want the colorful-0.8.0 ones. The only time you would probably want colorful-pure is on a headless application (often a server) that doesn't depend on libGDX (1.9.13 or higher), but can depend on jdkgdxds (0.2.8 or higher).

0.7.0 "Lighter With Notes of Oak"

This is in some ways a more substantial release than the previous one, even though 0.7.0 doesn't add a new color space and 0.6.1 did. Why would that be? There's just been a lot of work here. There is a GradientTools class for each color space, allowing easier generation of gradients of packed float colors between 2 or more specified colors. Critically, Oklab's lightness has been adjusted, so 50% gray (in RGBA, 0x808080FF) actually is at almost exactly 50% L, instead of 63% where it was before. This wound up being part of a massive set of debugging and repeated back-and-forth changes that found earlier issues in the Oklab gamut -- and this time, they seem to be fixed. In several earlier releases, ColorTools.oklabSaturation(), which is defined as returning a fraction of the maximum possible chroma a color can have with the same hue and lightness, would sometimes return higher numbers than 1, like 1.4 for blue. Naturally, using unexpectedly-out-of-range values would have caused problems. This was related to other gamut issues, but the cause mostly boiled down to hue() being used in some places (which uses HSL's hue algorithm) and oklabHue() used in others (which would be correct in this case, and gives the actual angle in turns to get the needed A and B channels).

I'm less than enthusiastic about CIELAB now that Oklab looks a fair bit better than before. CIELAB turns out not to have its black color positioned at the center of A and B (it's off to higher A and slightly higher B than it should be), and gradients with CIELAB seem to often have strange color changes in the middle. Hats off to Björn Ottosson, for creating a color space that beats CIELAB after it has been the go-to for many years.

The docs are all updated, the preview images are also updated, and there's a fresh coat of paint on everything. I hope you enjoy.

0.6.1 "It Came From The LAB"

This release adds support for the CIELAB color space (specifically, the 1976 CIE L*A*B* color space), which this takes pains not to approximate in most key aspects. As a result, it tends to be slower to do some operations than Oklab, and because the two color spaces are otherwise rather similar, Oklab is currently recommended. There is some small but significant optimization to Oklab-related code here, so there's a reason to update even if you don't use CIELAB.

0.6.0 "Many Minor Messes Mopped"

This is something of a big release, because it's just been a while since the last one and I've been coding away here... Many bugs have been fixed and many small features have been added. Some weird issues with the Oklab and RGB ColorfulBatches are fixed. The gamut, mostly for Oklab, has been tinkered with a lot and I think it works well now. There's many more methods in Oklab's ColorTools for dealing with colorfulness, such as oklabSaturation(), chroma(), and chromaLimit(). All of the color spaces have some editQuux() methods, replacing Quux with the current color space. This allows you to edit the RGBA channels of a color with editRGB() just as you can edit the L, A, B, and alpha channels of an Oklab color with editOklab(). SimplePalette has been brought over to the RGB color space, and all of the SimplePalettes and Palettes allow you to convert the existing colors in libGDX's Colors to the current color space, or append the SimplePalette or Palette entries to Colors. In general this should be a worthwhile update, if only for the several key bug fixes.

colorful depends on libGDX 1.9.13 or higher, and colorful-pure depends instead on jdkgdxds 0.1.2 or higher. colorful is probably what you want here.

0.5.1 "Form A Perimeter"

This release has various small improvements, but more significant changes to Oklab. Before, A and B were compressed so their -1 to 1 range would fit in the 0 to 1 space each channel gets. However, because Oklab's A and B channels are so narrow, compression isn't necessary, and so they are allowed to be their actual width now (which is smaller than -0.5 to 0.5, so fitting that in the 0 to 1 range just needs an offset). This means when comparing the difference between two Oklab colors, you should now use the normal Euclidean distance, Math.sqrt(L * L + A * A + B * B). Another change involves an optimization to how the gamut is found for Oklab, which also improves the quality when colors are brought back into the gamut from outside of it. A possible breaking change affects the inverseLuma(), inverseIntensity(), and inverseLightness() methods, which are now all called inverseLightness() to make translation between ColorTools versions easier. There are now added differentiateLightness() and offsetLightness() methods that act something like inverseLightness() but don't consider chroma at all; offsetLightness() takes one color parameter, is about the same as differentiateLightness(), which takes two colors, if you called it on the same color for both arguments (offsetLightness() differentiates a color from itself). There's a fix to toEditedFloat() in everywhere that needed it; most implementations used the luma, intensity, or L (as in LAB) in that calculation, but it needs to use the lightness from HSL, as inaccurate as it may be in general, for the HSL edit to work correctly. All in all, this should be a worthwhile release, and I hope I didn't miss any problems.
If I did, the Issues tab is wide open.

This release depends on libGDX 1.9.13 (or higher) for colorful, or jdkgdxds 0.0.5 (or higher) for colorful-pure. You probably want colorful, if you're using the JARs here, and don't need colorful-pure, but there could easily be a case where the opposite is true.