I essentially do
this in my own Calibre build (i.e., literally calling ImageMagick, instead of relying on what Calibre has to offer like in the patch I linked to earlier. It's not portable for shit, but it works ;p).
(On the off-chance you're using Gentoo, that version of the patch is in my
Portage overlay. The patch will need to be personalized, because it's using a hardcoded path to the palette

).
If you're in a hurry, and/or don't want to bother with expensive rescaling/letterboxing, and slightly more expensive error diffusion dithering, ImageMagick's
-ordered-dither o8x8,16 also does wonders, and it's dirt cheap compared to what both my examples do

.
And thanks to the magic of maths, it outputs stuff in the right palette without needing an explicit remap (as the palette is evenly spaced, and 255 / (16-1) == 17, meaning 0x11 in hex, which is exactly the gap between colors in the 4bpp grayscale palette used on eInk).
(Yes, it worked so well that I may have
spent a bit of time porting it to FBInk recently

).
Keep in mind that you'll probably have to reboot for Nickel to pick up changes made to cover thumbnails behind its back.
There's also a possibility what you're seeing is an eInk refresh artifact based on the way Nickel shows sleep screen covers, which, on my devices is: show the image, then refresh the image again with a flash. (At least when NOT using the option that shows the "Sleeping" tag. I have no idea how this might affect the whole process, so disabling that may also be one thing to try).
That's less optimal than flashing a white screen, then flashing the image.
(In fact, with certain patterns, it can lead to hilariously bad results).