ilmenit Posted June 28, 2012 Author Share Posted June 28, 2012 The only reason why with 4 colours and /init=less any evaluations are needed is because still the sprites are randomly placed before the first line. They get however zeroed fast. Quote Link to comment Share on other sites More sharing options...
emkay Posted June 28, 2012 Share Posted June 28, 2012 (edited) With gif file and options: Beat me too it (first time around it actually got there in 7K evaluations ) png image converted to Laoo palette, tip: read the tutorial earlier on this thread regarding Timanthes. So the 1st error is pointed out. The palette usage. Using the different palette was intentional, because it shows 1 of several points , why the generator is wasting that much resources. Edited June 28, 2012 by emkay Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted June 28, 2012 Share Posted June 28, 2012 Err, you've forced it to by making it consider choices between colour distances, and did the dithering introduce any additional colours into the target picture? Quote Link to comment Share on other sites More sharing options...
emkay Posted June 28, 2012 Share Posted June 28, 2012 Err, you've forced it to by making it consider choices between colour distances, and did the dithering introduce any additional colours into the target picture? Well, not really necessary for a 4 colour picture. But it explains well, where optimisations really would be needed. Before, in this thread, I already mentioned to make the pictures fitting to the used palette, to have some clearer picture with less bandings. But Ilmenit always put that into the YUV space converter, which isn't really true there. The converter exploits the whole "available colour at resolution" and additionally it sorts colours wrong . So you get 1000s or even millions of dropped solutions. Quote Link to comment Share on other sites More sharing options...
ilmenit Posted June 28, 2012 Author Share Posted June 28, 2012 So the 1st error is pointed out. The palette usage. Using the different palette was intentional, because it shows 1 of several points , why the generator is wasting that much resources. You are wrong. Please paste here original picture that you have used in post #596 . If it is 4 colours then it should be converted 1:1 in less than 20K evals on average with proper command line parameters. Quote Link to comment Share on other sites More sharing options...
ilmenit Posted June 28, 2012 Author Share Posted June 28, 2012 Before, in this thread, I already mentioned to make the pictures fitting to the used palette, to have some clearer picture with less bandings. But Ilmenit always put that into the YUV space converter, which isn't really true there. What you write is not true. I even wrote a tutorial some posts ago how I convert pictures to a destination palette when the default proprocess gives unacceptable results. Quote Link to comment Share on other sites More sharing options...
potatohead Posted June 29, 2012 Share Posted June 29, 2012 (sigh) Quote Link to comment Share on other sites More sharing options...
emkay Posted June 29, 2012 Share Posted June 29, 2012 (edited) Before, in this thread, I already mentioned to make the pictures fitting to the used palette, to have some clearer picture with less bandings. But Ilmenit always put that into the YUV space converter, which isn't really true there. What you write is not true. I even wrote a tutorial some posts ago how I convert pictures to a destination palette when the default proprocess gives unacceptable results. You mean that picure with large regions being overlaid with banding? What you have done there is to adjust the colours to a value of colour changes that cannot be handled and result in the banding again. And not really adjust the palette to a workable picture with a clear image. Btw. How long did it take to have the "final" picture there? You only can get there with some "real iteration calculation".... Produce the 1st image, check the colour count, adjust the colour count, recalculate the picture.... until the colour count fits to have the image with some low banding. And then, that "unsharp" colour sorting has to be adjusted. What can help to speed things up, is to "index all available colours" and set every value darker or brighter, to have the used colour set to the best point. Those rules of the colour converter and the import-code don't really work together. They do contrary until some trigger point is reached. Edited June 29, 2012 by emkay Quote Link to comment Share on other sites More sharing options...
analmux Posted June 29, 2012 Share Posted June 29, 2012 (edited) But, emkay, how to do it 'better' then? Do you have the knowledge of the needed techniques then? OK, not everything will work excellently, using these techniques of local maxima. But, do you have better & faster alternatives? ... or solutions for altering the existing & used techniques? It's not that simple as you might think. Edited June 29, 2012 by analmux 3 Quote Link to comment Share on other sites More sharing options...
emkay Posted June 29, 2012 Share Posted June 29, 2012 OK, not everything will work excellently, using these techniques of local maxima. But, do you have better & faster alternatives? ... or solutions for altering the existing & used techniques? It's not that simple as you might think. I might be easier than you think. The converter is able to check the image "quality" and the importer is able to check the available colours and changes per scanline. Several cross checks can allow to approximate the possible colours per scanline and to adjust the image resolution. As I wrote, the combination of the "both routines" jumps over simply changeable colours. As the value of a light pink is somehow eaqual to a gray in the same brightness. The line is checked wrong by colour, the amount of changeable registers is more than "free" because the rest of the line is black.... The only way right now is to put a full false colour there... and put the colour back after the region is affected. So the line gets corrected in some seconds, when it otherwise takes "days"... Quote Link to comment Share on other sites More sharing options...
emkay Posted June 29, 2012 Share Posted June 29, 2012 (edited) One solution of keeping the details is to put a picture into several bit depths. 2 bit to 6 bit, for example... 4, 8, 16, 32 ,64 .... indexed to the Atari palette. And calculate them until a changing rate is getting low. Then put the next higher bit picture there .... until the max is reached. Look at this image.... 2M evals. All necessary details are there, you see even the small antenna in the background, and the picture got over 50 colours with a low banding. Edited June 29, 2012 by emkay Quote Link to comment Share on other sites More sharing options...
emkay Posted June 30, 2012 Share Posted June 30, 2012 Another example.... 5M evals. The result: 34 colours. Details still there , banding low. You see the birds, the ropes, you have the clear shape of the boatsman and the leaves distinguish into green. Quote Link to comment Share on other sites More sharing options...
emkay Posted June 30, 2012 Share Posted June 30, 2012 After an image is captured with the most possible details, Quantizator can run until the colours get the best fit there, and possibly all disturbing banding is removed. 5 bit depth seems the best value. Quote Link to comment Share on other sites More sharing options...
ilmenit Posted June 30, 2012 Author Share Posted June 30, 2012 OK, not everything will work excellently, using these techniques of local maxima. But, do you have better & faster alternatives? ... or solutions for altering the existing & used techniques? It's not that simple as you might think. I might be easier than you think. The converter is able to check the image "quality" and the importer is able to check the available colours and changes per scanline. Several cross checks can allow to approximate the possible colours per scanline and to adjust the image resolution. As I wrote, the combination of the "both routines" jumps over simply changeable colours. As the value of a light pink is somehow eaqual to a gray in the same brightness. The line is checked wrong by colour, the amount of changeable registers is more than "free" because the rest of the line is black.... The only way right now is to put a full false colour there... and put the colour back after the region is affected. So the line gets corrected in some seconds, when it otherwise takes "days"... Does anyone understand this and could explain it in other words? If not, is there a plonk option? 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted June 30, 2012 Share Posted June 30, 2012 Does anyone understand this and could explain it in other words? If not, is there a plonk option? Full details in less than 20M instead of waiting for 2000 Million evaluations. You understand that? If not, plonk yourself. Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted June 30, 2012 Share Posted June 30, 2012 Does anyone understand this and could explain it in other words? I'm quite sure he means that you should upgrade the 'hill climbing' algorithm to a 'branch-and-bound' one, so that it no longer gets stuck in a local maxima... ...but I could be wrong... Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted June 30, 2012 Share Posted June 30, 2012 The converter is able to check the image "quality" That Emkay seems to be the problem. Yes, the converter checks that, but you have to find a mathematical representation for the check (e.g. min-distance in YUV colour space). That this min PSNR does not automatically fits to your image emphasis requirements is quite clear. So the 'red moon' doesn't fit so well, even it forms a min-distance. If you put your emphasis on the moon by appling a false colour, the min-distance calculation has to follow your emphasis. There is nothing wrong with the calculation. Scientist wrote theses about mathematical representations of the human visual reception - that is not something you can just implement from scratch. Since you resulting images look quite good, it may could be helpful if you just describe your steps to get these results and we can estimate if these are imitable by an algorithm. Things are sometimes not so easy as they seem... Quote Link to comment Share on other sites More sharing options...
emkay Posted June 30, 2012 Share Posted June 30, 2012 Does anyone understand this and could explain it in other words? I'm quite sure he means that you should upgrade the 'hill climbing' algorithm to a 'branch-and-bound' one, so that it no longer gets stuck in a local maxima... ...but I could be wrong... I was referring to this picture: the pink colour stood in line across the grey for several 100Mil evals. In the range where mostly black is used. sam.xex after putting a strange colour in ,,, and turn it back, the lines became well. Quote Link to comment Share on other sites More sharing options...
ilmenit Posted June 30, 2012 Author Share Posted June 30, 2012 (edited) after putting a strange colour in ,,, and turn it back, the lines became well. In this case you pointed exactly where to disturb the local optimum, because visually (for you) that was the place where it should happen. RastaConverter is created to solve complex problems (huge search space), where midline color changes and sprite repositioning is needed. For simple cases of low color pictures totally different techniques can be faster. Even some brute-force algorithm could work. Edited June 30, 2012 by ilmenit Quote Link to comment Share on other sites More sharing options...
AtariNerd Posted June 30, 2012 Share Posted June 30, 2012 (edited) Heh, that's interesting. Does the convertor automatically limit the number of evaluations to around 2 billion? I'm guessing, maybe, the memory profile starts to become problematic above a certain point? There is an image that I've been playing with and I've let grind away in the background for some time. My last save was about 20 million or so below the 2BN point. Windows restarted due to an update and when I went to continue the program, afer calculating for a few seconds, it konked out, showing the calculations at the 2BN mark. It's no problem, as that is a supercillious amount of calculations and the point of diminishing returns was well past, reaching between 20-42M evaluations, sometimes, between normative progressions.. It's just a curious thing. Edited June 30, 2012 by AtariNerd Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted June 30, 2012 Share Posted June 30, 2012 (edited) Heh, that's interesting. Does the convertor automatically limit the number of evaluations to around 2 billion? Signed integer (iterator) overflow? (>2^31 (32 bit ints)) I'm guessing, maybe, the memory profile starts to become problematic above a certain point? AFAIK memory should not be a problem: Only the best solution is 'saved'. Edited June 30, 2012 by Irgendwer Quote Link to comment Share on other sites More sharing options...
emkay Posted June 30, 2012 Share Posted June 30, 2012 after putting a strange colour in ,,, and turn it back, the lines became well. In this case you pointed exactly where to disturb the local optimum, because visually (for you) that was the place where it should happen. LOL 60% is the local optimum? Now it is at the local optimum there. The optimum doesn't get reached without "help from outside" due to weird rules. RastaConverter is created to solve complex problems (huge search space), where midline color changes and sprite repositioning is needed. For simple cases of low color pictures totally different techniques can be faster. Even some brute-force algorithm could work. At the current state the converter prefers "killing of the image content" to have a colour more, which results always in unsolvable rules. Alike if C64 pictures or from true colour space. Quote Link to comment Share on other sites More sharing options...
ilmenit Posted June 30, 2012 Author Share Posted June 30, 2012 This is amazing... You don't even know how ignorant you are... 7 Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 30, 2012 Share Posted June 30, 2012 LOL 60% is the local optimum? Now it is at the local optimum there. The optimum doesn't get reached without "help from outside" due to weird rules. Local optimum has a very specific meaning. hint: it's not what you think it is. 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted June 30, 2012 Share Posted June 30, 2012 This is amazing... You don't even know how ignorant you are... Look in the Mirror. 5 Bit Graphics. Details that do not get sorted from the start, will be added "soon" ... or not. While very parts of an import gets destroyed. Jämmerlich zusammengeklepmnert. That's the word in german , how the converter and the importer work together. I really wonder sometimes, how people manage to pull things off the hat, without knowing what they do. Instead of thinking of optimisations, you start being offending though. The converter only can search for the correct colour, if it knows where a colour is needed, and a detail gets drawn, after.... a black hole is sucking randomly in space.... Keep the image stable from the beginning and everything will be fast there. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.