I can't seem to get the "right" pallete

[Pomax]

I'm running rgbquant on the following image in order to get the 10 most dominant colours out:

but instead most of the settings I've tried seem to come up with the following quantization:

Are there specific settings that work best for quantizing such that the final palette is closest to the original image?

(the orange is obvious, but also the little yellow bit in the original image has become pink in the quantized result, and the tiny plushy at the bottom has become half pink, too =)

[leeoniya]

try setting minHueCols to something big. 4096+.

edit: though for this size image, there arent even that many pixels :)

[Pomax]

still the same. With the following, the result is still pretty much the same color rewriting:

    var opts = {
      colors: 10, // also tried 20, still roughly the same but too many colours
      boxSize: [64, 64], // also tried 16,16 and 200,200
      initColors: 4096, // started at 256
      minHueCols: 4096
    };

if github does animated gif, here's the new result:

(in case it's useful, I put the full size image online at http://i.imgur.com/SnOkhf1.jpg)

[leeoniya]

so for some odd reason - and i've noticed this before - chrome and ff always give slightly different results. i'm not sure if this has to do with some bug in the histogram sorting or something else. it happens to be quite noticeable in this case, where the total pixel count is low enough for the smoothness of histogram statistics to break down.

chrome:

firefox:

[leeoniya]

sorry, i missed the full image. one sec.

[Pomax]

hm, looks like FF gets the "foxes" right, but the cheese wrong, with Chrome doing the opposite. That's quite weird! Would rgbquant still work if it didn't have a canvas to work with, but simply ran on top of a uint8array? The jpg.js library I'm using decodes jpg independently of what the browser/canvas will do, turning the data into an int array with the "correct" values (at least, as far as photoshop shows me), so if rgbquant relies on the canvas for certain operations that might be one possible reason there's color oddities showing up (thinking out loud)

[leeoniya]

i'll have to investigate, lots of stuff is tending to favor quantizing to pink. there's no specific reason i can think of for this to be happening. i tried using colorDist: "manhattan" rather than colorDist: "euclidean", but no difference. it seems to be picking the right palette, but something in the reduction step (the color distance) is being inaccurate. which is weird cause the same colorDist func is used for the palette histogram reduction step.

the lib doenst need canvas at all, you can pass it a Uint8Array + width: https://github.com/leeoniya/RgbQuant.js/blob/master/src/rgbquant.js#L840

[Pomax]

Comparison shot between irfanview, jpg.js-loaded-onto-canvas, and what Firefox turns the image into if it's loaded as <img> instead of on a canvas (note the <img> is pretty wrong wrt the other two), so this might also be caused by weird things happening by tapping into the image's data (say if it's getting used to paint onto a canvas for analysis)

I'll try to pass it a straight up uint8array, hopefully that behaves much better!

[leeoniya]

the way they all display the jpegs may be slightly different from color profiles etc, but i wouldnt expect jpeg decoders to be wrong wrt the raw ImageData, it should be identical. though i have seen some foo with the first gradient png in the demo on different machines/browsers.

let me know how it goes, i'm not getting my hopes up, though,

[leeoniya]

i have a question: how real is this issue for your use-case? it looks like in both cases, the resulting palette is pretty good, despite the reduction pass not quantizing as expected.

as should be apparent, when you get down to really low color counts (<16), the answers become less black-and-white (pardon the pun) in terms of right or wrong. So there is no single "correct" palette of 5 colors for a gradient of 10k that fall all over the hue/saturation/luminance space.

i consider the generated palettes to be quite good, with no additional amount of tweaking that will yield non-subjective improvements in generally-applicable use cases.

just to clarify, i'm not intending to close the issue, regardless of answer. the reduction pass should probably do a better job.

[Pomax]

pretty real - it's about matching colours in images to one or more fountain pen inks commercially available, so even in this example the "colour of the fox" should come out looking reasonably the same, since it makes up a fairly large part of the image, Instead it becomes a colour that's visibly off.

http://mighty-lake-2303.herokuapp.com => "match layout" from the selector in the upper left, then drag and drop an image onto the drop zone. This runs the image through rgbquant and does (Lab 'L' based) color matching to find the closest available inks that are commercially available. Ideally, this would give the situation where one can write something using a particular ink, save that as jpg, and then dropping that onto the matches, so that one of the best matches is simply the ink that was used to do the writing with (barring colors messing up during the 'taking a picure' stage of course)

example: dropping the swatch jpg from http://www.gouletpens.com/p339341/p/P339341 onto the matcher yields the same ink as the first possible match hit

[leeoniya]

i'll be fairly busy for a week or two, but if you find a more accurate way to color match (that has an acceptable perf profile), i'd be interested in what you find and maybe implement it in RgbQuant

[Pomax]

will keep you posted

[leeoniya]

@Pomax relevant discussion (though some of it in Russian): ibezkrovnyi/image-quantization#4

[Pomax]

that is certainly an interesting discussion, thanks for letting me know!