Quantizator

[emkay]

I have to say you're getting some nice results there Emkay. Pictures tend to be spoiled by the horizontal banding, but I see hardly any in your latest efforts.

 

It's still Ilmenit's program

But it still can be optimized. What really has to be removed is the "brightness search in cost of colours", which causes the banding to get more visual. For now, the solution is to adjust the colour's levels. With C64 pictures it is rather easy, because they are already close and only 16 of them. While in "real color" pictures the amount of usable colours can vary every scanline.

Depending on the image, 80-90 colours should be possible with some slight banding.

[Wrathchild]

A fairly good stab at another C64 screen but I feel this tool missing the "5th color" option but then that would need a new approach for for the 4*8 cell of the inverted character.

output.xex

[emkay]

A fairly good stab at another C64 screen but I feel this tool missing the "5th color" option but then that would need a new approach for for the 4*8 cell of the inverted character.

 

Come on. This picture uses 13 colours and not more than 9 colours per scanline. Those pictures should be adopted in some seconds.

But, as I wrote already, the colour-choice-routine has it's logical bugs.

 

http://www.youtube.com/watch?v=AAGmKG43y-A

 

Look at the circle in the background. The converter leaves it even at almost 100m not fully adopted.

At 42s. I dropped the same picture in, with just a clean different colour, which makes the circles handled fast. And then look how far it goes til 120K of evaluations.

 

 

 

[Rybags]

A 5th colour could be added, sacrificing some HBlank time so it might affect preloading.

 

The VScrol trick can be used to have characters that extend the entire height of the screen with only a single badline at the top - Jac used it in his demo with the diagonal rotation between 2 bitmaps.

 

In the context of this utility, the way to use it would be to have "Inverse" characters at the far left/right of screen which allows plenty of time between PF3 changes. PF2 wouldn't need to be preloaded since the first change per scanline isn't until near the middle.

 

The cost though is that the VScrol register needs periodic updates as well as Chbase - these might be able to be staggered, so minimising the cycles lost.

The other cost is that it would probably increase the complexity of the program somewhat.

[+MrFish]

A fairly good stab at another C64 screen but I feel this tool missing the "5th color" option but then that would need a new approach for for the 4*8 cell of the inverted character.

 

Looks good!

[w1k]

how i can make picture without border? /noborder - no works

 

You could change this line in no_name.asq:

 

 mva #$ff sizem

 

to this:

 

 mva #$00 sizem

 

again i have border..

[emkay]

Can it be? The converter is originally done for C64? Or at least the colour adjustment routine?

It would work 100% and fast there. As the 16 colours have their direct rules and clear distinguishness (which only sounds good... actually)...

On the A8 the colours spare their brightess in 8 steps, some share the colour space very close. So, if the colours weren't to different, the program leaves them unsorted, even if a "full row of code" for changes is free.

On the other hand, it pulls colours in, that weren't in the original picture and don't aid it at all.

 

Could someone axplain , why this is appearing?

 

I only see a correct solution, when the colours fully get handled with an indexed palette.

 

 

[emkay]

The original SCR picture uses 13 colours, the converter result uses 21 colours. This might look nice in numbers, but at the end, 13 colours were easily to handle, 21 colours not.

 

This is one scanline of the output picture. Actually 1 colour is needed to make the line completed.

 

7 coloures used there.

 

 

As you might see, there is enough space to add even more than one colour, but the converter doesn't care... Actually a white pixel is missing there at the car.

Make the grey a bit darker , the white pixel will approach.

 

 

 

[ANTIQ]

It might be useful to be able to lock the converter to the nearest Atari colours when the source picture contains fewer than 128.

[Wrathchild]

I'm going to try another approach... make an .act file with everything set to black, or maybe a value that we know wouldn't be matched, and then set the RGB values for the C64 palette at their equivalent position in the A8 palette (as pairs due to the 256 to 128 reduction RastaConverter does). In theory then the mappings then can't go wrong?

[emkay]

Every picture could be handled well, if the colours get their index, when it comes into the range of a usable count of colours.

 

Best ways right now:

Put the picture through a filter, til it reaches 160x240 pixels (for example). This limits the amount of colours to 38400. The filter will adjust it to root(3) for every colour channel of RGB, leaving 34 clear steps of brightness per channel.

But pictures always have an amount of used colours in there, limiting the colours even more.

That's why 256 indexed colours mostly were enough to have fully working images at that resolution.

So, if you have the picture fully converted to the usable resolution, it can be adjusted colour by colour to the Atari palette, without making the whole thing looking weird.

 

The most limiting factor is to find the possible changes per scanline. This had to be adjusted before switching to the A8 palette.

Edited June 9, 2012 by emkay

[emkay]

For "low colour images" as from the C64, reducing of colours isn't needed, except the amount of colour changes per scanline exceeds the limitations of the A8.

In theory, the content of colours could be ignored, just the index of a colour had to be handled.

Edited June 9, 2012 by emkay

[Xuel]

how i can make picture without border? /noborder - no works

 

You could change this line in no_name.asq:

 

 mva #$ff sizem

 

to this:

 

 mva #$00 sizem

 

again i have border..

 

I think you are swapping "border" and "no border". You have no border in that picture. border = two black bars on left and right side of picture made from MISSILES which cover COLBAK and PLAYERS. To get a border change #$00 back to #$ff.

[Wrathchild]

Here's the c64 palette as an act file, aligned to approximate A8 equivalents, for anyone to experiment with.

c64_act.zip

[emkay]

Here's the c64 palette as an act file, aligned to approximate A8 equivalents, for anyone to experiment with.

The big red part in the palette causes the converter to be very red friedly in pictures.

How has the palette to be defined exactly?

 

How's about using the values of the 16 colours of the palette 8 times?

Edited June 10, 2012 by emkay

[emkay]

It's odd. Why is the converter doing this?

You have a picture with 11 colours at the 160x240 resolution.... indexed colour BMP . Everything should go like drinking a good beer in the desert.

But the picture gets 23 colours there... 5 greys instead of 3 greys, 6 browns instead of 3 browns... 5 reds instead of 3...

[emkay]

How's about a direct import filter ... with a dedicated switch /filter=direct . For prepared pictures , and for testing purposes?

[emkay]

For some variety

 

 

grau.xex

 

 

[Wrathchild]

The problem will be that many of the C64 pictures people will be using will have slightly different variations of their 16 colour palette and so so the converter is still making guesses based upon the distance function employed. This may explain why the red-bias is being seen as the colours in your source picture maybe closer to the 'red' that I've set every unused entry in the c64.act palette too.

 

Like emkay suggests, a better approach could be to form a palette 'on-the-fly' from the loaded image if it has <=16 colours. This would re-position the colours in the 256 entry palette to correspond to the A8 .act file entries.

 

Alternatively you can take your source picture and use something like XnView to edit the palette and tweak the 16 colours to the values below. Then when you pass it to RastaConverter with the c64.act file then the computed colour distances should be spot-on.

 

0 0 0 ; Black

255 255 255 ; White

136 57 50 ; Red

103 182 189 ; Light Blue

139 63 150 ; Purple

85 160 73 ; Dark Green

64 49 141; Dark Blue

191 206 114 ; Yellow

139 84 41 ; Light Brown

87 66 0 ; Dark Brown

184 105 98 ; Pink

80 80 80 ; Dark Grey

120 120 120 ;Mid Grey

148 224 137 ; Light Green

120 105 196 ; Mid Blue

159 159 159 ; Light Grey

[snicklin]

Could I be cheeky enough to ask for a feature request (once more!)

 

When continuing, I would like an optional option to say where to concentrate RastaConverter's efforts. I have an image which is very good on the bottom half but not so good in the top half. I would like to be able to say /concentrate_on top .

 

I could image that the options may be:

top

bottom

0-100 (scanlines to concentrate it's efforts on)

 

... or something like this.

[w1k]

wow, that eye..

[Bryan]

wow, that eye..

It's watching you.

[Wrathchild]

I think this nice C64 image will be beyond the A8, here I've flipped the image horizontally to try and encourage the face to be concentrated upon but still no joy Others screens that also struggle... QueDex loader & Ballistix

c64screens.zip

[emkay]

I think this nice C64 image will be beyond the A8, here I've flipped the image horizontally to try and encourage the face to be concentrated upon but still no joy Others screens that also struggle... QueDex loader & Ballistix

 

The "nice" picture is already beyond the C64 .... colourwise.... While the others look really nice.

 

I'm trying them with my method... If it only was a bit faster...

[emkay]

Funnily enough, to see colours of the C64 change mystically. As in the Quedex Picture, some colours of the Amstrad CPC (like only a channel of R,G or B has turned fully on) got some friends to the image-uploader. While in pictures with the usage of colours for having "brightness effects" , the colours get a decent style.... sometimes pastel.