Images generated by RastaConverter

[Gunstar]

An entire art program using DLI's and player/missiles would have been needed back then, as there was no PC that could handle Rasta, or even full-color images to convert!

[Rybags]

There was decent photos floating around in the early 90s. And machines with 8 Meg or better were pretty common.

I should think an RC version for plain Dos would have been possible.

 

From RC runs I've done, sometimes you get a well usable pic in under half a minute. That would likely translate to over an hour on a Pentium 100.

Penalty factor of about 4.5 for being single core vs 4 core with hyperthreading. Penalty factor of 35 for being slower than the average modern CPU @ 3.5 GHz. Penalty factor of about 2 for lesser IPC and less capable maths performance. So, based on that we might assume a P100 is 315 times slower than a Core i7 at 3.5 GHz.

[Gunstar]

There was decent photos floating around in the early 90s. And machines with 8 Meg or better were pretty common.

I should think an RC version for plain Dos would have been possible.

 

From RC runs I've done, sometimes you get a well usable pic in under half a minute. That would likely translate to over an hour on a Pentium 100.

Penalty factor of about 4.5 for being single core vs 4 core with hyperthreading. Penalty factor of 35 for being slower than the average modern CPU @ 3.5 GHz. Penalty factor of about 2 for lesser IPC and less capable maths performance. So, based on that we might assume a P100 is 315 times slower than a Core i7 at 3.5 GHz.

yes, but we are talking 1980's not 90's. Back when the 8-bit was still relevant! Only with a mini-computer like the one used for Tron movie or The Last Starfighter could have been useful back then...maybe an ST or Amiga could have a Rastaconverter for those Spectrum 512 (and Amiga equivalent) images too, but then, as you say, an image conversion would take probably weeks to complete...

Edited December 28, 2017 by Gunstar

[RAM]

An entire art program using DLI's and player/missiles would have been needed back then, as there was no PC that could handle Rasta, or even full-color images to convert!

 

I wonder if anyone ever wrote such a program? I remember Graphics Art Department (GAD) allowed you to use DLIs, but not manipulate players, and it was in mode 7, I used to use that a lot back in the 80s!

[Rybags]

A less resource hungry but slower method could be to do evaluations a scanline at a time.

That way, even the Atari itself could be used to generate the pictures.

[AtariNerd]

I'm wondering if it is possible to implement this as two interlaced gr.7 screens and whether it would gain anything in cycle time (or not) for manipulation, if that would be of any benefit or if it would just be counterproductive and be less visibly desirable given refresh flicker, temporal dimming from the interspersing of blank-lines every other field, etc.

[Gunstar]

 

I wonder if anyone ever wrote such a program? I remember Graphics Art Department (GAD) allowed you to use DLIs, but not manipulate players, and it was in mode 7, I used to use that a lot back in the 80s!

Rambrandt by Antic Software. allowed DLI's and multiple graphic modes. It also has a solid object module addition to it, but alas, I don't know of any art program that used player/missiles for added colors. There were several others too. But Rastaconverter only averages about 64 colors per image, and there are art programs for HIP and TIP and other software graphic modes and at least one of them is a comparable resolution and can display 64 colors. I think there is some flicker though, which Rasta images avoid.

Edited December 28, 2017 by Gunstar

[The Mr. Video]

This one I made as sort of a test.

The_Mr_Video_LavaLamp.xex

[Gunstar]

Infocom's Planetfall. 76 colors.

Planetfall.xex

[Gunstar]

Man! Can you imagine if Miner, et.al. could have witnessed screens like this in 1979, 1980?!?!?

You know, another reason just came to me why it's interesting you bring up Miner. I recently either read or watched a review of Dropzone, and it was either a direct quote or indirect, of the programmer, Archer Maclean had said, which I am going to paraphrase here, which is: The Atari 8-bit/800 really is like an Amiga Jr., both creations of Miner's. But I do think Miner just might have been quite surprised and pleased if he'd seen images like this on the old 8-bit, way back then too, hell, even in the era of the Amiga. That's what's so fun about the Atari 8-bit and others, with modern techniques, going back to the old machines and pushing them further than ever thought possible, even by the engineers themselves.

Edited December 29, 2017 by Gunstar

[jmccorm]

This very colorful science fiction scene (similar to what Atari would have done for their own software titles) is from the cover of Creative Computing April, 1982. Snapshots are from the Altirra and Atari800 emulators in NTSC. I've included the picture that I started with and the binary that I ended with.

 

I used the Altirra palette with rastaconverter, but the colors were wrong based on Altirra's 2.80 default NTSC palette, so I adjusted the Hue Start to -20 and the Hue Step to 27.3. The adjusted NTSC setting in Altirra was used in its screenshot, below. I don't recall how Atari800 was set, as it was done many years ago, but it appears correct although slightly less saturated.

 

I think this would have looked incredible if I could easily make further adjustments, but I can't find a path to pull the output of RastaConverter into Graph2Font and keep the color adjustments. Does anyone have any pointers?

 

COMMAND: rastaconverter.exe creative.jpg /pal=altirra /threads=8 /distance=yuv /predistance=ciede /dither=floyd /dither-val=1 /s=10000 /h=240 /init=smart

Creative.xex

Edited December 29, 2017 by jmccorm

[jmccorm]

For comparison, I'll include a screen from Altirra 3.0 using its default NTSC color palette (which it references as Altirra 2.80 Default NTSC). You'll see the introduction of greens [along the ground] and more blues [throughout]. The deviation is pretty large, and I thought that being able to directly compare the original PNG and emulator video output on the same platform would be compelling evidence, but I was unable to convince Phaeron that it is a problem worth pursuing. Maybe I have it wrong after all? But Atari800 managed to get it right (if only a bit desaturated), so I dunno.

 

 

EDIT: The Altirra 3.0 default palette looks quite pretty (due to the saturation and artistically I like the blue colors much better) but those aren't the colors from the original picture and they aren't shown in Atari800 emulator either. I'm convinced that if Altirra is going to be used to view RastaConvert images with the Altirra palette, then it needs the adjustments to keep the colors accurate. Maybe I should recalibrate one of my arcade monitors and verify it on real hardware.

Edited December 29, 2017 by jmccorm

[+Philsan]

With Rastaconverter did you use NTSC palette?

I use Rastaconverter GUI and all palettes are PAL; to render a NTSC image I have to replace altirra.act with ntsc.act and rename it altirra.act.

[jmccorm]

With Rastaconverter did you use NTSC palette?

I use Rastaconverter GUI and all palettes are PAL; to render a NTSC image I have to replace altirra.act with ntsc.act and rename it altirra.act.

 

No, I thought I was doing one better!

 

With RastaConverter, I used the Altirra palette (as seen in their GitHub) and used the provided batch file to feed the output into the mads no_name.asq script, which creates our output.xex file. I made no adjustments to Atari800's settings before I took its screenshot, which looked desaturated but otherwise accurate.

 

I took a screenshot with Altirra 3.00 in NTSC mode and using the default setting which was Altirra NTSC 2.8, and it seemed nice but the colors were surprisingly wrong considering that I went out of my way to target it. I tuned the palette inside of the Altirra emulator by eye and documented my changes as Hue Start=-20 and Hue Step=27.3, and I took a screenshot, which looked totally awesome. I also tried the Altirra NTSC 2.5 setting and did not take a screenshot, but it was just ever-so-slighty more purple but significantly desaturated. So 2.5 seemed more accurate than 2.8 but less impressive because of the desaturation.

 

When I used RastaConverter, I used the command line (giving me more control and easily repeatable results), and I thought that selecting its altirra palette would yield really good accuracy, so I was surprised.

 

I also verified that the command line was properly evaluating palette input, including pulling the choice from the palettes subdirectory, and then displaying an error if an invalid or missing palette was specified. Here is exactly how I converted the image (and I've provided everything in my previous post which would allow for it to be easily reproduced and/or tested):

 

COMMAND: rastaconverter.exe creative.jpg /pal=altirra /threads=8 /distance=yuv /predistance=ciede /dither=floyd /dither-val=1 /s=10000 /h=240 /init=smart

 

I'll repeat the experiment by telling rastaconverter to use the NTSC palette and... wait a second.

 

They don't include an ntsc.act file! Should I use one of the other choices like real.act, or are we using different distributions of RastaConverter, or should I pull a copy of ntsc.act from a different source? I'm totally willing to run some experiments on my end as much as it helps figure this out one way or another.

Edited December 29, 2017 by jmccorm

[Gunstar]

With Rastaconverter did you use NTSC palette?

I use Rastaconverter GUI and all palettes are PAL; to render a NTSC image I have to replace altirra.act with ntsc.act and rename it altirra.act.

I replaced the Atari800Winplus palette with NTSC.

[+Philsan]

Here's NTSC palette:

ntsc.zip

[jmccorm]

Here's NTSC palette:

ntsc.zip

 

It is still deciding on colors, not to mention how it is going to dither it, so I'll let it run overnight.

 

Early impression is that it somehow manages to look pretty close on all three! Altirra with the NTSC 2.50 palette, Altirra with the NTSC 2.80 palette, and Atari800 with the NTSC palette (just as a reference). When it arrives at the answer, I'll reproduce and provide the output images for comparison.

 

What was the source for the ntsc.act file? Any thoughts why the palette they included for Altirra ends up all wrong? (I'm also curious to see if the final picture is perceived by the human eye as being higher or lower quality, or the same, color shifting aside.)

Edited December 30, 2017 by jmccorm

[jmccorm]

INTRODUCTION:

As requested, the images were re-run through RastaConverter and with the provided NTSC palette. RastaConverter introduced some obvious errors into the picture, but they didn't impact this comparison, so it was left as-is. Some images were cropped and/or resized to make them easier to compare.

 

SOURCE AND DESTINATION IMAGE:

The original image, and then a rendered "ideal" 8-bit version that RastaConverter is trying to reach.

 

 

ATARI800 (DEFAULT NTSC PALETTE):

The default Atari800 NTSC palette is significantly desaturated, but otherwise, it is close.

The blue areas should be just a little more green.

 

ALTIRRA 3.00 (NTSC25, NTSC28, MANUALLY CORRECTED NTSC28):

The NTSC 2.5 palette seems like the best of the three that follow.

The NTSC 2.8 palette seems a bit too red on top, a bit too green on bottom.

 

 

If it isn't clear which picture is which, hover your mouse over the image to see the filename.

 

BINARY EXECUTABLE:

output.xex

 

SUMMARY:

Overall, this run looks a lot closer, which was expected. With the provided NTSC palette for RastaConverter, the Altirra NTSC 2.8 preset seems like a regression (versus the 2.5 preset). If I flip back and forth between the Altirra's default NTSC 2.8 preset and the destination image, my arcade monitor calibration experience would say that the Altirra 2.8 version has too much red and green gain, but everything else seems good.

 

The NTSC 2.5 preset provides the most faithful color reproduction of the destination image and clearly seems to be the closest one out of this last set.

Edited December 30, 2017 by jmccorm

[a8isa1]

This very colorful science fiction scene (similar to what Atari would have done for their own software titles) is from the cover of Creative Computing April, 1982. Snapshots are from the Altirra and Atari800 emulators in NTSC. I've included the picture that I started with and the binary that I ended with.

 

I used the Altirra palette with rastaconverter, but the colors were wrong based on Altirra's 2.80 default NTSC palette, so I adjusted the Hue Start to -20 and the Hue Step to 27.3. The adjusted NTSC setting in Altirra was used in its screenshot, below. I don't recall how Atari800 was set, as it was done many years ago, but it appears correct although slightly less saturated.

 

I think this would have looked incredible if I could easily make further adjustments, but I can't find a path to pull the output of RastaConverter into Graph2Font and keep the color adjustments. Does anyone have any pointers?

 

COMMAND: rastaconverter.exe creative.jpg /pal=altirra /threads=8 /distance=yuv /predistance=ciede /dither=floyd /dither-val=1 /s=10000 /h=240 /init=smart

jmccorm, this is a cool picture. I hope you don't mind me giving it a try.

 

Please note that with rastaconversions I've long ago given up attempting to match brightness/contrast levels of the conversions with the originals. I just try to yield a fun picture on A8

 

The main palette I use (NTSC) is tweaked so that colors in the emulators are very close to what I see on my 800XL. This means I'm

using much more saturated colors.

 

Here are 2 works in progress. I like the destination pics. I know they look quite far from the original but if either one yields an acceptable .XEX I'll be happy.

 

I have a slow machine so I won't know for a quite a while.

 

Weak Jarvis dither, dither_val=0.666, dither_rand=2.1

 

Strong Line dither, dither_val=3.0, no randomization

Edited December 30, 2017 by a8isa1

[jmccorm]

jmccorm, this is a cool picture. I hope you don't mind me giving it a try.

 

Please note that with rastaconversions I've long ago given up attempting to match brightness/contrast levels of the conversions with the originals. I just try to yield a fun picture on A8

 

I don't mind at all.

I think you've succeeded! I like your interpretation, particularly the first one.

 

My current work-in-progress goes the other direction (so I'm interested in seeing your final results). It is running painfully on 8 hardware which supports threads because I've mixed ciede and knoll. But it looks like it captures a lot more detail.

 

COMMAND: rastaconverter.exe creative.jpg /pal=ntsc /threads=8 /distance=ciede /predistance=ciede /dither=knoll /dither-val=3 /dither_rand=1 /s=50000 /h=240 /init=smart /filter=box

 

I tried a number of options before that one, and now I realize how important the predistance, dither, and filter parameters are. They build the destination picture, which is the ideal that RastaConverter spends all the time working towards. Once you've got the parameters to make the destination picture that you want, then it is time to go for a full rendering.

 

I'm getting tempting to put together a new manual for RastaConverter which explains and visually demonstrates what the options do, what the limitations are, etc.

[a8isa1]

 

I don't mind at all.

I think you've succeeded! I like your interpretation, particularly the first one.

 

My current work-in-progress goes the other direction (so I'm interested in seeing your final results). It is running painfully on 8 hardware which supports threads because I've mixed ciede and knoll. But it looks like it captures a lot more detail.

 

COMMAND: rastaconverter.exe creative.jpg /pal=ntsc /threads=8 /distance=ciede /predistance=ciede /dither=knoll /dither-val=3 /dither_rand=1 /s=50000 /h=240 /init=smart /filter=box

 

I tried a number of options before that one, and now I realize how important the predistance, dither, and filter parameters are. They build the destination picture, which is the ideal that RastaConverter spends all the time working towards. Once you've got the parameters to make the destination picture that you want, then it is time to go for a full rendering.

 

I'm getting tempting to put together a new manual for RastaConverter which explains and visually demonstrates what the options do, what the limitations are, etc.

I found something in Rastaconverter that helps some pics. Low resolution dithering is undoubtedly ugly but waht makes it worse is false color, namely gray. I think with default contrast level gray is being used to blend two or more colors into a third color or shade. Unfortunately it's the gray that stands out. Pushing contrast to between 25 to 100 drives out the gray which makes the colors that are selected seem better blended even if they really aren't. The downside is some shading gets driven down to black (or dark).

[jmccorm]

I found something in Rastaconverter that helps some pics. Low resolution dithering is undoubtedly ugly but waht makes it worse is false color, namely gray. I think with default contrast level gray is being used to blend two or more colors into a third color or shade. Unfortunately it's the gray that stands out. Pushing contrast to between 25 to 100 drives out the gray which makes the colors that are selected seem better blended even if they really aren't. The downside is some shading gets driven down to black (or dark).

 

I noticed the gray, too. The colors in that area are just right on the edge, aren't they?

 

I worked around it a different way as I was trying a number of predistance options and saving the destination pictures to unique files. I found that euclid, yuv, and cie94 went gray while ciede kept things green. So once I arrived at my destination image with a predistance of ciede, I also set my distance to ciede hoping it'll keep things green. Your way is more direct (short of editing the image itself) so I'll be interested in your results, and I'm encouraged to try some of your settings, too.

[a8isa1]

 

I noticed the gray, too. The colors in that area are just right on the edge, aren't they?

 

I worked around it a different way as I was trying a number of predistance options and saving the destination pictures to unique files. I found that euclid, yuv, and cie94 went gray while ciede kept things green. So once I arrived at my destination image with a predistance of ciede, I also set my distance to ciede hoping it'll keep things green. Your way is more direct (short of editing the image itself) so I'll be interested in your results, and I'm encouraged to try some of your settings, too.

Feel free to try my palettes (in my sig). The numbers are notations of Altirra's color adjustments, NTSC default, 24.1 degrees, -44 start hue (the minus sign is implied since all start hues are negative), and saturation 30. The palettes have a brighter white, edited with gimp. The palette with saturation 50 I don't use in emulators. It's just for processing. It's mostly to get some red into a picture that rastaconverter wants to drive to brown hues (*shrug*).

[jmccorm]

I'm starting to get quite the education on RastaConverter. The code is far more complex than I imagined.

 

From my recent experience, I think I see the downside of creating a really detailed destination image with plenty of knoll dithering: you end up with a beautiful picture which RastaConverter is going to have a lot of difficulty reaching. The big blue marble [center, top] is one good example. The animation below switches between the destination image and the actual results after almost 20 hours of work on 7 CPU threads:

 

 

Aside from that, having errors in the destination image can be forgivable when they're randomized (and the error is not too large in magnitude). The code appears to be able to tackle the large magnitude errors well enough, but not the remaining problem of banding where one or more groups of lines will share similar errors over the same area. What many of these lines seem to have in common is that they share the same bad color selection in a region (but a mutation which swaps out a color either never manages to hit, or it causes a great problem somewhere else).

 

I looked to see how the code was targeting where to try new mutations, and it looks it is either going to try a neighborlng line next, or a random one. A comment in the code explains:

 

// I have tried to choose next mutation place depending on the error distance in the created picture, but the result was worse than that:

 

I'd be curious to see what was already tried. I think, though, that if we tell ourselves that the base algorithm is good enough, and we just focus on the error which is caused by bands of errors (which are often shared with similar lines), we'd have a decent plan of attack.

 

My opinion on root cause: the otherwise useful mutation which grabs a neighboring line as the starting point. Early on when the picture is being built (where lines are more likely to mutate, and successful colors are part of what is copied to neighboring lines), this works out well, but once a picture has developed sufficiently enough, a line tends to gets stuck with its color palette because. It doesn't take on a more successful neighbor's colors because it isn't able to quickly mutate into something better than the line started as.

 

If I had to take a stab at an algorithm, it would be something which runs independently of the other mutations, and only combs through the image on a very rare basis to force-start a line's mutation where needed, as follows:

 

1. Has this picture baked for a sufficient period of time? (If so, continue.)

2. Determine the amount of error we have in the current line. Subtract the amount of error in the previous (or next) line. Does this line have significantly more errors? (If so, continue.)

3. In the destination image, compare this line with the previous (or next) line. Are they similar enough for test #2 to have been a valid comparison? [#2 and #3 forms to create a very basic statistical analysis.] (If so, continue.)

4. Swap our current effort towards this line with the other line we've compared to and lock it in as the current best choice.

5. OPTIONAL: Mark this line as immune to this or other swapping mutations for the next number of [arbitrary] iterations run against this line.

6. OPTIONAL: If we are copying from the previous line, it is possible, but more rare, that the problem actually began two lines back. Maybe if we've been really unsuccessful in mutating this line after combing and copying once, we'd copy and shift from two lines back.

 

If that proves to be a successful algorithm, then we might look at doing the same analysis with partial (but significantly large enough) horizontal line segments.

 

I tried to justify why I think this approach would be successful, and then I realized, this is almost exactly what ilmenit said that people should do. This automates a manual process (originally for player/missile graphics errors that RastaConverter wasn't detecting.). If this could be automated, then I think RastaConverter could produce consistently better output.

 

Unfortunately, modern-day programming is beyond my skillset. Would anyone be willing to tackle something like this?

 

EDIT: I'm also wondering about the way a line's average error is determined. I seem to recall it was done on a per-pixel basis, and then summed up for a line, but I'm wondering if with mono-colors (like grays), it might need to have their error rates juiced up in some way. Something that just looks at luminance? I don't think it is giving luminance errors enough weight. If so, just fixing that might also help a great deal.

Edited January 1, 2018 by jmccorm

[a8isa1]

This was a last minute idea (with some cut & paste fails). Only time for 18 million evals.

 

 

Happy New Year 2018 !

a8isa1_hny2018.zip

Edited January 1, 2018 by a8isa1