ham_convert 0.5

A new version with a lot of improvements and new features is ready. This program doesn’t use any external libraries, just pure jdk.

ham_convert 0.5

ham_convert 0.5

Get it here:
ham_convert_0.5.zip
Mirror (all versions)

Changelog:

  • Added a simple build-in palette generator to produce a better base palette for HAM8 conversion.
  • Added a new 256-color mode, which converts the image to a normal indexed 256-color mode.
  • Floyd–Steinberg dithering can be used with the 256-color mode.
  • Added an option to load a 256-color palette from a file in the JASC pal format (256 colours are used in 256-color mode, HAM8 uses only the first 64 colours). This option enables the user to load an optimized 64-color palette to greatly improve the quality of the HAM8 conversion. External programs (like IrfanView) have much better colour reduction algorithms than the build-in one. If you want a high-quality HAM8, you can reduce the number of colours of your image to 64 in IrfanView using the new high-quality option, export the resulting 64-color palette to a file and load to it my program.
  • Improved the user interface.
  • Fixed some bugs.

There are some sample palettes included: Amstrad CPC, Apple II, Atari 2600, Atari 8-bit, Commodore 16/Plus4, Commodore 64, Commodore 64 DTV, Commodore VIC20, CGA, Grayscale (4-bit), NES, RGB222 (EGA), RGB332 (MSX2), SAM Coupé, ZX Spectrum.
These palettes when used in 256-color mode with enabled dithering could be used to approximate the graphic capabilities of these old computers (with the exception of the colour restrictions often present in their screen modes).
I’ve posted a few test pictures below (dithering was enabled in 256-color mode).

Base image

Base image

ham_convert 0.4

ham_convert 0.4

ham_convert 0.5 (HAM8 mode, internal palette generator)

ham_convert 0.5 (HAM8 mode, internal palette generator)

ham_convert 0.5 (HAM8 mode, external palette generated by the IrfanView)

ham_convert 0.5 (HAM8 mode, external palette generated by the IrfanView)

ham_convert 0.5 (256-color mode, external C64 palette)

ham_convert 0.5 (256-color mode, external C64 palette)

ham_convert 0.5 (256-color mode, external NES palette)

ham_convert 0.5 (256-color mode, external NES palette)

ham_convert 0.5 (256-color mode, external Atari 800XL palette)

ham_convert 0.5 (256-color mode, external Atari 800XL palette)

5 thoughts on “ham_convert 0.5

  1. Any chance of an “tweaked” ham8 mode? I’m just curious to see how much (if any) quality improvement could have been made by the AGA chip-set designers. Instead of using the normal ham8 ,optimized palette and 6-bit MSB values, why not use a 6-bit, 64 colour palette and use the 6-bit LSB values instead. Should give much smoother transitions etc.. Almost like real 24-bit. 😉

      • This “tweaked” ham8 mode concept is fundamentally incorrect because errors in the MSB are the most visible. My initial tests show that with an optimized palette there is almost no banding on smooth gradients but small details have more artefacts than normal ham8. When I used an unoptimized 6-bit RGB palette the output image looked like a total garbage, because errors in the MSB were copied across the line. I’ve also tested a HAM10 and it looked nearly identical to the original image and there were smooth gradients and almost no visible artefacts.

Leave a Reply to Kef Emzy Cancel reply

Your email address will not be published. Required fields are marked *