I've used this script for a while now, thanks a lot for this. I'm think I stumbled across something in regards to the conversion.
As it's a bit complicated I'll try to explain it:
Colors appear different in emulator: Recently I noticed that the colors in the emulator appear slightly different than in Aseprite (using your script). Looking at the script it appears it rounds everything to a palette entry ending with "0" for each rgb value:
0x00, 0x10, 0x20, 0x30... 0xE0, 0xFF << you can see here that there is a gap of 31 values at then end and 16 in between all others...
The emulator produces each entry mostly with the same hex digits for each tuple (using screenshots and Gimp to determine color values). So:
0x00, 0x11, 0x22, 0x33... 0xEE, 0xFF << here the gap is 17 between each color value.
why this can be an issue: The script currently adds 8 and then discards the lower nibble. I think the thresholds for each of the 16 values per color value needs to be different. Right now there is a big gap in the brighter colors, which leads to color bleeding towards the slightly dimmer ones.
Script algorithm changes: What I have done now is to change the script slightly and emit the above RGB values, so Gimp, Pro Motion, Aseprite etc. show the right colors (as the emulator would) and also use those for dithering. Of course VERA then can only use the upper 4 bits of each palette entry. Tools like Aloevera etc. take care of that. Using this delivered better results for me when working with large (320x240 - haha) bitmaps like I used in Brixx and Invaderz.
It probably doesn't matter that much for sprites and tiles etc.
I attach my (not very elegant) version of the script so you can see the difference.
12-bit Palette Quantize V2.lua