Quantizator

[snicklin]

I programmed a similar program to this years ago at university. It was a Fractal Compression routine for the PC. It would iteratively amend details of the picture until the differences between it and the original were smallest (lowest distance). If only I had thought of this!!

[emkay]

Nice. Tool is still working here. Does it use multiprocessing? I see not all cores were handled equal?

 

How about some spedup with manual help

 

 

This image gets into this:

 

 

The help could be to create an image that fits to the resolution and to the available colours..

 

 

Then check the scanlines (most colour changes)

 

 

And sort the palette to find images with approximated 12 colours per scanline.

 

Then convert the picture for showing it on the real hardware.

Edited April 21, 2012 by emkay

[snicklin]

I think that any changes in the strategies of how to encode these pictures would probably make the code prohibitively complex.

 

I have a picture with myself and the wife in it. As like most photos of humans, we're in the middle of the picture. In theory I would like to be able to ask for a feature to prioritise the horizontal centre of the picture and not the picture as a whole.

 

However, imagine how much more complex the code would be to then start discarding changes (which may enhance the picture as a whole) because they are on the edge of the picture.

[AtariNerd]

Be sure when you apply the patch by adding and replacing the files in the last download to the base files, to also delete the old RastaConverter.exe file and rename the RastaConverterBeta2.exe file to RastaConverter.exe or else you're still using the old build engine. I think I got that right. The bat file still calls on the old engine rather than the new one. Found this out by simply deleting the old engine file and trying to run it by dropping an image file and getting a missing resource warning.

Edited April 21, 2012 by AtariNerd

[w1k]

with this bat i have BW pictures, why?

q 02.jpg /lock=000000 /h=192 /mode=simple /dval=0.2 /pal=Palettes\laoo.act /o=file3.xex

[AtariNerd]

So, when are we getting CUDA support?

[emkay]

If I'm correct only DLIs are used to change the palette of the playfield gfx. No PM gfx used, am I right? Especially interesting then." (& Thanks, Ilmenit, for the answer.)

 

this is bitmap mode, LMS per line, raster program, GED- g2f equivalent, PMG used

 

Which version of G2F loads it then? I set GED- LMS Rasters... but the colour get weird.

 

 

The supposed image

 

 

 

after loading the colours in G2F:

 

[emkay]

So, when are we getting CUDA support?

 

Or at least 64 bit multiprocessing support

[ilmenit]

1. RastaConverter is not Quantizator! While they both convert pictures they are totally different programs and have different command line parameters. I wanted to create a new thread not to mix them, but discussion already started here.

2. No multiprocessing for now. You can run a few instances of RastaConverter (with at least one second delay - RNG init resolution is 1 second), because sometimes picture get different details optimized.

3. To limit confusion the newest version is attached to this post.

4. Currently you can't edit created pictures. You can copy output files (output.*) to the Generator directory and run build.bat - this will compile executable file to be run on the Atari. Loading output to Graph2Font is planned, but both Graph2Font and RastaConverter must be extended for that.

5. I plan to add some better interface with the "mask of details" feature - user will be able to define a mask and algorithm will try to optimize more the masked area. It will increase user defined details f.e. faces on the pictures.

6. I started recently CUDA programming so maybe in the future we will have this converter much faster

7. 64bit version can be created, but I haven't seen any boost with that.

8. Multiprocessing won't increase the speed. The slowest part is execution of raster program and it can't be parallelized.

RastaConverterBeta2.zip

Edited April 21, 2012 by ilmenit

[+Philsan]

Is right image always achieved, as long as you let the program makes millions iterations?

[ilmenit]

What is right image? If I would be able to determine the ootimal state, then iterative optimization process would not be needed... :-)

 

Moreover there is no perfect optimization. Different people may find different details of the picture more important.

[snicklin]

 

5. I plan to add some better interface with the "mask of details" feature - user will be able to define a mask and algorithm will try to optimize more the masked area. It will increase user defined details f.e. faces on the pictures.

 

Wow! Best of luck with this! I didn't think that this would be possible!

[+Philsan]

Sorry, with "right image" I meant the third image, the image on the right, the target image.

Will the second image, the center image, always become identical to the third image?

In other words, if I patiently wait, will I achieve the result pictured in the third image?

[AtariNerd]

Is right image always achieved, as long as you let the program makes millions iterations?

 

I think the image on the right is the original image as it would theoretically be if converted to the A8 palette and the Atari were able to display all of those colors without restriction. The program dose a brute-force comparative analysis of neighboring pixels and lines and tries to create prior color maps and spritemaps to add color. Since it can't know what shapes it might need and can only compare only so many pixels/lines directly to each other, it has to flop back and forth and compare repeatedly for best results. If neighboring pixels match enough and a color that might not otherwise be available on that line can be achieved by one of the techniques, it will create an entry in its' database to come back to. It does this many many times, comparing the next set and the next set. Again, it can't know if what it is doing is going to accomplish the best results, only if a particular instance achieves a better match. If so many instances above a certain thresh-hold are achieved it likely settles on a particular technique. Of course, resources are limited - there are only so many prior color combinations and sprite-layers the Atari can accomplish before memory/ cycle time/ registers are filled up, so it has to take that into account. Theoretically the more time, the better the results, but there is eventualy an exponential curve where only so much extra goody can be gotten before the law of dimenishing returns becomes burdensome.

 

Then, again, 100's of thousands or iterations may pass, as snicklin intimated and you'll suddenly notice an area of improvement as the program "surmises" a technique is usable for a specific area, etc and creates a new map.

 

So, the answer to your question: Theoretically, maybe, practically, probaby not.

 

(But don't take my word for it; I'm likely wrong about how the program works, ie , I left out mention of rasterization and assumed the other techniques.)

Edited April 21, 2012 by AtariNerd

[snicklin]

I've still got an execution running from last night. It is on 9.3 million evaluations!! (and it's looking very good)

[Synthpopalooza]

I had an idea ... I don't know how feasible this would be, but what if you used what I call PCIN (Programmable CIN) mode ... that is, it's like CIN mode, except that this time you alternate Graphics 15 with Graphics 10 (instead of 11) each scan line. You would be basically interlacing a Graphics 15 and Graphics 10 bitmap, which would allow for 36 colors per scanline at 160 pixel resolution. You would be choosing the best 36 colors for each scanline, and also possibly interlacing two DLI tables, one for each picture.

 

One requirement that would be needed for this mode is that you would either need to shift the Graphics 15 bitmap one color clock to the right, or alternate HSCROL each scanline so that the Graphics 15 lines are shifted one color clock right. This is because of the Graphics 10 pixel shift (like in the HIP and TIP modes), it is necessary to make sure Graphcis 15 and Graphics 10 line up properly.

[snicklin]

@AtariNerd,

 

Good explanation there - that is exactly how I understood it too. In short, it iteratively tries different layouts of pixels or PMGs, edging closer and closer to a lower distance that it can possibly achieve.

 

(Distance = A quotient for the difference between the picture it is processing and the right hand picture which is as perfect as an Atari could achieve if it had infinite colours)

[1NG]

I just tested it and it is great!

As you may know I work on similar things my hole life. From basic via assembler, C, C++ and now in C#.

I am very interested in the technique you are using now: What means that technical stuff while the calculations are running?

 

PushBach2Prev
Copy2NextLine
SwapWithPrevL

Is this Color changing or pixel? I have no clue.

 

Add Instr
Remove Instr
Swap Instr

This looks like organizing the color changes in the dli

 

Change Target
Change Value
Chg Val To Col

What are these for?

 

Norm. Distance looks like the Distance per Pixel (momalized), right?

Last Best is the number of the calculation with the lowest distance yet

Solutions: 1 seems to be constant

[snicklin]

You can change the Solutions value with the -s parameter on the command line.

[Creature XL]

 

6. I started recently CUDA programming so maybe in the future we will have this converter much faster

8. Multiprocessing won't increase the speed. The slowest part is execution of raster program and it can't be parallelized.

 

If it can not be parallelized then CUDA is no option. As far as I know the vector-computing efficiency of a (CUDA enabled) graphics card is not much better then on a modern CPU. Where CUDA stands out is when you can dispatch the task to 1000 Vector ALUs. Must admit though that my CUDA experience is 3 years old. There might have benn changes. Would be interested to hear about that.

 

However, I find it really cool that it seems to take hours on a modern PC to calculate an optimal A8 picture. I just found this thread and havent looked at the program. Do you try out every possible combination of GR15 and PMG and measure the "distance" from the original?

[AtariNerd]

I was mostly kidding, but it might be possible to vitualize a core on the highest-end cards that might get you a few times speed-up compared to a typical CPU. Highly impracticle, but maybe doable.. A bit mental, that.

[1NG]

You can change the Solutions value with the -s parameter on the command line.

Yes RTFM - I did that, but I was to excited to read it carefully

 

I was mostly kidding, but it might be possible to vitualize a core on the highest-end cards that might get you a few times speed-up compared to a typical CPU. Highly impracticle, but maybe doable.. A bit mental, that.

I am programming in c#, which has an easy parallel for and parallel foreach since .Net 4.0. And it works without gpu, but only with cpu-speed and that few cores. it has nearly no disadvantages even on only one CPU-core. Speedup is about factor 3 to 4 on my quadcore and was achieved very easily.

 

However, I find it really cool that it seems to take hours on a modern PC to calculate an optimal A8 picture. I just found this thread and havent looked at the program. Do you try out every possible combination of GR15 and PMG and measure the "distance" from the original?

What is the optimal picture? Optimal can be, if the eye recognizes the least possble differences for the graphics mode used. That can not be achieved by calculating all possible solutions - Simply because there are to many.

Choose 4 colors out of the possible 128 colors per line and combine them with the 5 available colors of player-missile graphics and place them at the best possible positions.

Limitations are: PM is only 8 pixels horizontal, but can have different width of one pixel at the screen

PM can be in front or behind the normal color which has different possibilities: a) smaller independent pixel or b) bigger area (width) of the color because a big block of the color is placed behind the 3 foreground colors. Every block has to be positioned on the right place.

Then dither the colors in an optimal way (not simple to do that afterwards or before the color choosing. Afterwards it affects the next line and previous calculating leads to more colors at all)

And that all has to melt down in an assemply-program that can be executed on the atari syncronized with the beam.

After all pixels, colors and PM-places are choosen the visible difference has to be calculated to analyze the solution.

And there is always something extra

This means, that it is not easy to get a program like RastaConverter wich does pictures in a forseeable time.

 

This means great work so far!

Edited April 22, 2012 by 1NG

[emkay]

I'm trying to pre-create the pictures, to make it "easier" for converting.

 

But I wonder, why the result always gets darker. I'm using "laoo" palette for every setting.

 

Input

 

 

Output

 

 

 

Input

 

 

Output

 

[snicklin]

@Emkay - Maybe they are the closest colours that the Atari has available? If not, maybe the RGB/YUV setting needs playing with?

[tebe]

@Emkay - Maybe they are the closest colours that the Atari has available? If not, maybe the RGB/YUV setting needs playing with?

/euclid
 Use Euclidian RGB distance for colors instead of default UYV distance.
 UYV produces usually better color mapping, but sometimes RGB distance is useful.