1NG #126 Posted April 23, 2012 For the sources for the previous version, take a look at the attached version 0.9 a few pages back. Thank you, but as far as I understand the aproaches and the sources are very different: Quantizator works different than RastaConverter. And version numbers are totally different, too I think that RastaConverter is younger and looks better . (Because ilmenit has a lot of experience and the result is getting better each new generation) I can´t wait to have a look at the source of the new generation and to learn from that! Quote Share this post Link to post Share on other sites
NRV #127 Posted April 23, 2012 For the sources for the previous version, take a look at the attached version 0.9 a few pages back. Thank you, but as far as I understand the aproaches and the sources are very different: Quantizator works different than RastaConverter. And version numbers are totally different, too I think that RastaConverter is younger and looks better . (Because ilmenit has a lot of experience and the result is getting better each new generation) I can´t wait to have a look at the source of the new generation and to learn from that! I believe he was talking about this: http://www.atariage....ost__p__2504806 There is a link to rastaconverter 0.9 with source there. Quote Share this post Link to post Share on other sites
+AtariNerd #128 Posted April 23, 2012 (edited) I'm running this on an older laptop, as that is the only computer guaranteed to be free, around here. It's a 1ghz, single-core, single-threaded machine, so the process is a relatively slow one. In reference to how long it takes to get an optimized image, mileage seems to vary. Right now, I'm working on a image of the Simpsons that i think it is theoretically possible to get a near-exact replica of and have around 5 Million perturbations logged so far. I am going to attempt to see how far it takes to get close or at least until I give up. Since it's mainly non-dithered, it's easy to see any non-conformities.. So far, here is what I have. I'll post the binary when I'm ready to call it quits. This might be a good example of just how far it might take to get a faithful approximation of a screen ported from another 8-bit machine, given enough patience. Kind of humbling. Edited April 23, 2012 by AtariNerd Quote Share this post Link to post Share on other sites
+Philsan #129 Posted April 23, 2012 I am converting two images: 12 and 8 million evaluations so far... Quote Share this post Link to post Share on other sites
snicklin #130 Posted April 23, 2012 I believe he was talking about this: http://www.atariage....ost__p__2504806 There is a link to rastaconverter 0.9 with source there. You are correct! Quote Share this post Link to post Share on other sites
+AtariNerd #131 Posted April 23, 2012 (edited) I am converting two images: 12 and 8 million evaluations so far... Math can be beautiful. Edited April 23, 2012 by AtariNerd Quote Share this post Link to post Share on other sites
snicklin #132 Posted April 23, 2012 My PC and a laptop have not been switched off for several days while playing with this. This is the most unenvironmentally friendly program that has been developed on here! Quote Share this post Link to post Share on other sites
Bryan #133 Posted April 23, 2012 This really makes me wonder how you would optimize a routine to quickly find the "best possible line" given all the bitmap/PMG/mid-line-store combinations. Then factor in the PRIOR bits and make it try to hide errors by choosing the least offensive colors for mis-colored regions... Sounds like a real AI programming challenge to me. Quote Share this post Link to post Share on other sites
+Philsan #134 Posted April 23, 2012 Today my wife said: "why is the computer so slow?" Quote Share this post Link to post Share on other sites
1NG #135 Posted April 23, 2012 I believe he was talking about this: http://www.atariage....ost__p__2504806 There is a link to rastaconverter 0.9 with source there. You are correct! My fault, excuses to you. And thanks, because I have already seen very interesting stuff! The antic2cpu and vice versa is also part of the atari800 emulator - Of course, it has to emulate it. Quote Share this post Link to post Share on other sites
emkay #136 Posted April 24, 2012 I guess , I know why the pictures doesn't get to a final state. The dithering, doesn't work as it should. You see the brighter colour getting into the darker colour. But the "heaps" get bigger and should get smaller/ more distorted. This would explain why sometimes lines stay in the graphics and wouldn't be needed to be there. Quote Share this post Link to post Share on other sites
emkay #137 Posted April 24, 2012 This one is a direct import/conversion using standard dithering with the given resolution and the 128 Atari.colours. Quote Share this post Link to post Share on other sites
+AtariNerd #138 Posted April 25, 2012 (edited) This is a marvelous program and its' creator is aces for creating it and tolerating our shenanigans. Laptop crashed on the other image so decided to restart anew. Currently working on a image that has a norm distribution of now just under 5, done with only 100,000 evaluations,spent while still on the old foresaken laptop. I'm cheating a bit...It's a monochrome image and I'm going for a medium-res, multishade effect. Seems to be going much faster than the previous full-color images, for likely reasons..It's looking good so far, but I wish I had optimized the image better before-hand. Maybe an optimized, monochrome-only mode could be an option. Edited April 25, 2012 by AtariNerd Quote Share this post Link to post Share on other sites
+AtariNerd #139 Posted April 25, 2012 Guess, I shouldn't tease..not bad, so far. Quote Share this post Link to post Share on other sites
ilmenit #140 Posted April 27, 2012 RastaConverter Beta3 attached. Big improvements in optimization heuristics and "continue" option are two main features in this version. Tomorrow I'm going on holidays for 10 days so I publish it without other promised features. Beta3: - New dithering algorithms - Changed command line parameters for dithering - Improved mutation heuristics (more accurate) - Changed default init behavior from smart to random - Improved random initialization - Preview for the destination picture and rescaled source picture (saved into files) - On big enough desktops displayed pictures in the app have proper proportions - Resuming of process added - Conversion in Beta3 is MUCH faster than in Beta2 and overal picture quality is better. RastaConverterBeta3.zip 4 Quote Share this post Link to post Share on other sites
emkay #141 Posted April 27, 2012 That's a progress Quote Share this post Link to post Share on other sites
emkay #142 Posted April 27, 2012 Approx. 15 minutes for this quality: Over 40 colours and recognizable.... Quote Share this post Link to post Share on other sites
1NG #143 Posted April 27, 2012 (edited) RastaConverter Beta3 attached. Big improvements in optimization heuristics and "continue" option are two main features in this version. ...[lots of things] That is awesome! I had some ideas after looking at the old source but was´nt able to write you before you did it? Great! Have a nice holyday! Edited April 27, 2012 by 1NG Quote Share this post Link to post Share on other sites
snicklin #144 Posted April 27, 2012 Brilliant! I haven't checked it yet as I am on a library computer on my works lunchtime, but I will do so when I get home. Quote Share this post Link to post Share on other sites
Irgendwer #145 Posted April 27, 2012 RastaConverter Beta3 attached. Big improvements in optimization heuristics and "continue" option are two main features in this version. Very nice. I also had a quick look into the sources and performed a profiler run. I think the process can be speed-up drastically if you always work in YUV colour space. According to the profiler RGBtoYUV takes 50%. A single conversion at the start (picture & palette to YUV) and back at the end, could IMHO save this time. I also would avoid the 'double'-math. I think nothing would break if the distances are handled as 'int'. Nice work! Quote Share this post Link to post Share on other sites
ilmenit #146 Posted April 27, 2012 (edited) Very nice. I also had a quick look into the sources and performed a profiler run. I think the process can be speed-up drastically if you always work in YUV colour space. According to the profiler RGBtoYUV takes 50%. A single conversion at the start (picture & palette to YUV) and back at the end, could IMHO save this time. I also would avoid the 'double'-math. I think nothing would break if the distances are handled as 'int'. Both ideas are good. The first one may bring a nice boost :-) I have also tried different caches for the distance function (small cache for the last colors and the whole map of distances) but direct calculations were faster than using the cache. Edited April 27, 2012 by ilmenit Quote Share this post Link to post Share on other sites
Irgendwer #147 Posted April 28, 2012 (edited) I have also tried different caches for the distance function (small cache for the last colors and the whole map of distances) but direct calculations were faster than using the cache. That's always a problem. Using a cache may break access to the CPU cache and timings get much more worse accessing memory: Only important optimization goal these days • Use mul instead of shift: 5 cycles penalty. • Conditional branch mispredicted: 10 cycles. • Cache miss to main memory: 250 cycles. (from http://dl.fefe.de/optimizer-isec.pdf) A last thing I recognized doing my quick review are the updates to the screen (AFAIR the '%300' thing): Since writing to the screen is quite costly (OS call, trap), screen updates could alternatively be triggered when the user hits a key or the distance drops about a specific delta. This could get even more important if the bitmap is held in YUV space and displaying needs a conversion first. Keep up this interesting project and enjoy your holidays! Edited April 28, 2012 by Irgendwer Quote Share this post Link to post Share on other sites
emkay #148 Posted April 28, 2012 (edited) Almost 12million iterations. 24 colours, up to 8 colours per scanline, all 8 grey (incl. b/w)lumas used. Some bright light flooding the tree, the green and brown colours remove slightly the darkness around the tree. Nice type of "Atari 8 bit Art", I'd say. Original picture is from the Amiga Game Agony. It's still not the upper limit. Edited April 28, 2012 by emkay Quote Share this post Link to post Share on other sites
+AtariNerd #149 Posted April 28, 2012 (edited) emkay, come back when you've reached 100,000,000 permutations ... The first 70% goes relatively quickly, while probability plays its hand as time progresses and as more of the image is optimized, the longer it takes to see progress. . Some areas will still seem relatively untouched, while some are polished. I'm not sure what the Atari's limits are or how this software goes about determining them, so one may be waiting in vain..Maybe, if there were some sort of little indicator to pop up stating that we are getting pretty close to the theoretical limit...say within 5% or less of Atari resources... Heck, maybe it does already and I've just never have gotten that far? It might be we just have to get used to some imperfection and be willing to go in by hand and retouch through some sort of editor. (Sometimes, autocorrect is a real pain.) Edited April 28, 2012 by AtariNerd Quote Share this post Link to post Share on other sites
matosimi #150 Posted April 30, 2012 Hi, I'm experiencing this kind of issue: I tried rasterizer on my two computers and it worked ok, but then I uploaded it to computer at my work (which is more powerfull and runs 24x7 ) and got these scrabled pallettes. I haven't tried it personally there... I mean, I was remotely connected through RDP and also tried teamviewer, but both gave me this result... so I think it has nothing to do with this "remote access" tools. I'll be at work on wednesday so I'll check it there. Does anyone else have similar issue? Martin Quote Share this post Link to post Share on other sites