Show HN: High End Color Quantizer

> eaaaarly stage […] beta

If your goal is for users to adopt the use of the software, then you can easily increase acceptance by going the proverbial extra mile:

1. Make it installable via `uv tool install patolette` with the optimisations taken care of automatically. 2. Compare its results in the documentation/on the project Web site against the incumbents. https://news.ycombinator.com/item?id=26646035 Find standard test images https://ddg.gg/?q=color+quantization+test+corpus , copy the split-image/slider technique from https://uprootlabs.github.io/poly-flif/

The rationale for this is that each interested user should not have to replicate this work on his own.

What's the primary use case you had in mind here? In the example I see it generating a palette of 256 colors and then using them, but it doesn't seem to correspond to any modern use case. AFAIU one currently needs dithering either as part of print/display process (but then you have a fixed palette), or for compression, but I think this makes sense nowadays only with very low color count, like 16 max?

This doesn't seem to be gamma correct, I just see / 255 and * 255.

sRGB is a nonlinear colour space and so you can't do linear operations in that space (because a^2 + b^2 isn't (a+b)^2 in general).

The example image only shows the differences between parts of the image that are deemed as salient, but does not show the effects of the tradeoff on the non-salient parts nor does it show an entire quantized image.

I'd say that showing full example results are the most important part of showcasing a "high end" color quantizer.

Can this also do quantizations like median cut?

Does it also support colour spaces other than RGB, CIEDE (I think I saw that in the source), i.e CMYK for paint mixing, and similar ilk?

I have a few personal projects that would benefit from a library that is wide ranging in the colour space, dither algorithms (I only saw riezsma) and quantizations.

Typically these are all usually implemented in different libraries :(

Thanks!

Wu v2 is really good. i said it in 2015 :)

https://news.ycombinator.com/item?id=9213955

see that whole thread, too

What specifically about this paper caught your eye that you wanted to implement that, what does it do better than other methods? Can you give a quick primer on what it does, and what the optional kmeans refinement does?

Very cool!

Something that always bugged me about palette generators I've used is how they end up not picking any colors intense enough for the deepest highlights/shadows, because they use colors close to the average of various sets of pixels.

The result is that the most eye-catching parts of an image end up washed out, reducing the appeal.

My hack to address this has always been making a larger image with big white/black bars around the original image to push the palette generator to include a few really bright or dark colors.

From the look of your examples, your project addresses this too, right?

Btw, I opened an issue about the graphs in your readme because, as a programmer, they don't tell me if your program is fast or not. From a user's perspective that thinks in terms of the side length of an image, the numbers presented are very useful, but they might be even more useful in table format.

There so many interesting papers out there without a publicly accessible implementation, very cool that you made this. Question out of curiousity: what made you pick Riemersma dithering?

Fantastic project and documentation. Thanks for putting it up there.

Please consider adding this and possibly other algorithms to CUPS printing system. Easiest is to add it into ghostscript.

https://github.com/OpenPrinting/libcupsfilters/pull/92

What is color quantization used for in this lossy compression age?

Would this be a good candidate for use in image posterization? That was what I assumed it was for.

I looked for pytorch native implementation for Xiaolin Wu's quantizer like 3 month ago, and found none. Would not it be much easier and more productive to integrate with pytorch? Some of the functionality which you have there is already provided by kornia, torch_kmeans. You'll end up with much less code to worry about.

i wonder how something like this would perform if adapted to oklab or oklch. these should give good eucledian color distances.

[dead]

[flagged]

[flagged]