Resize images before running quanitizer, like the real Palette does.

[jariz]

Currently, the demo site is a pretty good example for this: if you change the size of your browser, the palette will change.
This is of course caused by the image size changing, and because of Vibrant not loading every single pixel (only the 5th, each time, by default, as configured by the quality parameter)

For more consistent results, Vibrant should resize the image to a default set max size before getting swatches from it.
Maybe even instead of grabbing every fifth pixel, it should grab every pixel when it's downscaled. (unless performance takes a hit)

Palette does this as well.

[akfish]

My past encounter with canvas seems to suggest that processing every pixels wouldn't be that bad, as long as you don't allocate tons of memories in the process.

I just created a benchmark for node-vibrant. You can run gulp benchmark and test for yourself. Here's my result:

[12:53:51] Requiring external module coffee-script/register
[12:53:52] Using gulpfile F:\dev\js\node-vibrant\gulpfile.coffee
[12:53:52] Starting 'benchmark'...
Src: ./test/**/*.benchmark.coffee
[12:53:52] Running suite node-vibrant colorCount benchmark (quality = 5) [F:\dev\js\node-vibrant\test\vibrant.color-coun
t.benchmark.coffee]...
[12:53:58]    Color count: 2 x 9.83 ops/sec ±2.67% (52 runs sampled)
[12:54:04]    Color count: 4 x 9.52 ops/sec ±1.02% (50 runs sampled)
[12:54:10]    Color count: 8 x 9.01 ops/sec ±1.39% (47 runs sampled)
[12:54:16]    Color count: 16 x 8.29 ops/sec ±0.95% (44 runs sampled)
[12:54:22]    Color count: 32 x 7.95 ops/sec ±0.85% (43 runs sampled)
[12:54:28]    Color count: 64 x 7.23 ops/sec ±2.17% (39 runs sampled)
[12:54:33]    Color count: 128 x 7.42 ops/sec ±1.00% (40 runs sampled)
[12:54:39]    Color count: 256 x 6.36 ops/sec ±2.54% (35 runs sampled)
[12:54:39] Fastest test is Color count: 2 at 1.03x faster than Color count: 4
[12:54:39] Running suite node-vibrant quality benchmark (colorCount = 64) [F:\dev\js\node-vibrant\test\vibrant.quality.b
enchmark.coffee]...
[12:54:46]    Quality: 1 x 3.11 ops/sec ±5.63% (20 runs sampled)
[12:54:53]    Quality: 2 x 3.53 ops/sec ±3.11% (22 runs sampled)
[12:54:59]    Quality: 3 x 3.95 ops/sec ±1.98% (24 runs sampled)
[12:55:05]    Quality: 4 x 4.29 ops/sec ±1.24% (26 runs sampled)
[12:55:12]    Quality: 5 x 4.44 ops/sec ±0.97% (26 runs sampled)
[12:55:18]    Quality: 6 x 4.55 ops/sec ±1.14% (27 runs sampled)
[12:55:24]    Quality: 7 x 4.60 ops/sec ±0.77% (27 runs sampled)
[12:55:30]    Quality: 8 x 4.59 ops/sec ±1.41% (27 runs sampled)
[12:55:30] Fastest tests are Quality: 7,Quality: 8 at 1.00x faster than Quality: 8
[12:55:30] Finished 'benchmark' after 1.63 min

The gist is that quality 8 is only 1.48x faster than quality 1 (btw, quality = 0 will cause an infinite loop, which is in the document and should be corrected). That's hardly a significant dent in performance.

Note that node-vibrant uses jimp to read pixels, which is a pure JS implementation. Modern browsers' canvas are backed by native code and should be even faster.

[jariz]

Thanks, I took the 'quality' stuff from ColorThief which stated that if you'd run it on 0 you'd get the highest quality. I'll correct it.
This issue still isn't solved by this though.

[akfish]

I see.
This line of code should be responsible for quality = 0 issue: https://github.com/jariz/vibrant.js/blob/master/src/Vibrant.coffee#L105

What I was trying to say is that you could just process the image at its original size and get consistent result right away and see if it's really worth the trouble of downsampling and stuff in browser environment. There're tons of canvas applications that process whole images without running into significant performance trouble.
After all the application for this is usually one time deal per image. No one expects to do it in real-time repeatedly like 60FPS or something.
And if it's really that slow, there's web worker too.

[akfish]

Fixed in node-vibrant