Testing Tursi's Convert9918 program

[Captain Cozmos]

Here are some various pics using Tursi's Convert 9918

 

Show him some love and encourage to continue the work

 

Here are 27 Cartridges created with his program.

Everything was pretty much drag and drop then select Colecovision rom to export

 

No one expects you to do anything other than drop them in an emulator to see the capabilities of the Colecovision and ADAM

If I had to pic the best one of the lot that shows off Coleco's colors it would be Colored Cubes.

 

Here is the latest version of Convert 9918.

Convert9918.zip

 

github:

https://github.com/tursilion/convert9918

Harmless Lion website:

https://harmlesslion.com/software/convert9918/

 

BTW, some of these pics are off the net.  The rest are from my personal photo album.
I am not taking credit other than I did the conversion.

Picture Carts.zip

Edited December 28, 2023 by Captain Cozmos

[jblenkle]

Huh, imagine that! I've been using this program for quite awhile to construct my ADAM Multimedia Disks and I never noticed there was an option to save the pictures in a .ROM format.

[Captain Cozmos]

2 hours ago, jblenkle said:

Huh, imagine that! I've been using this program for quite awhile to construct my ADAM Multimedia Disks and I never noticed there was an option to save the pictures in a .ROM format.

I'm glad it's there because I can extract the data directly in Assembly DB format using my disassembler.

 

So, any picture that this thing can handle I can put it on any game or piece of software.

[Tursi]

Glad you are enjoying. Some tips for getting the most out of it. This will be a long post:

 

It's more art than science, but if you really want to push an image, this is what I'll go through. After every step you have to click 'reload' to see the changes, cause it's not quite fast enough yet. It's on my todo list to learn GPU programming and see if that'll help.

 

First look at your "fill mode" dropdown. 'Default' fits the entire image -- which usually means you end up with black bars that waste space. We don't have very many pixels - every one counts.

So use Top/Left, Middle, or Bottom/Right if you can. (This just changes where the cropping is focused - for most images, Middle is good. For portraits you might prefer Top/Left).

 

The Scaling Filter is rarely changed. I use 'Box' for most images as it's pretty sharp. But if you have a pic with a lot of noise, try 'Gaussian' to smooth it out a bit.

Make sure Error Mode is set to "Accumulate". "Average" is a legacy setting from the early days and loses color information.

Next you want to choose a Dithering system. You can ignore the PIX values - they show you what the actual distribution of error will be and can be used to make custom dithers, but not going to cover that here. The buttons beside it are where we are going:

 

Atkinson - this reduces how much error is distributed and usually results in good color reproduction and good sharpness, it's sort of a middle ground. All the above is Atkinson.

Floyd-Stein - The classic dither. This results is very good color reproduction but typically the images are very noisy.

Pattern - This was my first attempt at an ordered dither, but it's really closer to "every other pixel". Legacy dither.

Diag was a random dither I liked the result in on some pics, an attempt at crosshatch shading:

Order 1, 2, 3 and 4 are ordered dithers, meaning the pixel color is position dependent. This makes it the ideal choice for animation (all of my Dragon's Lair used Order 4). The differences are that 1 and 3 are true ordered dithers with 2 or 4 levels respectively. Order 2 and 4 expands the dither to its left with limited error distribution to improve colors. Usually I'll use Order 4, but sometimes the simpler patterns in 2 looks better. Ordered results in a brightness shift most of the time, and the slider to the right aims to offset how much. I usually keep it about one tick above center, as in the pic. (Due to a bug, you can only move it when Order 1 or 3 is selected, but it affects all four).

(Brighter and darker Order 4):

And of course None is no dither. This is helpful if you need to compress the image.

Almost done. Luma emphasis tells the converter how important brightness is relative to color. Since we have a limited palette, there's got to be tradeoffs made, and increased brightness importance can result in a sharper image at the cost of color shift, or vice versa. 100 means 100% equal. Lower values means color is more important. Higher values means brightness is. I normally run about 120% Luma emphasis. Back to Atkinson dither on this samples:

Gamma correct applies a gamma change, but you can largely treat it as a master brightness/contrast adjust. 100 means no change. I usually run about 80.

The shift buttons aim to align the image, in particular with the 8 pixel horizontal limits... but honestly I almost never touch them anymore. However, right beside them are three 'quick sets'.

 

Toon attempts to map the colors closer to the real palette and reduce dither, at the expense of color shift. You would normally only use this with no dither:

Hist stretches the color histogram, which can result in dramatic contrast enhancement. It's not needed very often anymore (and indeed didn't do much here):

Perc switches the color matching from YUV to RGB Perceptual. Again, this is an old setting not needed much anymore, but the idea is to emphasize green and de-emphasize blue. When you select it, the Luma box will grey out, and the Perceptual Ratio boxes are enabled - they are pre-loaded with the standard RGB-to-brightness values. It tends to have less contrast but the colors may be more appealing.

As a last resort - "Max Color Shift" controls how far the pre-processor is allowed to shift the original colors towards the palette before converting. A larger value can result in less dithering, though color shift will occur. I usually keep it at 5% as in these examples. 100% will go all the way to the palette colors, so keep changes small. Here's 0% and 20%.

Last but not least, the dropdown at the bottom has a few other modes, including a couple of F18A modes:

 

Grayscale (requires color table, even though there is only black, white and grey): (hmmm.... striking this. There might be something wrong with it. The preview has way too many grays in it...)

 

B&W - pattern table only:

Multicolor 64x48 -- yeah, this rarely works well.

Dual-multicolor expects you to flicker two multicolor images, and gives more colors. I don't feel flicker modes work well on modern displays, though, they really need a CRT:

Half-multicolor flickers a multicolor image with a bitmap image to give full screen improved colors. Same caveats apply. Both flicker modes enable a "Flicker Max Difference" on the left to let you control how blatent the flicker is (for instance, flickering black and white doesn't really give you grey, it just gives you a headache 😞

Bitmap color only outputs only the color table, assuming the pattern table is filled with 0xF0. This gives a 64x192 resolution. I envisioned this for some projects that didn't pan out.

Paletted Bitmap F18A generates a custom 16 color palette to go with the standard bitmap image for the F18A. You can toggle the color selection mode at the left between Median Cut (generates a palette of averages) and Popularity (uses the most popular colors - good if you don't have too many):

And finally Scanline Palette Bitmap F18A generates a new palette for every single scanline. A GPU program is included for the F18A so this mode can be displayed with no CPU intervention, though of course it uses nearly all the VDP RAM (there's a tiny bit left for a few sprites). It actually takes 16.5k for the image, but the GPU program tucks most of the color data into it's dedicated 2k RAM space, leaving enough room for the tables. You can set the 'per-scanline static color count' to force a few most popular colors to stay the same across the screen to reduce streaking, if necessary.

I should note too that earlier this year a fellow cloned my program. On some images his dithers look better, but I haven't dug too deeply into it. His thread is here: 

 

 

 

 

Edited December 29, 2023 by Tursi

[Tursi]

I also just remembered what's up with grayscale... it's been so long since I did it. It treats the palette as grayscale, so yes, it has many grays. But, you can only really view the resulting image on a black and white display. More of a 'might have been' than a modern useful feature...

 

[jblenkle]

Wow, thanks for all the examples and explanations. For converting pictures to ADAM PowerPaint your program is a lot better and easier to use than the old BMP2PP I used on my early ADAM Multimedia Disks.

[Falonn]

This is a great tool, @Tursi, thanks for sharing it with the community!

 

Two colors per 8 horizontal pixels in bitmap mode is a harsh limitation.  I wonder if there would be any value in trying to minimize error by performing the dither eight separate times, shifting the input image one pixel horizontally each time?  You could keep track of some total error metric for each version and choose the one that did the best.

 

It would also be neat to be able to offer up some variable number of sprites to spot-correct the highest error areas remaining in the image after the initial conversion!

 

I tried to build it from source, but it appears there is some dependency on a closed-source library that doesn't seem to exist anymore?  Outside of IS40_BrightnessHistogramEqualizeImage, it looks like it wouldn't take too much effort to migrate from ImgSource over to the stb_image* single-header/public-domain libraries.

[Tursi]

5 hours ago, Falonn said:

This is a great tool, @Tursi, thanks for sharing it with the community!

 

Two colors per 8 horizontal pixels in bitmap mode is a harsh limitation.  I wonder if there would be any value in trying to minimize error by performing the dither eight separate times, shifting the input image one pixel horizontally each time?  You could keep track of some total error metric for each version and choose the one that did the best.

 

It would also be neat to be able to offer up some variable number of sprites to spot-correct the highest error areas remaining in the image after the initial conversion!

 

I tried to build it from source, but it appears there is some dependency on a closed-source library that doesn't seem to exist anymore?  Outside of IS40_BrightnessHistogramEqualizeImage, it looks like it wouldn't take too much effort to migrate from ImgSource over to the stb_image* single-header/public-domain libraries.

There might be some value in auto-shifting, but frankly it's rare that I get an output that I'm unhappy with due to the clash. It works on brute-force as it is, trying every possible combination at each position (so all the settings just affect the fitness routines). It actually has a secret mode that I used to just browse images at random - double-click anywhere there is NOT a button, and 'OPEN' will turn into 'NEXT'. Click it, and select a file in the root of your images folder (if you have no files there, you can make one up, the filename itself is ignored). It will randomly select and covert a file every time you click 'Next'. It will also randomly convert any image you copy to your clipboard. And the ultimate - you can open multiple copies, put them all in 'NEXT' mode, and they will sync loads. I use this to compare settings.

 

Yeeeah... I never really intended anyone to build it, and ImgSource is long dead. The histogram function is only used for the Hist button, and while I do still sometimes use it, the gamma adjust can usually do a better (and finer grained) job. So losing that wouldn't hurt my feelings.

 

Agreed it shouldn't take much to move it, and I've thought about it, but, I don't really need to so that has impacted it. I've also thought about re-writing it cause the code is loaded with over a decade of hacks and experimentation and likely runs a lot slower than it needs to. In general, for a good ten years I've been the only one seriously using it that I know of, so never worried much about it being pretty.

 

Nice to see a recommendation for the STB stuff, though, I like those single-header libs. That would definitely be the direction to go.