Quantizator

[ilmenit]

Jose, reporting as "does not work!" is not very helpful...

Please attach all the input and output files and only then I will be able tell you what is wrong.

But probably you won't get 1:1 copy, because RC does not use 5 colour char mode, sprites are always quad size and their priority is different.

Edited July 26, 2012 by ilmenit

[ivop]

Here's a patch with some fixes for Linux and g++ (warnings, deprecated stuff, etc...) and an updated Makefile. One can now do a normal build (make), a profile generate build (make pg) and after running the rastaconv-pg binary for a while, one can make a profile-use build (make pu). The resulting rastaconv-pu binary should be faster

ivop.patch.zip

[José Pereira]

Jose, reporting as "does not work!" is not very helpful...

Please attach all the input and output files and only then I will be able tell you what is wrong.

But probably you won't get 1:1 copy, because RC does not use 5 colour char mode, sprites are always quad size and their priority is different.

Thanks but I think I really understand now.

5colours it would be just one more colour but I think that the problem are in the PMs.

Mine are all Normal width so your quadruple with more the 5colours...

(if it was possible that program could get the PMs wide according to the colour Area it would cover...)

Edited July 26, 2012 by José Pereira

[ilmenit]

The best result that I have achieved:

sf1.xex

sf2.xex

Unfortunately adding inline changes of priority, sprite size etc. would slow the process a lot. I'm thinking of adding the char mode for the fifth colour, but the CPU timing is not equal in lines there and it is even hard to predict how possibility of char inversion would slow the conversion.

Edited July 26, 2012 by ilmenit

[Synthpopalooza]

I do recall another bug in Atari's ANTIC display, something like, if you change from mode E to mode F in the same scanline, the color palette is changed ... 708 becomes COLBK and 711 becomes PF2. I wonder if this would be of any use here.

 

As for char mode, you would either need to change CHBAS every so often on the screen, or find a way to optimise characters on screen ... that's the problem I've come up on when doing my ICE pictures. I've had to use anywhere from 5 to 8 double fonts per screen, and I am not real sure how DLI character changes would work with scanline changes of color regisers and PM positions/width. And there's also the problem of PF2-PF3 mixing. One way around it is to use the old VSCROL trick (Konop's mode) ... 32 character rows (or 40 character rows using 240 scanlines), 6 scanlines per character. It wastes some memory and takes up processor time, but allows for better PF2-PF3 mixing.

Edited July 26, 2012 by Synthpopalooza

[Xuel]

I do recall another bug in Atari's ANTIC display, something like, if you change from mode E to mode F in the same scanline, the color palette is changed ... 708 becomes COLBK and 711 becomes PF2. I wonder if this would be of any use here.

 

Perhaps you're thinking of mid-line changes of GTIA's PRIOR register, like in Ilusia or several other demos? Might be hard to use since part of the bitmap will be interpreted as 4x1 pixels instead of the usual 2x1. Also, the screen gets garbled where the changes occur.

[Synthpopalooza]

It might be less intrusive though if you did a change to mode 10 inline though, the 4x1 pixels might not show up as much. Perhaps for areas of the picture that don't require the high resolution?

[emkay]

This thing better would go on 64 bit.

Some calculations break due to the 2GB RAM limit. 64 Bit code wouldn't bother ...

[emkay]

2GB memory cause ...

 

[Bryan]

I do recall another bug in Atari's ANTIC display, something like, if you change from mode E to mode F in the same scanline, the color palette is changed ... 708 becomes COLBK and 711 becomes PF2. I wonder if this would be of any use here.

Yes, high-res mode is latched at the beginning of a line and if you change into GTIA modes its state is lost and switching back gets you a 160 mode with the color registers rearranged. I don't know if there's anything terribly useful about it, but it does allow 320/160/GTIA modes on the same line. I kept trying to find a R-M-W instruction which would switch GTIA from 320 to 160 mode in 1 instruction but I never could do it.

[Joey Z]

so when can we get a cluster computing version of rastaconverter?

(half joking, half serious here...)

Edited July 30, 2012 by Joey Z

[+Stephen]

so when can we get a cluster computing version of rastaconverter?

(half joking, half serious here...)

It would be cool, but a more realistic approach would be porting the code to CUDA (which is beyond my meager skillset).

[ZebCorpse]

... or better to open-CL, perhaps? Cuda availability is limited to the nvidia hardware...

[emkay]

This one:

 

 

 

turns into this one....

 

 

In the dragon, you see the bright blue... at the same level as the white. In the original it is a brightness level below.

Blue has become violet.... and so on.

 

I wonder, how someone could be satisfied with that?

 

Scaling the a8 palette into real RGB values for the calculation is the solution here. And after the calculation has been finished, the colors could be set back to the palette values.

[emkay]

The brightest white of the laoo palette (for example) is R=220, G=219, B=220

The brightest white in RGB is 255,255,255.

Darkest colour is 0,0,0

The real brightness steps you can project from the created voltage inbetween them.

 

Colours on the PAL Atari...

 

grey

gold/brown

red/pink

winered/rose

...

the colour distance also can be adjusted by the dependency of the produced voltage ...

[snicklin]

so when can we get a cluster computing version of rastaconverter?

(half joking, half serious here...)

 

We've got one - sort of!

 

Open the same picture on several computers with different settings.

 

Then see which ones comes out best!

[Heaven/TQA]

simpler... open several instances of the converter one PC - ok. Quadcore...

[Synthpopalooza]

I was just thinking ... somewhere back (or maybe in the Rasta thread) was mentioned the possibility of using Antic 4 and gettng the 5th color. I just thought of an idea: You can change the CHACT register on the fly from 2 to 0, in areas of the picture where you want to have PF3 and PF2 in the same character, maybe alternate it on scanlines, or in mid scanline. That might ease things up.

 

I also think having an interlace option would be neat, though I don't know how easy it would be to implement. There are 5 possible types of interlace one could do in Antic F (or Antic 4):

 

DIN: Graphics 15-8 (or Graphics 12-0) for 320 pixel res.

XL Paint or INP: Double Graphics 15 or 12 (in char mode this is called Super IRG)

CIN: Graphics 15-11

MIN: Graphics 15-9

PCIN: Graphics 15-10

 

DIN would not be too workable in char mode because you can only do full frame changes, not changes on the scanline. Also, using CIN/MIN/PCIN on scanline changes would introduce some limitations if you used char mode (not all colors available, inverse mapping).

[Rybags]

CHACT has no effect on PF2/3 choice in the MC char modes.

 

The problem with using char mode is the badlines. To get around that, VScrol trick can be used to give full screen height characters if needed.

But then the problem arises - you get stuck with whatever attributes for the whole duration.

 

This could be used to advantage - e.g. use PF2 on the left, PF3 on the right of screen. But some HBlank cycles will be lost. In order to get tall characters we have to continuously update VScrol, and also change CHBASE to introduce new data.

So these sacrifices mightn't be outweighed by an extra available colour.

[ilmenit]

FAQ for RastaConverter:

http://github.com/ilmenit/RastaConverter/wiki/FAQ

[1NG]

FAQ for RastaConverter:

http://github.com/il...verter/wiki/FAQ

The FAQ is a good Idea! No need to read the complete thread here and it shows how complex graphics can be. But it also includes a lot of knowledge transfer for the interested user.

Well done!

[ivop]

Seconded.

 

Your avatar btw. shows how simple graphics can be sometimes, and still highly effective. With only a few pixels it is obvious that the guy dressed in black is way older than the other one

[Irgendwer]

The image on the left hand side depicts the 'possible' optimum image when displayed with the A8 palette.

But AFAIK it is impossible to display more than 9 colours per row!? So what about an additional preprocessing step, reducing the no. of colours to the maximum possible (9?) per row?

(I've got good results with 'Pairwise Clustering' (http://www.google.co...mgVcb0Q&cad=rja) , but of course you could also add median-cut or quad-tree colour quantization).

IMHO this would not only give a much better representation of what result is at best possible, but also suppress unneeded 'cycling adaptations' when the converter tries to adapt to more than 9 colours per row... (resulting in a faster and better reconstruction?!)

Edited August 4, 2012 by Irgendwer

[emkay]

The image on the left hand side depicts the 'possible' optimum image when displayed with the A8 palette.

But AFAIK it is impossible to display more than 9 colours per row!? So what about an additional preprocessing step, reducing the no. of colours to the maximum possible (9?) per row?

 

Wow. And that is what you've got that fast ?

 

Depending on the colourisation, even 6 colours can be the upper limit. Best case seem up to 13 colours per scanline...

 

[emkay]

The picture I have marked where obvious banding errors occure. Just leaving the area unicolour would enhance the picture... local and global.

 

 

 

The interesting part: The more solutions you chose, the less of this unnecessary bands appear.

But 100000 solutions can break the 32 bit range of calculations.