Must the code fit the exact size of the formatting, or just follow that pattern, regardless of size of code? This should be specified in the description.

There should be sample tests provided. We shouldn't have to attempt the kata just to see the fixed tests again.

This kata needs updating to Node 18.x; it is one of three left in Node 12.x. Automatic updating was unsuccessful.

Author, please update your kata, or unpublish it, or it might be unpublished for you.

Node version needs updating from 10.x.

So we have 4 kB to compress 768 kB into ( not even ) 1 kB.

With really random input data as the 768 kB, this is theoretically impossible. You just can't fit that much entropy in there.

If it were less ridiculous, I might try to see how far I got, but with this required compression, I have just one question:

WTF?

What am I ( or what are you ) missing here?

This came from your random tests as the expected output. Is that really correct?

your images are in jpeg, with highly arguable rescaling operations => there are antialiasing effects on the borders of the squares, meaning it's close to impossible to actually know what the true shapes are at each size. To resolve this:

1. use png, instead of jpg (or any other uncompressed format)
2. generate the images based on the output of your function, so that we can see the exact expected behaviour.

Note: last point is not enough to close the issue below.

Note²: same problem in the other version, ofc.

Kata requires rounding of floating point values but does not test with a margin for error.

Kata requires rounding of floating point values but does not test with a margin for error.

A few things:

• The draw function is very cool.
• The expected output was a little confusing at first. You might want to change 'create a general solution that will give the expected image' to something like 'create a general solution that will return the data of the following image'
• You may want to also note that the colours must not only be 'truthy/falsy' but will be treated as booleans. After all, the standard RGB range 0-255 are all truthy and falsy numbers in JS too.

It certainly looks like a daunting task but I will give it a go.

A lot more "hints" would be nice, and would not detract from the kata.

Is that horizontal single pixel black line in the middle always there, or does it somehow scale with the image? Same for the vertical half white line.

Why isn't there purple in the dithered red and blue part? The colour encoding could handle that, no?

Will tests with different sizes compare for actual equality with a reference picture? Ie, will we have to reverse engineer any idiosyncrasies the reference solution might have ( and I can see a few in the dithering ) ? Or will it somehow test for average colours in regions? The latter would be interesting, the former - H3LL NO, that's just masochism ( on solver's part, and sadism on yours ).