Didn't suggest it until now as I didn't know of an algorithm that could do it, but now I do. This would make it easier to get images into a format usable by NM since you wouldn't need to manually change colors.

1. First split image imported into 8x8 segments. A single NES tile can be only 8x8 so it's good.
2. Now, for each segment get the 4 most used colors and turn the other into them by choosing the one closest to it. So if a block has 6 colors, like 32,45,255 22,34,125 0,20,0 23,44,0 23,136,234 and 32,45,33 with first 4 being the most common, all 23,136,234 pixels would become 22,34,125 and all 32,45,33 pixels would become 23,44,0
3. Next, replace most common colors with the back/rgb to conform with the internal format.
4. Combine the blocks together again in the same order they were originally in, possibly with black being the color used in the top-left pixel.

Still would require some fiddling to get right , but not nearly as much as it does now.

My program I-CHR can already turn NES conforming background art into NES Maker's four color format, but I'm trying to get some sprite stuff done before I release the version that has the function.

It figures it out fully automatically. Gives you a palette, and a NES Maker BMP etc.
But it won't condense > 4 colors in a 16x16 pixel region into 4 colors, it will just mark the pixels that broke the rules. The reason for this is that even if you condense each region to four colors, there may still be way more than four palettes on screen. And condensing that while making it look good is harder automatically.

If the new I-CHR's not ready by August 8th I'll probably at least make a standalone tool that does things like this. It's definitely a thing I've thought a lot about.

You should check it in 8x8 chunks, that way you could also use it to convert spritesheets, not just screens. Or full-color rips from NES games.

Also you could try using the color conflating algorithm, that's how any sane program (MS Paint excluded) convert True Color (full RGB) images to 256 colors figuring out the best palette. Except you'd be converting to 4 colors.

Also this suggestion is rather for something to be built-in to the NM itself without a need of third-party tool.

Try building a version that uses my algorithm and see where it gets you. Most likely as said, user would still need to fiddle a bit with different blocks to get them right, but it would dramatically improve importing of high-color sprites that have too big amount of colors (for example SNES/Genesis/DOS VGA rips or already made art from an indie game that dev wants to make a NES port of, but graphics are too high def).

You should check it in 8x8 chunks, that way you could also use it to convert spritesheets, not just screens. Or full-color rips from NES games.

My tool can already import full color rips from NES games, even when they use sprite overlays. Here's Mega Man:
imported from this image sequence:

But how it works is not really NES Maker compatible.

A case that breaks your algorithm is when the transparent color is the least used color in the block, but still appears. It gets made into another, non transparent color, but that can be fixed by making the user explicitly tell the program which color is the transparent color and basically ignoring it in the algorithm. And as you mentioned, the top left pixel is usually a good bet to guess as the transparent one.

Assuming you reduce each 8x8 area to four colors while successfully preserving the transparent color, you're usually going to end up with a lot of unique sets of 4 colors. Getting them down to say... the two that are "best" is the bigger issue.

Here's a six color Sakura:
Here are the unique palettes each block would need using your algorithm.
(Maybe, I actually did this manually so it may contain errors.) With sprite overlays you need 2 sprite palettes to display this Sakura. How you choose affects sprite count, but not how it looks. The computer could try every combination and get the lowest number for sprite count.

With the block method, which two palettes you choose greatly affects how it'll look. The computer can try every combination, but can't judge which looks the best. I have some ideas about how to choose, but even the sprite palette guessing algorithm I wrote for sprite overlays ended up not getting the results I was trying to guide it to.

I think 4 colors usually ends up not looking bad, even for high color sprites. Here's 3rd Strike Chun Li:
Here's an automatically done 4 color 3rd Strike Chun Li on NES:
Anyway, I'll probably give a >4 color no overlay method a shot, but there are some other things that need to get cleaned up first.

edit: I do get you want this in NES Maker proper, rather than a third party tool, I just happen to have a lot of code for this sort of thing already.

A case that breaks your algorithm is when the transparent color is the least used color in the block, but still appears. It gets made into another, non transparent color, but that can be fixed by making the user explicitly tell the program which color is the transparent color and basically ignoring it in the algorithm. And as you mentioned, the top left pixel is usually a good bet to guess as the transparent one.

Yup, pretty much. And obviously my algorithm would be wrong on occasion, but it would also be right most of the time which would save tremendous amount of work for converting the sprites (even if they're high-color ones, such as SNES rips). The time the algorithm made a mistake it can be fixed manually. It wouldn't be often though.