Enhanced decoding of YJK images

Pagina 2/5
1 | | 3 | 4 | 5

Van hit9918

Prophet (2903)

afbeelding van hit9918

12-03-2013, 10:33

I too was thinking of the screen 12 converter side.
Edwin mentioned a "standard algorithm", anything else ever been done?
Maybe screen 12 can do better. Then you wont miss the TV signal smear.

I made a BASIC program to look at the screen 12 colors (run it in emulator with max speed).
The demo does increase Y in a line from left to right.
That "Y" of YJK is not a real brightness value.
"jaggies of the red hat picture", a slide from bright red to black does not exist,
a compromise could slide magenta to black - more color error, but less brightness error, maybe less harsh to the eye.

A converter could have a slider to tune the compromise of brightness correctness versus color correctness.
Further one could try 4 sliders for the 4 pixels of a block to emphasize their error value in that JK search.
Putting middle sliders to "0" emphasize and border pixels to "1" emphasize, maybe this decreases the jaggies further.

10 color ,0,0 : screen 11

100 for j = 0 to 7
101 for jl = 0 to 7 step 4

110 for k = 0 to 7
111 for kl = 0 to 7 step 2

115 for y = 0 to 15 step 4

120 vpoke n+y+0,(y+0)*16+kl
130 vpoke n+y+1,(y+1)*16+k
140 vpoke n+y+2,(y+2)*16+jl
150 vpoke n+y+3,(y+3)*16+j

200 next y
260 n = n + 512 'n = n + 256 to remove black lines
261 if n >= (256*128) then n = n - (256*128) + 2*16
300 next kl,k,jl,j

1000 goto 1000

Van sd_snatcher

Prophet (3450)

afbeelding van sd_snatcher

25-08-2013, 17:56


Yes, the Y isn't just a brightness level. If you look at the YJK formula, you'll notice that it contains the blue level of the image too.

Now I did some tests on the encoder side and it's possible to encode the images while smoothing the jaggies. But:

1) The encoder can't completely eliminate the jaggies, because the whole system relies on chroma interpolation being done on the decoder side

2) It will always result in reducing the number of colors contained in an image. The worst the jaggies are, more you have to reduce the color count:

This is the resulting digital color count for some of the images shown in this thread when preprocessed to reduce the jaggies:

- Gulliver: Felt from 3830 colors to 3329 colors
- Haruko: Felt from 2667 colors to 2381 colors
- Lena: Felt from 1280 to 1245 colors

One important aspect is that the worst the decoder is, the more you have to chew colors on the encoder to reduce the jaggies that it will produce. This is why it's important to have a proper decoder that supports chroma reconstruction.

I'm planning to write an article on the MSX-wiki explaining the findings and the algorithms.

Note: The V9958 YJK decoding design strongly remembers me the way that the YM2413 mixes all channels using an analog filter instead of a digital sum like all other OPLx chips do (so the design can be made cheaper). The current level of YJK emulation can be compared to emulate the YM2413 without the analog mixing filter. Of course emulators this days do the mixing in a more elegant way that result in a much sharper/pleasant sound. The same approach could be done for the V9958.


You're right that there are not too much MSX2+ software. But hey! There's still Graph Saurus, Quinpl, Nyancle Race, Golvellius-2, etc. And most of us have hundreds of SCR12 files that look horrible when loaded in any emulator, while they look smooth and beautiful when I load them on my real MSX using the s-video connection. Smile

The approach can be made much simpler than including the whole NTSC emulator in openMSX. All that would be needed is to replace the current Nearest-neighbor interpolation done when decoding the JK values with the Lanczos3 interpolation. This is simpler to do than the NTSC emulator and will output much better results. If you want it to be more flexible, you can add a way to select the interpolation algorithm to be used there:

set yjk_chroma_interpolation nearest-neighbor
set yjk_chroma_interpolation bicubic
set yjk_chroma_interpolation Lanczos3

Van igal

Master (215)

afbeelding van igal

04-11-2013, 15:39

Very interesting.

I tried on a Gulliver.SCC NMS8280 on different outputs native MSX.
The MSX has an S-VIDEO output (modded by Hans Otten??).

I have noticed that the improvement curve "Red" is made only 60Hz and not 50Hz.

Rca-Luminance Only 60Hz:

Rca-Luminance Only 50Hz:

Rca-Composite 60Hz:

Rca-Composite 50Hz: (No improvement)

Rgb-Scart 60Hz:

Rgb-Scart 50Hz:(The curves are uglier than RGB 60Hz)

S-Video Luminance Only 60Hz:

S-Video Luminance Only 50Hz: (irregular curves red right hat.)

S-Vidéo 60Hz:

S-Vidéo 50Hz:

Van sd_snatcher

Prophet (3450)

afbeelding van sd_snatcher

04-11-2013, 23:09

Interesting! Somehow your TV set seems to use different chroma filters for 60Hz and 50Hz.

What color system does your NMS-8280 outputs? Is it PAL or SECAM? Because YJK is designed to work closely with the NTSC chroma filters, and those will do the proper chroma reconstruction. When the output is done in PAL, my guess is:

- Reddish colors will be interpolated correctly
- Blueish colors will be interpolated so-so.
- Greenish colors will be badly interpolated

I think this is why the V9990 has both modes available, YJK and YUV, using exactly the same kind of encoding, but with green and blue swapped. The YJK is meant to be used on NTSC TV sets, while the YUV does exactly the same trick for PAL TV sets. Cross using on system one another will result in sub-optimal chroma reconstruction.

But SECAM is a completely different beast from NTSC and PAL. Probably YJK chroma information will be very poorly reconstructed with it. V9990's YUV modes may perform a bit better, but still quite sub-optimal.

Van igal

Master (215)

afbeelding van igal

05-11-2013, 15:00

Hi Sd_snatcher. All the old tests were done with the original setting of NMS8280 in PAL.

Here is the result:
Rca Composite 60Hz Secam:

S-video 60Hz Secam:

Rgb-Scart 60Hz Secam:

I think all European MSX are in PAL.
If we switches to SECAM with [OUT&HF6,235], we always get the "Black and white" image. (The Chroma was lost!?!?)
The same tested SECAM with [Luminance Button MSX] pressed give the strictly the same results.

Nb:In France, in the past, wee need add an [Secam To Pal Transcoder] for Digitize with color in MSX : X
For some years, all video equipment are in Pal/Secam compatible.

A small program to show the behavior of the TV according to the selected connection:

20 VDP(10)=0:SCREEN0,,,,,1
40 CLS:SET ADJUST(6,3):COLOR ,,0:OUT&HF6,251:SCREEN12,,,,,1:' PAL
60 VDP(10)=1:VDP(10)=4:GOTO60
80 CLS:SET ADJUST(6,3):COLOR ,,0:OUT&HF6,235:SCREEN12,,,,,1:'SECAM
100 VDP(10)=1:VDP(10)=4:GOTO100
110 VDP(10)=0:SCREEN0,,,,,1

S-Vidéo Filters transitions Pal appearance:
Nb:See the Red color of hat the beginning of the video
In Secam, the Image it's in black and white.

Van Metalion

Paragon (1384)

afbeelding van Metalion

05-11-2013, 14:44

For your information, when the image is transmitted through the RGB cables, NO color coding standard is needed. So there is no "RGB SECAM" or "RGB NTSC", it's just RGB.

Van sd_snatcher

Prophet (3450)

afbeelding van sd_snatcher

07-11-2013, 02:39


F6h I/O port? That's weird! Smile

I mean, according to The MSX Assembly Page, this port should be reserved for the "color bus I/O" (which I never seem). Are you sure it isn't F7h or F8h? Those two ports are the ones that should be used for the A/V controller...

Van igal

Master (215)

afbeelding van igal

07-11-2013, 15:18

Hi Sd_Snatcher:

I applied OUT & HF6, 235 (SECAM) and OUT & HF6, 251 (PAL) following the instructions of Jipe. (Sorry, my knowledge is really limited)

Maybe OUT & HF6, 235 can scan Secam precisely because VDP wait only luminance and not the Chrominance. Unfortunately, I do not have Secam drive for testing.

Anyway, we see that there is an RGB (OUT) different rendering!
Nb: I never digitized this image. Just displayed your images on the screen with differents parameters.

PAL 60Hz (Out & HF6, 251)

Secam 60Hz (OUT & HF6, 235)

The image rendering Secam 60Hz is as bad as PAL 50Hz.
PAL 50Hz (OUT & HF6, 251)

Van hit9918

Prophet (2903)

afbeelding van hit9918

10-11-2013, 08:54

I wrote a "no jaggies screen12 converter" Big smile

Get it at

Well cant promise that for all images, but the red hat is improved. And lenna actually is no problem.
I didn't have the original of the red hat, but relatively well got on a sharp RGB monitor (emu)
the pic of an MSX displaying the pic on TV :)

I build the color for a block by mixing in left and right neighbour blocks.
In "convertblock2()" in the source I sum the rgb of pixels including neighbour blocks.
(there is lots other code in the file that is not active, that was other attempts).

But when removing the mixing, I still dont get the whole-screen-striping of the lenna pic.
That seems to have another problem, maybe in searching the Y.

Van hit9918

Prophet (2903)

afbeelding van hit9918

10-11-2013, 18:57

I uploaded a new version

Now with a commandline parameter the amount of mixing can be tuned.

Pagina 2/5
1 | | 3 | 4 | 5