ilmenit Posted July 24, 2012 Share Posted July 24, 2012 (edited) I guess Emkay mentioned "HAM"-like, too. I only know HAM decades ago while using Personal Paint on my A1200. It is more like Spectrum512 Edited July 24, 2012 by ilmenit Quote Link to comment Share on other sites More sharing options...
ilmenit Posted July 24, 2012 Share Posted July 24, 2012 Superheroes time :-) ilmenit_iron_man.xex Quote Link to comment Share on other sites More sharing options...
+Stephen Posted July 25, 2012 Share Posted July 25, 2012 Just for giggles - I have no idea where the original came from, and it was actually smaller than the A8 resolution - I think it was an avatar on some random forum. This is 10 million evals, no dither, laoo pallette. Mullets Rock (10 million).xex Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted July 25, 2012 Share Posted July 25, 2012 One of mine ... Original: Rasta: synthpopalooza - bridgestream.xex Still working out how to use this tool ... I noticed I am getting a lot of greenish blues in this render, The Rasta was at 8 million evaluations ... my patience is not as good as some people I guess. By comparison, I rendered the same picture in MIN (Graphics 12 + 9 interlace, 5 chroma x 16 luma, 192 scanlines): bridge stream.atr Which has led me to a thought ... could Rastaconverter be improved, by adding inline GTIA mode changes to Graphics 10 or 9? You'd lose on the resolution some, but in some areas of the picture maybe it's not as big an issue? Maybe even introduce 16 level shading in some parts of the picture? Quote Link to comment Share on other sites More sharing options...
ilmenit Posted July 25, 2012 Share Posted July 25, 2012 (edited) Still working out how to use this tool ... I noticed I am getting a lot of greenish blues in this render, The Rasta was at 8 million evaluations ... my patience is not as good as some people I guess. The default CIEDE2000 color distance increases saturation of grayish colors, which is usually better for conversion (/predistance=yuv or /predistance=euclid would cause output picture almost grey). Use any dithering option to spread the error over picture to get much better result: Which has led me to a thought ... could Rastaconverter be improved, by adding inline GTIA mode changes to Graphics 10 or 9? You'd lose on the resolution some, but in some areas of the picture maybe it's not as big an issue? Maybe even introduce 16 level shading in some parts of the picture? It could be done but I doubt it will look good without interlace. I have done those tests in the past: http://atarionline.p...nID=1514&page=1 http://atarionline.p...tachmentID=1552 Edited July 25, 2012 by ilmenit Quote Link to comment Share on other sites More sharing options...
ilmenit Posted July 25, 2012 Share Posted July 25, 2012 joker.xex batman.xex Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 25, 2012 Share Posted July 25, 2012 Here's the lovely Lenna. 295 million evaluations, floyd dither, laoo palette, s=10000. I used a detail mask covering her eyes, nose, and shading of the cheeks. RevEng_Lenna.xex 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted July 25, 2012 Share Posted July 25, 2012 I think I may have found a bug in the latest version. I am including a ZIP of all the output files. I ran the image using ciede, no dither, 1000 solutions, altirra palette, and selected the "only use colours in picture" option. The output .png turned out great, but the generated image has big colour bars running through it. Original author unknown I tried this on both Altirra and Atari800Win+ and the results are the same DJT.xex Here's all the output files DJT 89 million evals.zip Quote Link to comment Share on other sites More sharing options...
ilmenit Posted July 25, 2012 Share Posted July 25, 2012 Can you post the DJT_Indexed.png ? For /picture_colors: 1. /filter=box should be used, because default resize filtering (lanczos) produces additional colours on the destination picture 2. /distance=ciede is probably not needed (it will only slow the process) Quote Link to comment Share on other sites More sharing options...
+Stephen Posted July 25, 2012 Share Posted July 25, 2012 Can you post the DJT_Indexed.png ? For /picture_colors: 1. /filter=box should be used, because default resize filtering (lanczos) produces additional colours on the destination picture 2. /distance=ciede is probably not needed (it will only slow the process) Here's the source file. Quote Link to comment Share on other sites More sharing options...
ilmenit Posted July 25, 2012 Share Posted July 25, 2012 Here's the source file. Thanks. The logic implemented in /picture_colors is somehow wrong. I will take a look into that. Quote Link to comment Share on other sites More sharing options...
thealgorithm Posted July 25, 2012 Share Posted July 25, 2012 A great innovative tool ilmenit. Good quality images considering the limitations of the atari mode. Some questions as below Have you considered brute forcing without sprites initially, then to start the genetic selection after based on sprite underlay/overlay position/color (would be good to have that as an option). Can the atari sprites be shifted at a different offset (eg in 160x240 display at x2 horizontal resolution, able to shift sprites to odd pixels (if so can somewhat be able to get 320x240). I have idea's for a c64 tool using genetic selection, however on the c64 it is easy enough to have sprites covering the entire screen (4 pixel wide however) at high quality. Although the ability to have hires/mcol non expanded where suitable would increase quality somewhat. Quote Link to comment Share on other sites More sharing options...
ilmenit Posted July 25, 2012 Share Posted July 25, 2012 (edited) Have you considered brute forcing without sprites initially, then to start the genetic selection after based on sprite underlay/overlay position/color (would be good to have that as an option). As estimated here http://www.atariage....75#entry2548993 even for single line bruteforcing would be too time consuming. Without sprites it would be: 1 (NOP) + 3 (LDx)*128 colors + 3*(STx)*4 regs = 397. 17 instructions on average in line = 397^17 = 10^44 combinations. RastaConverter uses single color quad size sprites. According to the sprites and playfield priorities sometimes they are good to cover bigger areas with a single color, sometimes to increase details. Currently used Late Acceptance Hill Climbing prefers solutions with a big improvements on the picture, so at the beginning algorithm covers large areas quickly and then focuses on details. In Beta5 you can observe this as progressive increase of details. What is great it works totally automatically. Can the atari sprites be shifted at a different offset (eg in 160x240 display at x2 horizontal resolution, able to shift sprites to odd pixels (if so can somewhat be able to get 320x240). Not as far as I know. Anyone? I have idea's for a c64 tool using genetic selection, however on the c64 it is easy enough to have sprites covering the entire screen (4 pixel wide however) at high quality. Although the ability to have hires/mcol non expanded where suitable would increase quality somewhat. I've tried genetic algorithm first but it was slow to evaluate big population and I was not able to remove problem of premature convergence. http://www.atariage....00#entry2554192 Edited July 25, 2012 by ilmenit Quote Link to comment Share on other sites More sharing options...
thealgorithm Posted July 25, 2012 Share Posted July 25, 2012 If 4 colors can be displayed perscanline then would it not just be all combo's and error difference measured. for example on the c64 it would be something similar to color 0,1,2,3, color 0,1,2,4.... color 0,1,2,f... color 0,1,3,4.. ensuring that there are no repeated colors then code can be generated after based on the colors rendered. ofcourse on the atari this would take longer due to more 120 colors instead of 16 I dont know anything about how the atari generates its images however. perhaps previous colors have influence on next line etc. But even in interlaced format using combinations of multicolor/hires and all possible combo's, i was able to convert the image via pure brute force and luma masking etc in less than 10 minutes. See attached 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted July 25, 2012 Share Posted July 25, 2012 Latest conversion, 226 million evals, knoll dither, 1000 solutions, laoo palette, yuv colourspace. Enclosing in a spoiler tag as it may be moderately NSFW. It's a FLIR scan for cancer. Original Image: Attempted Destination Actual Output FLIR 226 Million evals.xex Quote Link to comment Share on other sites More sharing options...
+Stephen Posted July 25, 2012 Share Posted July 25, 2012 If 4 colors can be displayed perscanline then would it not just be all combo's and error difference measured. for example on the c64 it would be something similar to color 0,1,2,3, color 0,1,2,4.... color 0,1,2,f... color 0,1,3,4.. ensuring that there are no repeated colors then code can be generated after based on the colors rendered. ofcourse on the atari this would take longer due to more 120 colors instead of 16 I dont know anything about how the atari generates its images however. perhaps previous colors have influence on next line etc. But even in interlaced format using combinations of multicolor/hires and all possible combo's, i was able to convert the image via pure brute force and luma masking etc in less than 10 minutes. See attached That's awesome - looks as good as a Spectrum512 image on the ST! Quote Link to comment Share on other sites More sharing options...
ilmenit Posted July 25, 2012 Share Posted July 25, 2012 (edited) If 4 colors can be displayed perscanline then would it not just be all combo's and error difference measured. Minimum 4 colours are available per scanline, but RastaConverter is synchronized with screen draw and for the best effect it changes colours in line and does the same with sprite color and sprite position (multiplexing). With 4 basic colours and 4 sprites in good conditions it can reach about even 15 colours in line. It however depends where those changes happen in line and then - those changes influence possibilities to set colours and sprites in the following line, causing the problem to be (probably) NP complete. Edited July 25, 2012 by ilmenit Quote Link to comment Share on other sites More sharing options...
thealgorithm Posted July 25, 2012 Share Posted July 25, 2012 Ofcourse the possibile combo's with what you mentioned would result in taking too much time when brute forcing, however if you exclude the sprites from the equation and then just treat each line and select optimum 4 colors for each line, and then to start the other combinations and include sprites, via the hill climbing method after, how would the results be in comparison to starting everything without brute force? Quote Link to comment Share on other sites More sharing options...
ilmenit Posted July 25, 2012 Share Posted July 25, 2012 That's awesome - looks as good as a Spectrum512 image on the ST! True, but this is an interlace. Well... Implementing interlace for RC should not be hard... It would be great if somebody could point me some good reading about PAL and NTSC color mixing for interlace Quote Link to comment Share on other sites More sharing options...
ilmenit Posted July 25, 2012 Share Posted July 25, 2012 Ofcourse the possibile combo's with what you mentioned would result in taking too much time when brute forcing, however if you exclude the sprites from the equation and then just treat each line and select optimum 4 colors for each line, and then to start the other combinations and include sprites, via the hill climbing method after, how would the results be in comparison to starting everything without brute force? How would you define optimum 4 colors? Quote Link to comment Share on other sites More sharing options...
emkay Posted July 25, 2012 Share Posted July 25, 2012 If 4 colors can be displayed perscanline then would it not just be all combo's and error difference measured. for example on the c64 it would be something similar to color 0,1,2,3, color 0,1,2,4.... color 0,1,2,f... color 0,1,3,4.. ensuring that there are no repeated colors then code can be generated after based on the colors rendered. ofcourse on the atari this would take longer due to more 120 colors instead of 16 I dont know anything about how the atari generates its images however. perhaps previous colors have influence on next line etc. But even in interlaced format using combinations of multicolor/hires and all possible combo's, i was able to convert the image via pure brute force and luma masking etc in less than 10 minutes. See attached That's awesome - looks as good as a Spectrum512 image on the ST! Interlace with tremendous sunburn.... Quote Link to comment Share on other sites More sharing options...
thealgorithm Posted July 25, 2012 Share Posted July 25, 2012 That's awesome - looks as good as a Spectrum512 image on the ST! True, but this is an interlace. Well... Implementing interlace for RC should not be hard... It would be great if somebody could point me some good reading about PAL and NTSC color mixing for interlace Yes it is interlace and on C64. Image is pre-processed taking into account pal blending however unlike most other c64 converters, it makes use of color mixing discarding colors of luma values far apart. Pixel shuffling is used across frames in order to minimise flicker further. One thing to note in this mode is that hires and multicolor are alternated each scanline and the opposite for field 2. this drastically increases the pixel color density in each 8x8 block. There is another non interlaced c64 gfx mode however with the results as below. Issues with scaling on the image preview however. Quote Link to comment Share on other sites More sharing options...
ANTIQ Posted July 25, 2012 Share Posted July 25, 2012 Can the atari sprites be shifted at a different offset (eg in 160x240 display at x2 horizontal resolution, able to shift sprites to odd pixels (if so can somewhat be able to get 320x240). Not as far as I know. Anyone? No, unfortunately. The great unknown is ORing. Quote Link to comment Share on other sites More sharing options...
thealgorithm Posted July 25, 2012 Share Posted July 25, 2012 Ofcourse the possibile combo's with what you mentioned would result in taking too much time when brute forcing, however if you exclude the sprites from the equation and then just treat each line and select optimum 4 colors for each line, and then to start the other combinations and include sprites, via the hill climbing method after, how would the results be in comparison to starting everything without brute force? How would you define optimum 4 colors? Well, i should have put quotes around 'optimum' What i meant was to select 4 colors which give the 'least' error overall in that scanline (ofcourse this is not the best approach) but a quick method of preperation Quote Link to comment Share on other sites More sharing options...
+Stephen Posted July 25, 2012 Share Posted July 25, 2012 Interlace with tremendous sunburn.... Typical response. Care to point to any photo-realistic colour images on the A8 in 320*200? Quote Link to comment Share on other sites More sharing options...
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.