That sounds neat. I use Painshop Pro and it allows you to view the number of Used colors in the image, and afterwards you can reduce by using it's Reduce Color Depth X Colors and manually type the number of colors. This of course does not remove the duplicate colors.

As far a grids go my Graphics editor,which is a Sprite editor called Character Maker 1999 which allows you to set a brush size grid and can stamp them over and over until you right click another tile. As perhaps the way Mario Pain does it. Seems if i load the image i just saved out with character Maker into PSP then only resave the image, the image actually gets smaller just by doing that.

You seem confused about colours. PSP will count the number of unique colours in the image. If you reduce it to some smaller number, you are throwing away some of the colour information. This might be an acceptable tradeoff in some situations but for game mapping it certainly is not.

As for reducing the file size by resaving in a different program: that's hardly surprising, but you will still get significant improvements by using a dedicated compressor like PNGOUT/PNGGauntlet, compared with pretty much any image editor's compression routines.

PSP(7) can do a passable version of "tile stamp mode" if you turn on the grid and snap to grid. Its texture fill mode also gives you a "stamp flood fill" feature which I find extremely handy.

The slicer/splicer can be useful, especially for finding mistakes, but I find the sheer volume of tiles hard to manage; a GUI might help there.

Indeed. That's one of the major features I plan on implementing. It will shade the image according to tile frequency, so the uncommon ones will stand out.

That sounds incredibly awesome. I've had to work with hundreds of tiles before.

(When I was making the Star Trek To Star Wars wallpaper images, I ran the splicer/slicer on the one I made for 800 x 600. It didn't work because 600 isn't a multiple of 16, so I changed it to 800 x 608. It came out to exactly 1000 tiles...neat! A coincidence, that. Though that wasn't the same situation as a game map (i.e. not made of repeated tiles).)

The slicer/splicer was instrumental in making the Super Kid Icarus maps, as I mentioned before, probably, and I also used your slicer/splicer to check for errors when making the Oracle Of Hours maps. I didn't make too many errors, but it allowed me to find the few I did. I think I did really well for not working with a grid, but nobody's perfect. But thanks to the slicer/splicer, my maps are!

You seem confused about colours. PSP will count the number of unique colours in the image. If you reduce it to some smaller number, you are throwing away some of the colour information. This might be an acceptable tradeoff in some situations but for game mapping it certainly is not.

An inefficient paletted image might have "duplicate colours" in its palette, but it's not hard to avoid that; just convert to true colour and back to paletted, or use PNGOUT.

As for reducing the file size by resaving in a different program: that's hardly surprising, but you will still get significant improvements by using a dedicated compressor like PNGOUT/PNGGauntlet, compared with pretty much any image editor's compression routines.

PSP(7) can do a passable version of "tile stamp mode" if you turn on the grid and snap to grid. Its texture fill mode also gives you a "stamp flood fill" feature which I find extremely handy.

I'm not confused really. Before I reduce the colors I always have to change to a high color mode before reducing the palette back anyway and when reducing after, no colors are lost, only the unique colors are left which are the only colors in the original palette of the image. I've never seen a difference with 256 color images when I have done that. I never argue when reducing high color images to 8 bit. If the image uses more than 256 colors I never reduce them.

I haven't used the grid, tile stamp mode with psp. It's much quicker with Character maker not having to past in each new stampable tile and stamp it.

For the few maps I've done so far, I find Python and the struct module are invaluable for decoding old DOS formats, so long as you can find documentation for the format in question. Combine that with the Python Imaging Library (PIL), and you can load RAW images, create images programatically, then save the result.

For the less hacking inclined, ImageMagick is awesome for automatically stitching, cropping, converting, resizing a bunch of images (and more!).

Since this program doesn't handle jpg files, I use jstrip first, then convert them to png with pnggauntlet & finally use pngoptimizer on them. I find pngoptimizer to be much faster than pnggauntlet.

Why are you converting JPG to PNG? JPEG compression causes a loss in image quality that is fine for photo-realistic images, but not lower-color graphics (like most of the images here at VGMaps). And for photo-realistic images, JPEG compression is probably going to beat out PNG most of the time.

Most of the files are in .png format anyways. Also, I prefer these tools even though they convert to png, pngoptimizer does it automatically anways.... and it sends gif files to .apng format.

If WebP had a GUI for windows, then I would definitely be looking forward to that. I have found some converters that do convert to webp format, albeit an earlier version of webp before google optimized it later on for better file size & quality. If I could find a webp converter to the updated webp image format, I'd love to try that out.

I've been checking out jpegmini. If you use the desktop app you can do 20 jpegs a day with the free version. However you can also register and upload jpeg files to a album after you zip them. That will put them in the server quo to be crushed, you can download the crushed images after it's done too. So far it looks pretty good. I'm considering upgrading for $20, however... it's limited to 28 MegaPixels unless you plop down $150... in which case it can handle up to 50 MegaPixels...

So long as you apply this before stitching maps together it should be a very valuable tool indeed!

PNG is lossless, JPEG is compressed. Basically once you get something to the JPEG format, it's already distorted (even if very slightly), changing it back to a PNG isn't going to help.

As an example, load up nearly any map from the 8-bit or 16-bit era in your favourite image editor. Do a colour count. Likely it's going to be under 256 colours. Now save it as a JPEG. Reload it, count the colours. It's probably now a lot more. Save it as a PNG. It's going to have the same number of colours as the JPEG. Blecch.

When assembling maps, stick to lossless formats all the time. Like PNG. Or GIF if it's under 256 colours, but in nearly all cases PNG will be smaller.

Well it's been slow in this topic but I may have found something useful. Here is a web page based BG ripping tool that can extract a full BG from any or almost any Zsnes, Vba or Gens save state. I've used it some with Castle of Illusion and it really does get you the BG. It's cool. I think it will mostly work best with side scrollers or any game that has a parallax scrolling BG.

You'll need to save state in game where the BG is currently on screen, then upload the save state and click begin. The next page will take you to the extracted image. From here you can then copy the image to get it.https://floating.muncher.se/bgrip/bgripper.php