Enhanced mode 1 pictures

[davidb]

I've invaded a number of other threads with this effort, so I've started a new thread for the inevitable picture disks I'm creating as the image conversion tools are slowly improved. I still haven't seen an image that really shows off this trick. Maybe on the next disk...

[aerworuld]

Very nice!

[davidb]

Thanks, Stuart!

[sPhilMainwaring]

So is this MODE 2 colours at MODE 1 resolution?

[steve3000]

Looks like changing the 4 colours in use for each line? (from the 8 colour palette)

Looks good!

How do you do your image palette conversion/optimisation?

[davidb]

The picture viewer displays 4 colours out of the standard palette of 8 per scanline. Colour choice is done using one of two different tools: one is very simple and just aims for the nearest colour in the standard palette, with a bit of bias towards certain colours; the other tries harder to choose colours or combinations of colours that match those in the original image.

Certainly, better schemes are possible. It might be interesting to treat alternate scanlines slightly differently, to allow complementary colours to be chosen. It would also be good to replace individual pixels of a colour outside the 4 colour palette with those of the nearest colour in the palette; for example, in a black-red-yellow-green palette, replacing magenta pixels with red ones and cyan pixels with green.

In the end, some artistic license is required to make the most of existing images. If you were to create images from scratch in a pixel editor, you could be even more creative.

[tricky]

I have some work to do on my Floyd–Steinberg dithering, but hopefully you get the idea.

I only allow one colour change per line, but could probably manage 2 even with a full width image.
The final image is what you would get choosing only four colours for the whole screen with the BBC Micro Image converter (which I really like). I hope the author Francis? adds support for this method of converting images. EDIT: added PSU picture, still only changing 1 colour per line.

[davidb]

Those look very good indeed, tricky!

Meanwhile, I went through a lot of photos looking for ones that look OK after being converted with the current tools I'm using and compiled another disk.





The third one is interesting because it naturally exhibits the kind of alternating scanline colours that I mentioned above, doing green then cyan in some areas. It's remarkable that certain colours only appear on certain scanlines, giving the impression that there are more than four colours in use on any particular horizontal line!

[danielj]

Very impressed with all of these!

d.

[davidb]

Thanks, Daniel.

It would be interesting to play with dithering and error diffusion techniques for mode 0 images. The same code works for these, too, it's just that you need to encode the images differently for display in that mode and write the appropriate palette register values to memory for the display routine to retrieve.

[tricky]

I was thinking about mode 0 and it is a shame that the extra resolution is horizontal.
I think partial palette programming might work well in mode 0, but I don't think my image foo is up to it-it is about equal to my music foo

[tricky]

I was just doing the maths (finally) and I think you are correct, on the beeb you can change all four colours with I think only a maximum of two pixels the wrong colour and by carefully choosing the order of palette programming, that can be avoided, or I guess just by not using the last colour to be programmed in the first two pixels of a line, which of course it easy

[oss003]

WOW ..... very impressive guys

Can't wait to see a MODE 0 picture in colour.

Greetings
Kees

[tricky]

Sorry, got my maths wrong!
There is actually time to reprogram TWO colours per scan line, which is a blow as I have just finished converting my converter to four colours per line!
I'll code the converter and displayer tomorrow and post some more images, maybe even an ssd.

[davidb]

Just looking at this briefly this evening as paulb has been working on an improved version of his conversion tool. It all looks very promising. I'm not very optimistic about pictures in mode 0, but you never know what surprises may await us if we run the tools over enough images.

[paulb]

Playing around with some sample images...



This one I modified to add extra colours:



I'm sure I could be doing the dithering a lot more thoroughly, but the images convert a lot better than they used to with my previously over-thought (but not as good) conversion algorithm.

[tricky]

Here is a two colour change per line parrot. The first image is the original, then what it should look like on the beeb, finally, what it looks like in b-Em/beebem - I have a bug at the top. I have also attached a zip with the .ssd (I haven't tried it on a real beeb yet).PS I should have turned the cursor off in LOADER.

[davidb]

Looking good!

[tricky]

Here is a disk with timing tweaked for a real beeb, it cycles through a few sample images. Please let me know if it flickers.
There are still some bugs in the converter, mostly at the top of the images, and the algorithm has plenty of room for improvement, but it does show that swapping two colours per line does work.
The LOADER program sets the horizontal sync pulse width to 9 as my main LCD won't sync on 8 - delete VDU 23,3 if it causes you problems.

[jbnbeeb]

Will try on a real beeb this wkd.

Nice looking images - tricky are your last two posts Mode 1 or 0?

AND

questions for Tricky and Davidb

a) what source image do you feed to the Beeb (or Elk) program? i.e. what is the format (resolution, no. of colours)
b) do you run any code PC side to manipulate the image before it is displayed on Beeb/Elk side
c) can you describe the algorithm/s used to decide what colours to use per line
d) can you upload the source code (preferably commented ) ?

Well done to you both. I reckon you're pushing boundaries on the Acorn 8 bits; I think similar (probably more fancy due to h/w) tricks have been done on the C64 with odd screen modes and dithering.

[davidb]

For the Electron code itself, the source images need to be 320x256 in the standard 8 colours.

On the PC side, the make_picture.py script will scale larger images down and reduce the colours to only 4 per scanline. If paulb doesn't publish his script separately, I'll try to include it with my tools, but it works in a similar way. The make_picture.py script encodes the image data in the form that is needed for mode 1.

I think I described my algorithm in an earlier message. paulb would have to describe his, though the code he wrote is deceptively short for what it does.

I put the code in a Mercurial repository. I'll update it later tonight.

[davidb]

I can reproduce the parrot image in Elkulator using my code, so I'm happy about that. I had to do some things to the parrot3_eg.png image first, but then it could be processed by my conversion script.

Where did the parrot picture come from, by the way?

[tricky]

My conversion only takes tga files as it is the same code I have used for the last 20 years. It takes the to left 320x256, cropping the right and reducing to a multiple of 4, so that it doesn't require a border color, but currently doesn't reduce the width of the screen, maybe tomorrow. The bottom is padded with black, I us it should be centred, but isn't yet.
The source can be any bit depth as it uses a Floyd-something algorithm to dither the image.
To pick the colours, I use sum of squared errors in r,g and b and just try all combinations of the current line with all combinations of the next for "preview" quality and takes a couple of seconds in c, it can run with any lookahead, but I haven't decided if anything more than 2 is useful and as that takes about 15 second unoptimised on my old desktop, it is long enough.
I output a tga of what the image should look like and two files ready for beebasm to include, one with two sets of palette info and one with the image.
The parrot was just on my disc, I'm unsure where it came from, it might have been a really old cover disc, I'm not sure.
Mine are mode 1.I will post the source once I have debugged it as it still goes mad on some images; and you know comments and I are strangers :O
Does the electron palette programming differently to the beeb? Or do i have time to change 4 colours and just can't work out how?

[davidb]

The Electron palette in a 4 colour mode only uses 2 registers, mapped to the addresses FE08 and FE09, so I just need to read the contents of 2 locations in RAM (which will cause the CPU to stall if done during the display period) and write to the registers. 12 bits are needed to represent the 4 colours so I can't just use one location to hold the palette unless I optimise the palette entries, which really isn't worth it for my code. In a 2 colour mode, I could easily do that.

From the EAUG (page 215), the two registers look like this, with the red, green and blue components for each logical colour stored in inverted form (0 enable, 1 disable):

Code: Select all

FE08: B3 B2 B1 B0 G3 G2 X  X
FE09: X  X  G1 G0 R3 R2 R1 R0

So, to make colour 0 black, you have to set the bits containing R0, G0 and B0.

If I try to run similar code in RAM, the instructions are accessed at half the speed. Memory accesses are the same when done from ROM or RAM, but there may not really be enough time to change both registers. I could understand if you are short of time when having to change 4 of them. Even if you optimised the number of locations that hold the palette data, you would still need to unpack the data and write to 4 palette registers as I understand it. Does that make sense?

Edit: If you have to write to 4 registers per colour, if I'm reading the AUG correctly, then the situation looks even worse! I suppose you could take advantage of the "nasty" effects that the guide mentions and write to fewer registers, but then you'd need to optimise the data even further.

[tricky]

That makes sense, yes, four writes per "colour", I use something like:

Code: Select all

.wait_for_vsync
	lda #SysIntVSync
	sta SysViaIFR
.wait_vsync
	bit SysViaIFR
	beq wait_vsync

The bit takes 4 cycles and the last beq, 3, meaning that I have a "random" element of less than 6 cycles. I could probably make this better by more precise cycle counting and get it down to knowing exactly when the vsync starts, but that wouldn't get me another 24 cycles for another colour.

Code: Select all

.write_palette_entries
	STA VideoULAPalette
	EOR #&10
	STA VideoULAPalette
	EOR #&40
	STA VideoULAPalette
	EOR #&10
	STA VideoULAPalette

	TYA
	STA VideoULAPalette
	EOR #&10
	STA VideoULAPalette
	EOR #&40
	STA VideoULAPalette
	EOR #&10
	STA VideoULAPalette

Changing both colours takes 46 cycles, but a bit less from first register write to last.
There are 128 cycles per scanline, with 80 of them visible, leaving 48 cycles to change the palette and allow for which of the 7 cycles in the BEQ+BIT the vsync starts. As I haven't seen any flicker, I either have my maths wrong, or don't use the changed colour in the first/last byte!

[davidb]

Another set of images to look at. This disk has a screen containing information about the code.

[jgharston]

I just get the screen filling and Bad key.

[paulv]

I just get the screen filling and Bad key.

I get the same. I see bad key and every image loads one after the other with no waiting and no palette jiggery pokery either.

Paul

[davidb]

I just get the screen filling and Bad key.

That's odd. What system configuration are you using?

[oss003]

Hi David,

Elkulator is working fine, great pictures!!!

Greetings
Kees