Jump to content
IGNORED

Images generated by RastaConverter


Philsan

Recommended Posts

One of mine ...

 

Original:

post-23798-0-80541200-1343191943_thumb.jpg

 

Rasta:

 

post-23798-0-00409800-1343191914_thumb.png

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):

 

post-23798-0-08166400-1343191902_thumb.png

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?

Link to comment
Share on other sites

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:

post-22831-0-34761000-1343207256_thumb.png

 

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 by ilmenit
Link to comment
Share on other sites

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

post-650-0-19880600-1343222700_thumb.png

 

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

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

post-650-0-68373900-1343226270_thumb.png

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by ilmenit
Link to comment
Share on other sites

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

 

testimage-supermfli.jpg

  • Like 1
Link to comment
Share on other sites

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:

post-650-0-16006900-1343240174_thumb.jpg

 

Attempted Destination

post-650-0-59881500-1343240190_thumb.png

 

Actual Output

post-650-0-09944400-1343240172_thumb.png

FLIR 226 Million evals.xex

 

 

Link to comment
Share on other sites

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

 

testimage-supermfli.jpg

That's awesome - looks as good as a Spectrum512 image on the ST!

Link to comment
Share on other sites

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 by ilmenit
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 ;-)

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

 

testimage-supermfli.jpg

That's awesome - looks as good as a Spectrum512 image on the ST!

 

Interlace with tremendous sunburn....

 

 

 

Link to comment
Share on other sites

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.

 

mucsu-fli.jpg

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...