Quantizator

[emkay]

64 bit code would speed up things for sure.... approx. 30% ... and the memory limit wasn`t there, so you could chose as much solutions as necessary, to get the best possible picture

Edited August 4, 2012 by emkay

[emkay]

 

 

This picture actually is based on 8 colours. But it ends up in 7 colours at all.

 

No more details added from 210M eval.

 

 

 

 

210M.xex

[1NG]

Here are just some thoughts about a constant amount of colors per row (to prevent something else):

Based picture is posted here some posts before in true color.

 

 

Resulting picture from that in all Atari colors with dithering would be

 

This is not possible as there are to many colors per line. A diagram for the colors of each line shows 6 to 16 Atari colors per line.

 

(first line is the amount of colors of the first line of the atari picture and so on)

 

Using 4 colors per line looks like this:

 

it has lots of errors

 

This will stay so for 9 or any other low number of colors.

A drawback is allways, that colors change from top to bottom because they are not get choosen for that line.

 

Ithink the approach of calculating a "best fit" is a good approach. Some criteria for best fit are not easy to calculate.

 

I think that looking at the pictures above and of course the thread at all is very interesting. And there are a lot of ideas presented here.

Quantizator has some kind of complexity that will allow users getting experts after using it heavily. I like that.

[emkay]

 

The solution is to check the possible colors per scanline in relation to the "neighboured" lines to have a common dither result.

 

Quantizator has some kind of complexity that will allow users getting experts after using it heavily. I like that.

 

You can only become an expert when there is a fixed point. If the point is changing (like the randomness in the results) the "experts" run in a chaotic manner after that. Thus you see unfinished pictures on and on....

[emkay]

The biggest bug in the importing part of the converter is the usage of the "palette" colours. As soon as you give a slight finger to the routines, it uses the "brighter" colours over the "darker" white. While in real, the colours were on the same level. This calculations should be independent of any palette.

[ZylonBane]

I cannot believe you people just wasted 10 pages on a technical argument with emkay, the incoherent idiot who's never satisfied with anything, and never right about anything.

[emkay]

I cannot believe you people just wasted 10 pages on a technical argument with emkay, the incoherent idiot who's never satisfied with anything, and never right about anything.

 

Reading that from you, I'm gladly honoured.

[Heaven/TQA]

Here are just some thoughts about a constant amount of colors per row (to prevent something else):

Based picture is posted here some posts before in true color.

 

 

Resulting picture from that in all Atari colors with dithering would be

 

This is not possible as there are to many colors per line. A diagram for the colors of each line shows 6 to 16 Atari colors per line.

 

(first line is the amount of colors of the first line of the atari picture and so on)

 

Using 4 colors per line looks like this:

 

it has lots of errors

 

This will stay so for 9 or any other low number of colors.

A drawback is allways, that colors change from top to bottom because they are not get choosen for that line.

 

Ithink the approach of calculating a "best fit" is a good approach. Some criteria for best fit are not easy to calculate.

 

I think that looking at the pictures above and of course the thread at all is very interesting. And there are a lot of ideas presented here.

Quantizator has some kind of complexity that will allow users getting experts after using it heavily. I like that.

 

What is this tile Tool you have used?

[emkay]

Incoherent... is the word of today....

 

If someone really wants to aid the "A8 scene" he would think of a coherent development tool.... Where people from outside can handle the A8 stuff by just using the tool itself...

 

Here a video of what's actually there:

 

http://www.youtube.com/watch?v=u4P6hjlmXxQ

 

I'd bet the participant ... painting with G2F ... has done the 1st and last pic with G2F.

[ZylonBane]

For the love of god, what does it take to make emkay STOP POSTING?

[emkay]

For the love of god, what does it take to make emkay STOP POSTING?

 

A bug free graphics development/drawing tool for the A8 would be a good start.

[potatohead]

He wants somebody to write all the possible code, incorporate it into a tool he can click on and do great things.

[emkay]

He wants somebody to write all the possible code, incorporate it into a tool he can click on and do great things.

 

Well, the A8 is a rather slow machine, compared to today's PCs. But some people's brains seem to work even mechanically....

 

Can you follow it? The only way to get real artists creating stuff for the A8 is a tool they understand.

 

[emkay]

The right picture is the DST. the left picture is the actual state of the output.

 

 

 

In the white mark, you see the old bug. Bands in the center of a unicolour range.

This time, the solution would be clear. As the brown and red/brown colours were at the same brightness level, the dark lines simply could be exchanged with the brown colour, which would make the band ignorable by the image itself.

But 100000 solutions seem not to be enough to have that decision right. What case ... at all... makes the software deciding to use such a wrong "banding colour" there?

Actually, it is a summary of the different stacked bugs.... or should we say miscalculations?

 

[ilmenit]

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

 

Which image on the left do you mean?

 

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?

 

RastaConverter does midline changes of colour/sprite registers. You can have up to 7 changes in line. With initial set of colours (4 playfield, 4 players) you can have up to 15 colours in line.

 

(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?!)

 

If you want you can reduce number of colours in line with some other tool to 9, but from what I tested it works well only with some pictures, for others giving much worse output.

This question reappears. I think I will add that to FAQ.

[ilmenit]

For the love of god, what does it take to make emkay STOP POSTING?

 

Just add him to ignore list. He does not understand what people write to him so he won't stop to post that rubbish.

[1NG]

Incoherent... is the word of today....

 

If someone really wants to aid the "A8 scene" he would think of a coherent development tool.... Where people from outside can handle the A8 stuff by just using the tool itself...

 

Here a video of what's actually there:

[youtube video]

 

I'd bet the participant ... painting with G2F ... has done the 1st and last pic with G2F.

 

AFAIK the paintings in the compo are NOT simply converted from a picture. They have to be handmade. The video also shows the steps of work.

Quantizator is not a painting program. It does not fit to the problem. Isn´t it better to use G2F to do it by hand? It is exact as you requested and can do wonderful pictures.

 

I think that all pictures in the compo have to come around the limitations.

Quantizator as a painter? The Gui is not designed for that. If a new program uses the cool "graphics mode" of Quantizator and would try to allow manual painting it would still be very difficult, because a new pixel at any point often needs a change that has effect on other pixels. And there is not only one solutioin for even changing only one pixel. What solution should be choosen? Would you like to get a drop down menu with 20 solutions for that and choose one by looking at the result? And after choosing a pixel the next pixel can destroy the previous one in all possible solutions if you have bad luck.

 

Maybe it is possible to paint a (translucent) green and red over the picture. Where green is painted the pixel get higher priority and less priority if it is "overpainted" with translucend red.

Then a slightly directing of the automatic optimization is possible. But it will remain "random".

Maybe the red/green overlay could be given as an option and has to be painted before the optimization process. Again it shows that the preparation process of the picture and the calculation parameters can have very strong influence on the result.

 

Only a thought, don´t thinkabout it: A fix random generator start for the complete picture can be given (not easy for multi threaded apps). That means only that the next calculation with identical parameters get the same result. The solution stays random of course. But how much random is the picture anyway? There can be found some good calling parameters that generate nearly the same result every time.Given the fact that it is impossible to calculate the "best picture" (BTW: How does someones eye define that without the slightest subjetivity?) in a short time, quatizator make a very good job.

[Synthpopalooza]

Here are just some thoughts about a constant amount of colors per row (to prevent something else):

Based picture is posted here some posts before in true color.

 

...

 

What is this tile Tool you have used?

 

Far as I know, he's written his own tool called GraphicsTileMaster which will take a picture and render an optimised Antic 4 font picture, or a font picture using CIN mode (Graphics 12+11, 80 colors). Still a work in progress.

[ZylonBane]

If a new program uses the cool "graphics mode" of Quantizator and would try to allow manual painting it would still be very difficult, because a new pixel at any point often needs a change that has effect on other pixels.

 

Such a program existed twenty years ago-- GED (Graphics EDitor), by John Harris (and discussed here nearly 10 years ago). And indeed, nobody used it because creating pictures from scratch with this technique is excruciatingly difficult. It's a task for brute-force machine translation.

[+Stephen]

Thought this may be of some interest to people reading this thread.

how to choose colours procedurally

[emkay]

Current state...

 

 

Funnily enough, the picture again has some bug ...

 

A8-softwaredeveloper.xex

[emkay]

 

 

AFAIK the paintings in the compo are NOT simply converted from a picture. They have to be handmade. The video also shows the steps of work.

Quantizator is not a painting program. It does not fit to the problem. Isn´t it better to use G2F to do it by hand? It is exact as you requested and can do wonderful pictures.

 

Ofcourse they are handmade. But do you think that one of the artists had to code anything while painting ?

Given that an artist is painting from scratch, there always indicators in the background could show, how much cycles and colours/changes (and which were) available.

There is no random part, just what the artist is painting, to calculate with.

G2F has the rasters. The solution is to put some automation to it, to aid the artist.

 

[1NG]

Ofcourse they are handmade. But do you think that one of the artists had to code anything while painting ?

Given that an artist is painting from scratch, there always indicators in the background could show, how much cycles and colours/changes (and which were) available.

 

Short: Hand Painting & G2F -> few colors per line using simple rasters, Quantizator -> lots of colors using complex rasters

 

There are two different applications for different needs.

Try to paint the bird obove by Hand -> impossible with G2F.

Try to get a G2F-Painted cool Picture to be found by Quantizator -> (nearly) impossible

 

What you want is a painter? Take G2F that is a good solution for that. You can´t have the full colors without complex rasters which have complex side effects which can not be visualized for the artist.

What you want is maximum colors? Take Quantizator and do not try to paint over the result.

 

There is no random part, just what the artist is painting, to calculate with.

G2F has the rasters. The solution is to put some automation to it, to aid the artist.

No. Assuming rasters are the same is not correct here.

 

There are other rasters for other needs. I have one for my own needs, and it is different to G2F or Quantizator.

 

You don´t want a "random program" to help you (because the result will be random), but you don´t have the time to wait for the brute force method (because you die before it is ready)

You can´t get a painting program with Quantizator rasters, because they are the result of the random process.

 

Quantizator rasters are not uniform, and that gives more colors and positions but more complexity.

 

Live with G2F and fewer colors, painter, and you will be happier. G2Fs restricted raster mode is understandable by the artist. And the paintings are not bad at all. The 4 (5) bitmap colors are shown on the left border.

 

Stock management uses a similar technique: chaotic or dynamic stock. Put pieces optimal in different places (chaotic) uses the space very well, but is not easy to handle from a person, because pieces are spreaded all over the stock.

The other technique uses the same pieces always in same locations but wastes space. This can be handled by a person.

-> Like much colors, but not understandable for the painter or less colors and easy to handle.

 

BTW: The color problem is way complexer then the example above, because usable areas overlap. But maybe it is an example to understand.

[emkay]

 

Short: Hand Painting & G2F -> few colors per line using simple rasters, Quantizator -> lots of colors using complex rasters

 

There are two different applications for different needs.

Try to paint the bird obove by Hand -> impossible with G2F.

Try to get a G2F-Painted cool Picture to be found by Quantizator -> (nearly) impossible

 

 

Ofcourse the bird is possible in G2F. The Raster editing is a annoying thing to do by hand. In G2F you can use up to 23 colours per scanline, if you want. The Rastaconverter allows up to 16 colours.

The problem with G2F is the missing automation for editing the rasters.

The problem with Rastaconverter is the "colour-usage-decision" which is not correct.

The older versions of Rastaconverter acted on every change of the source pic, so, basically, an automated tool for creating graphics was there.

The new version has even more bugs and crashes sometimes, when editing the source picture...

[emkay]

 

BTW: The color problem is way complexer then the example above, because usable areas overlap. But maybe it is an example to understand.

 

Some calculation helper....

 

We have 160x240 pixel. So in no way we could have more than 160x240 colours (38400) on the screen.

This is also limited by the FIXED palette of 128 colours and the available colour switches per scanline.

The only REAL problem is the calculation of the available colours per scanline with that. This limitation and the fact that an image has to be "an image" , limits the colour count even more.

Mostly a "real" colour picture ends up in less than 60 colours , and it is FULL ALIKE whether the picture originates from real colours or from a 512 colour picture.

And btw. one of my self written tools back in the 80s was a picture converter....

Edited August 7, 2012 by emkay