Converting images into screen 2

Paladin (963)

12-02-2015, 13:42

Yzi, basically I create a virtual palette that includes original MSX colors and all permutations of two original MSX colors mixed in one (of course it'll not have 256 colors, since MSX has only 15 colors and this cross method would create duplicates). Then for each 8 pixels the program checks by brute force which 2 virtual colors will have the best quality conversion. Since these virtual colors are an average of two MSX real colors, the program has to plot them in interlaced lines. Suppose, that the best color is a mix of yellow (11) and white (15), so if it's an odd line, it'll use first color (11) and if it's an even line, it'll use second color (15).

IMHO, the quality is better because I used another approach to check the best colors (Not only an RGB cube), and I also added two control options, a luminosity factor so I can control how much luminosity will be considered instead of colors during conversion, and a interlace intensity, so I can decide how much the image will be interlaced (or not).

Oh, and finally, I cheated. I realized that you can make conversions to the MSX1 palette look much better if you first adjust the original image saturation and contrast (this last one, the more, the merrier).

Van erikd

Master (255)

12-02-2015, 21:12

Wow, pretty cool!

Van marcos.m.carvajal.1

Expert (85)

13-02-2015, 00:47

I'm just blown away. I can't stop thinking what would have happened if this images would have been seen in 1983

Van sd_snatcher

Prophet (3675)

13-02-2015, 02:32

Kudos for you! Those are very good results indeed.

But it seems that you're using the V9938 default palette, and IMHO for screen-2 images, the TMS9918 palette should be used by default.

Many of the palettes available online for the TMS9918 are incorrectly converted Component-Video to RGB by using simplified formulas. If it may help you, feel free to use the perfect TMS9918 palette I calculated using the BT.601 standard, and published here.

Van Marq

Champion (387)

13-02-2015, 08:29

In the end, some tweaking is always required for optimal results, I guess. Most notably zooming and placing the image horizontally so that it matches with the 8-pixel boundaries to avoid bleeding. Can't just expect to drop any image there and get good results.

Van hit9918

Prophet (2932)

13-02-2015, 14:26

I too like that more than dithered.
The dithered wonders mostly happen in a thumbnail on PC monitor, it is different when you see things zoomed out to fullscreen.
Cant use them as game tiles, they are like missing hires and they are dotish.
Title screens are less problematic than game tiles, still I am interested in something more hires.
And the linemixing is better on that.

@LeandroCorreia, another feature is to limit the mixcolors to pairs that got some given max brightness difference. Like having a slider for that.
And there are some colors that got zero brightness difference, limiting the mix to those one gets full hires.
And then on PAL cinch they make real new MSX1 colors.

the brightness value list
color Y (brightness)
1 0
4 0.40
6 0.47
C 0.47
2 0.53
5 0.53
8 0.53
D 0.53
3 0.67
9 0.67
7 0.73
A 0.73
B 0.80
E 0.80
F 1.00

Van hit9918

Prophet (2932)

13-02-2015, 15:40

@sd_snatcher,
Trying colors 9.8.6 from your list, they are less rose. It looks like palette isnt in newest openmsx build yet.
I turned gamma to 1.1 to make the look of TV. I forgot, is 1.1 the openmsx factory setting?
Does the console command reference maybe tell it wrong by 1/x?
One would have to snapshot from emu to get the gamma-ed palette for tools.

Van LeandroCorreia

Paladin (963)

13-02-2015, 17:26

@hit9918

I do agree with your comments, specially on dithered tiles, Digital Devil Story Megami Tensei is a good MSX example on that. The lines look great in a CRT TV.

And I have a parameter to control mix colors intensity as well. But not using brightness only. Actually the whole color checking is done in Lab model instead of RGB. The reason is simple: Color proximity inside a Lab model cube is much more similar to color similarity according to human vision than using RGB.

Van ARTRAG

Enlighted (6976)

13-02-2015, 20:38

LeandroCorreia wrote:

Meits, I'm programming it in Blitz Basic. It's a PC program, since an MSX would be TOO slow for that. Basically it loads an image and tries to create an MSX version of it.

Artrag, I know Jannone's converter. I think it's really impressive, but I don't like dithered images for MSX. IMHO, dithered images only look nice in higher resolutions. My converter tries to mimick new colors by interlacing lines. I thnik it looks better for low resolutions, specially if you're displaying it on an CRT TV.

Anyway, I'm more curious about your opinions on image quality.

Try to use as metric the perceptually uniform distance in the color space I used in my converter.
It is a variation of CIELAB.

Van Louthrax

Prophet (2496)

15-02-2015, 00:44

I must say this looks really awesome ! I was condering about the time it takes to convert an image, the brute-force conversion to test all 256*256 color combinations with non simple RGB-square-distance should take quite some time ?

I could be interested in porting that conversion method in MIFui (the tool has all code to import from PNG or JPEG, view the conversion result in "real-time", dialogs to set parameters...), not sure when I'll have time to do it. Or I could provide you the sources of MIFui if you need a GUI base (it's C and Win32).

Artrag, how complex is the "perceptually uniform distance" method you use ? I tried to use CIELAB, but the functions are really too complex (RGB to XYZ to CIELAB error using floats), and also it does not define a color-space (which could be usefull for dithering).