1NG Posted April 30, 2012 Share Posted April 30, 2012 Hi, I'm experiencing this kind of issue: ... The palette is wrong. I looks like red and green is switched (RGB <-> BGR) This is caused by: A) The picture being "different" from others (size, pixel-format or something) B) the palette used for Atari is false, currupt or inaccessible - If the same picture works on a different computer it then A) is not the case. I would try another palette as option. Maybe they aren´t accessible on the computer or corrupt. Look if they are available. - If the same picture doesn´t work on any computer try converting to a different format (JPG->PNG / PNG->BMP / BMP->PNG / GIF->PNG) (but never to JPG or GIF or quality loss can happen). Or try to crop a pixel in width. If it works I am interested in the cause. If not please attach the picture and the "test.bat" that starts rastaconverter. Quote Link to comment Share on other sites More sharing options...
matosimi Posted April 30, 2012 Share Posted April 30, 2012 The palette is wrong. I looks like red and green is switched (RGB <-> BGR) This is caused by: A) The picture being "different" from others (size, pixel-format or something) B) the palette used for Atari is false, currupt or inaccessible none of the above - If the same picture works on a different computer it then A) is not the case. I would try another palette as option. Maybe they aren´t accessible on the computer or corrupt. Look if they are available. palettes are ok, I've also tried default.act which has more bright colors, but it was also scrambled. When I remove palettes, program gives an error, so its definately not a palette issue. - If the same picture doesn´t work on any computer try converting to a different format (JPG->PNG / PNG->BMP / BMP->PNG / GIF->PNG) (but never to JPG or GIF or quality loss can happen). Or try to crop a pixel in width. it works on any other than the one I can use as dedicated converter. If it works I am interested in the cause. If not please attach the picture and the "test.bat" that starts rastaconverter. test bat: start RastaConverter.exe manga_chick.png /dither=chess Regards, Martin Quote Link to comment Share on other sites More sharing options...
matosimi Posted April 30, 2012 Share Posted April 30, 2012 Well I figured it out. It happens when system runs at 16bit color depth instead of 32bit... remote desktop tries to save bandwith so it switches to 16bit and cause this palette crap. Anyway, this issue is not only linked to RDP, so when I switched color depth locally on my computer (which I use to write this post), I get same scrambled palettes. Dunno how to fix this... but at least i know what causes it. Regards, Martin Quote Link to comment Share on other sites More sharing options...
1NG Posted April 30, 2012 Share Posted April 30, 2012 (edited) It happens when system runs at 16bit color depth instead of 32bit... remote desktop tries to save bandwith so it switches to 16bit and cause this palette crap. Maybe the result is OK anyway and only the desktop is screwed. Have you tested the result? Dunno how to fix this... but at least i know what causes it. Maybe there is a simple solution and the source can be patched. But I think it is OK if it only runs in True Color Mode. Edited April 30, 2012 by 1NG Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted April 30, 2012 Share Posted April 30, 2012 (edited) Dunno how to fix this... but at least i know what causes it. Did you checked the output file? Chances are high that only the display is wrong. Edited April 30, 2012 by Irgendwer Quote Link to comment Share on other sites More sharing options...
matosimi Posted April 30, 2012 Share Posted April 30, 2012 Dunno how to fix this... but at least i know what causes it. Do you checked the output file? Chances are high that only the display is wrong. yes, I checked output file... it's all wrong. As I wrote before, u can try it yourself, just change screen color depth to highcolor and u'll see... Quote Link to comment Share on other sites More sharing options...
emkay Posted April 30, 2012 Share Posted April 30, 2012 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.) To wait for "max. iterations" may not be as fun as one might think. The converter uses up to 8 colours per scanline. But it could use more colours when more changes on a scanline appear. .... you know... more than 20 colours were possible. Here a 127 colour dither picture... There are simply more details. Quote Link to comment Share on other sites More sharing options...
matosimi Posted May 1, 2012 Share Posted May 1, 2012 (edited) Hi Jakub, I've checked source of rastaconverter, and it can be improved to boost calculations... for instance function double RGByuvDistance(rgb &col1, rgb &col2) and inline void RGBtoYUV(double r, double g, double b, double &y, double &u, double &v) uses doubles to calculate conversion from RGB->YUV and calculates distance... It could be replaced with 8-bit calculation like this: Y = ( ( 66 * R + 129 * G + 25 * B + 128) >> + 16 U = ( ( -38 * R - 74 * G + 112 * B + 128) >> + 128 V = ( ( 112 * R - 94 * G - 18 * B + 128) >> + 128 Intermediate values are 16bit, but R,G,B,Y,U,V are 8bit usigned chars. Also distance could be integer-like variable then. I'm curious whats the difference between calculating distance in RGB and YUV color space... is that RGB2YUV conversion really needed? I would also try to replace squares in distance calculations with absolute values... just to see what happens, but it colud be probably very inaccurate, but can also boost the code. also in: double RGBEuclidianDistance(rgb &col1, rgb &col2) I don't see any reason to use doubles, there are just additions and multiplications of unsigned char values. There are also some places where values are divided or multiplied by 2 or 4, where can be used bit shifts instead. Anyway, I don't know how those genetic algorithms work, honestly I don't want to know, but it's fresh great approach I guess. I've also checked generated DLI code which is .... hmm... funny ? There are many LDA #$xx LDX #$xx in row without any STA or STX... I don't know how it generates code but it's really sick . Maybe I'm completely wrong, but after million evaluations system tries very tiny changes so if there is major imperfection in image after that many evaluations, it's highly improbable or let's say impossible that it could be fixed in later evaluations. Best Regards, Martin Edited May 1, 2012 by matosimi Quote Link to comment Share on other sites More sharing options...
tebe Posted May 1, 2012 Share Posted May 1, 2012 Emkay RastaConvert set LMS per line, it's 57 CPU cycles per line example 9 different values send to register: lda # ; change #1 (6 cycle) not visible (out of screen) sta reg lda # ; change #2 (12 cycle) not visible (out of screen) sta reg lda # ; change #3 (18 cycle) not visible (out of screen) G2F this 3 changes required for EDIT COLORS, EDIT PMG sta reg lda # ; change #4 (24 cycle) visible this 6 changes is visible in G2F EDIT RASTERS sta reg lda # ; change #5 (30 cycle) visible sta reg lda # ; change #6 (36 cycle) visible sta reg lda # ; change #7 (42 cycle) visible sta reg lda # ; change #8 (48 cycle) visible sta reg lda # ; change #9 (54 cycle) visible sta reg 3 cycle free more changes, with preload reg A,X,Y lda # ldx # ldy # sta reg ; change #1 (4 cycle) not visible stx reg ; change #2 (8 cycle) sty reg ; change #3 (12 cycle) lda # ; change #4 (18 cycle) sta reg lda # ; change #5 (24 cycle) visible sta reg lda # ; change #6 (30 cycle) sta reg lda # ; change #7 (36 cycle) sta reg lda # ; change #8 (42 cycle) sta reg lda # ; change #9 (48 cycle) sta reg lda # ; change #10 (54 cycle) sta reg 3 cycle free Quote Link to comment Share on other sites More sharing options...
snicklin Posted May 1, 2012 Share Posted May 1, 2012 I'm trying to look at this from an algorithmic point of view. If we had extra colours on a horizontal line, but certain colours can only be used in specific sections of the line, I can only imagine that the calculations are going to be exponentially difficult (and therefore much much slower). I like the idea of using midline DLIs, but cannot fathom just how much more difficult it will become to code the encoding routine. The extra colours will make life easier, but the locality restrictions of colour use won't help matters. Please though - please prove me wrong with working code. Then maybe it can be ported onto here for some supercomputing... : http://aws.amazon.com/ec2/ Quote Link to comment Share on other sites More sharing options...
emkay Posted May 1, 2012 Share Posted May 1, 2012 (edited) Emkay RastaConvert set LMS per line, it's 57 CPU cycles per line example 9 different values send to register: lda # ; change #1 (6 cycle) not visible (out of screen) sta reg lda # ; change #2 (12 cycle) not visible (out of screen) sta reg lda # ; change #3 (18 cycle) not visible (out of screen) G2F this 3 changes required for EDIT COLORS, EDIT PMG sta reg lda # ; change #4 (24 cycle) visible this 6 changes is visible in G2F EDIT RASTERS sta reg lda # ; change #5 (30 cycle) visible sta reg lda # ; change #6 (36 cycle) visible sta reg lda # ; change #7 (42 cycle) visible sta reg lda # ; change #8 (48 cycle) visible sta reg lda # ; change #9 (54 cycle) visible sta reg 3 cycle free more changes, with preload reg A,X,Y lda # ldx # ldy # sta reg ; change #1 (4 cycle) not visible stx reg ; change #2 (8 cycle) sty reg ; change #3 (12 cycle) lda # ; change #4 (18 cycle) sta reg lda # ; change #5 (24 cycle) visible sta reg lda # ; change #6 (30 cycle) sta reg lda # ; change #7 (36 cycle) sta reg lda # ; change #8 (42 cycle) sta reg lda # ; change #9 (48 cycle) sta reg lda # ; change #10 (54 cycle) sta reg 3 cycle free I know . But things would get faster with a - per line examination of used pixels and the dependency with the lines above and below. Possibly a 2 line dither would help with more details though. It would be nice to have a "special feature" in G2F. It shouldn't be too hard to add, I guess. Just load the original picture for importing and make it possible to have every line "stretched"... and below the same with the same line of the picture to the importing place... This one could be analyzed by "view" and directly import by using the preferred details 1st. And, due to the fact, images depend on different scanlines, not all registers need to be changed every scanline, to have the needed colours available. 11 colours in the scanline 10 colours in the scanline 9 colours are easily there.... Edited May 1, 2012 by emkay Quote Link to comment Share on other sites More sharing options...
Marek Konopka Posted May 1, 2012 Share Posted May 1, 2012 (edited) Have a try with my experimental branch. Changes: - Increased pool of available raster cycles from 53 to 55. - Improved precision of raster program by introducing a neutral 3 cycle CMP 0 instruction. - Added two experimental mutations: "Copy to Previous Line" and "Shuffle Instructions". - Applied minor tweaks RastaConverterMKExpBranch.zip Edited May 1, 2012 by Marek Konopka Quote Link to comment Share on other sites More sharing options...
snicklin Posted May 1, 2012 Share Posted May 1, 2012 @Marek Konopka I've just tried this version but I am getting a missing DLL file error (msvcr100.dll) with Windows Vista. Am I doing something wrong? Quote Link to comment Share on other sites More sharing options...
snicklin Posted May 1, 2012 Share Posted May 1, 2012 ... and the previous versions work on the same PC. Quote Link to comment Share on other sites More sharing options...
miker Posted May 1, 2012 Share Posted May 1, 2012 I've enuntered similar problem with Ilmanit's version but regarding MSVCR71.DLL. I went into http://dll-files.com downloaded missing one, and put it into program directory. And it worked. OMGWFTBBQ Quote Link to comment Share on other sites More sharing options...
Marek Konopka Posted May 1, 2012 Share Posted May 1, 2012 (edited) Installing one of these should fix the problem temporarily: http://www.microsoft...ls.aspx?id=8328 http://www.microsoft...s.aspx?id=13523 EDIT: Or you could try this build. RastaConverterMKExpBranch.zip Edited May 1, 2012 by Marek Konopka Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 1, 2012 Share Posted May 1, 2012 This is an incredible tool. My netbook just renderes for 3 days and it is amazing how last minute changes improve the quality. Tonight I will check the latest build. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 1, 2012 Share Posted May 1, 2012 btw. how can I use the stuff on real A8? Quote Link to comment Share on other sites More sharing options...
Marek Konopka Posted May 1, 2012 Share Posted May 1, 2012 btw. how can I use the stuff on real A8? Copy program's output files: "output.png", "output.png.rp.ini", "output.png.mic", "output.png.rp", "output.png.pmg" into the Generator subfolder and run build.bat from that location. Use the produced .xex file. Quote Link to comment Share on other sites More sharing options...
snicklin Posted May 1, 2012 Share Posted May 1, 2012 The new build works for me now. Thank you! I'm just testing it out now. Quote Link to comment Share on other sites More sharing options...
miker Posted May 1, 2012 Share Posted May 1, 2012 Original picture: http://noname.c64.org/csdb/release/?id=58418 The one converted by RastaConverter: punished.xex Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 1, 2012 Share Posted May 1, 2012 the xex file... chunli.xex.xex Quote Link to comment Share on other sites More sharing options...
emkay Posted May 1, 2012 Share Posted May 1, 2012 (edited) Thinking of the best way to use the A8's palette most right. You know, the left pic is the source, the right is the destination and the middle is the current state. The colours only were almost available with some shifting of the colours, as you might await a picture like this, which is a quick GTIA 9 Mode edit in G2F.... This "slight" variation on the used colour balance reduces/removes the dithering-pixels, that would be necessary, to have the sky not just blue.... Edited May 1, 2012 by emkay 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted May 2, 2012 Share Posted May 2, 2012 (edited) Here's a patch to compile this on Linux. Just a few small fixes to make it more standards compliant and a simple Makefile. Did not fix the pathsep issue, but you can just specify the input file and palette file on the command line. Thanks for using portable libraries like allegro and freeimage. rasta-linux.patch.zip Edited May 2, 2012 by ivop 1 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 2, 2012 Share Posted May 2, 2012 is there a way to have a ASM-Source file? In theory the generator assembles via MADS anyway the .xex? Sorry for not having checked the output files manually. 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.