Quantizator

[phaeron]

I found one thing that's breaking /continue: the raster program loader is dropping NOP instructions. Fixing this doesn't solve all of the glitches but it makes situation a lot better.

 

There's also a bug in the mutator that affects several of the operations:

  	 do
       {
           i2=random(prog.instructions.size());
       } while (i1!=i2);

 

That should be an ==. This neutralizes the swap instruction op and also affects the change value to color op, as well as wastes some CPU time. I don't know what the impact of this is; fixing the bug doesn't seem to have made much difference overall, unfortunately.

[matosimi]

just a quick question... when starting the patched turbo version with picname.png /dither=chess it seems that it does not dither the pic? only the destination pic seems to get dithered?

Yes right, I just tried this turbo-optimized version and it kills all dithering. Result is very inaccurate comparing to slow versions.

[AtariNerd]

Accurate in a different way. What I've tended to notice is that the destination pic on the unpatched version tends to be more accurate to the source pic, giving the image more colors. Early in use it gives a nicer look with the arbitrary dithering, but ithe destination image is unattainable and the created picture in practice uses fewer colors and starts to eventually lose the dither as it works on the finer details. I find the patched versions give a more realistic possible destination image, using fewer colors and that in practice the created image on both the patched and unpatched versions match better the projected destination image on the latest patched versions. Eventually the image naturally starts to dither again, but it is a longer, drawn-out process. I think given the new dash of speed, the default dithering doesn't matter nearly as much, but depending on the type of image and tastes may achieve certain results a little quicker in some instances.

Edited May 6, 2012 by AtariNerd

[emkay]

The latest tool has some weird "features" aka bugs.

 

One time it stops working

other time it works better than awaited

then it puts strange colours in a pic ( 100% conform to the used palette) that has not been in the original....

And.... some parts of a picture seems simply to be overseen. You can wait "300Million" evaluations and nothing happens there ....

 

hmm....

Edited May 6, 2012 by emkay

[1NG]

The new version shows what is possible in speed. It geneates usable pictures a lot faster. It is very good for the old-style computer graphics pictures and not so good on the natural ones with to much colors. Maybe that improves if ilmenits holiday (without internet) is over in a few days.

 

And it looks like the team work here is leading to a wonderful program. Great!

 

BTW: The sources doesn´t compile on my computer with VS C++ 2005 or 2008. It seems that the including paths are not right. And if I change them the platform is unknown. Has anyone a complete source which compiles out of the box?

[andym00]

The latest tool has some weird "features" aka bugs.

 

One time it stops working

other time it works better than awaited

then it puts strange colours in a pic ( 100% conform to the used palette) that has not been in the original....

And.... some parts of a picture seems simply to be overseen. You can wait "300Million" evaluations and nothing happens there ....

 

hmm....

 

Make sure you use the box filter, that was my mistake where the source image that was 320x200 fat-pixels with the right palette, was still getting resampled with the lanczos default filter, and generating lots of very subtle extra colours, that meant it appeared to home in on a good result quickly, but then rapidly lost the plot totally.. I only realised this 10 minutes ago, when I was getting ready to post, and noticed my capture had too many shades in it, and at 1:1 pixel resolution in my screen, I just hadn't noticed this very subtle extra shades being added..

[AtariNerd]

I've been resampling all of my images by default to 160 pixels wide (maintaining the 200 or 240 pixel height , in relative proportion), adding some color saturation and then on some softer images, using a subtle unsharp mask to make some of the pixels edges a little more "findable". Seems to map more readily that way.

Edited May 6, 2012 by AtariNerd

[phaeron]

Here's an optimized version with some bug fixes:

• Fixed dithering not being taken into account -- the error map I added was being inited too soon, before the dithering had taken place.
  
• /continue now reloads NOPs in the raster instruction lists.
  
• Fixed bug where the first mutation after a /continue was always accepted unconditionally, because the score for the loaded solution wasn't evaluated. I think this may have been in the original build as well, although I don't have a buildable version of it to check.
  

There are still some discrepancies in the score after /continue... I'm going to see if I can track down the remaining problems.

Rasta-opthack3.zip

[frogstar_robot]

Here's an optimized version with some bug fixes:

• Fixed dithering not being taken into account -- the error map I added was being inited too soon, before the dithering had taken place.
  
• /continue now reloads NOPs in the raster instruction lists.
  
• Fixed bug where the first mutation after a /continue was always accepted unconditionally, because the score for the loaded solution wasn't evaluated. I think this may have been in the original build as well, although I don't have a buildable version of it to check.
  

There are still some discrepancies in the score after /continue... I'm going to see if I can track down the remaining problems.

 

Source patched to build on Linux. 64 bit amd64 binary included.

rastahacklinux.tar.gz

[phaeron]

 

Another version of the speed hack:

• I integrated the Linux portability changes... hopefully the delta should be smaller now.
  
• Fixed an uninitialized variable bug that sometimes prevented the (s)ave command being recognized after a /continue.
  
• The swap mutation bug noted above is fixed in this version.
  
• A .csv file is now written out with statistics for time and distance score relative to evaluation count.
  
• The raster program (.rp) file now contains the distance score.
  

Rasta-opthack4.zip

xelloss.xex

[matosimi]

Nice job phaeron!

I was afraid that dithering was removed intentionally to speed up processing.

[ilmenit]

Another version of the speed hack:

• I integrated the Linux portability changes... hopefully the delta should be smaller now.
  
• Fixed an uninitialized variable bug that sometimes prevented the (s)ave command being recognized after a /continue.
  
• The swap mutation bug noted above is fixed in this version.
  
• A .csv file is now written out with statistics for time and distance score relative to evaluation count.
  
• The raster program (.rp) file now contains the distance score.
  

 

Phaeron, your improvements are great! You already optimized the coded more than I planned to

I will take a look at the code soon and probably some source code repo (sf.net? github?) should be created.

It is so cool to return home to see that the project started to live it's own life without my hands on it.

 

regards,

Jakub

[emkay]

The things gets better and better

 

Is it possible to add a function for 48bytes width? To have a clean border and usable PMg?

 

[emkay]

The pictures get more impressive, if as less as possible transitions got used.

 

 

 

blood.xex

 

 

[w1k]

what options of converting youre using?

 

RastaConverter.exe c64.png /filter=box /h=200 /pal=palettes\laoo.act

[emkay]

what options of converting youre using?

 

RastaConverter.exe c64.png /filter=box /h=200 /pal=palettes\laoo.act

 

I go 2 steps. Use the preferred settings....

 

1. step : add /dither=none : start converting and stop after some seconds

 

2. step: Re-use the destination picture with the change: /dither=chess

 

It's the best ways right now to use the most correct "colour-room".

But some picture would need some additional dither in dedicated ranges. This could be done per hand, after G2f and the RastaConverter can interchange the data.

 

 

 

[emkay]

15-20 minutes.... still going on

 

entenpreis.xex

 

 

 

[w1k]

ok, rasta generates files, but no XEX file

[emkay]

ok, rasta generates files, but no XEX file

put all the produced file into the folder "generator" and click on build.bat

[ivop]

Linux users need this small patch and add -std=c++0x to CXXFLAGS (needed for the auto keyword).

Great work Phaeron and thanks for including the portability patches.

patch.zip

Edited May 7, 2012 by ivop

[Heaven/TQA]

what about osx?

[w1k]

emkay:

i have BAT:

r.exe 1.jpg /filter=box /h=200 /pal=laoo.act

 

but i dont see any XEX file

[RevEng]

It's a different BAT to build the xex, named build.bat. Look in the generator directory.

 

I added the following line to build.bat so I don't have to manually copy over the output files: copy ..\output*.* .

[Heaven/TQA]

as people told me when I asked that, too. read the f**king manual the original archive contais a readme where it is described. when pic saved copy all "output*.*"-files into generator folder and then double click the bat file. that's it.

[flashjazzcat]

One I've just started playing with.

 

Just tried this on a real machine, and I must say I can hardly believe we're seeing such wonderful images on stock video hardware. This is a superb project.