Quantizator

[emkay]

430 Million evaluations, lesser transitions...

 

 

lotus.xex

 

 

 

 

[analmux]

this result is great..

This pic looks awesome. What kind of paletting did you use? Only 9 colours/scanline, and palette changes during HBLANK? Or also midscanline kernel changes, and > 9 colours/scanline? (I assume you can select the colour density, before starting the converter.)

[analmux]

...or also a GPRIOR=0 setting?

[Goochman]

It's going to take awhile to cook and I'm going to have to go back in and fix a few more things... but just to show what tweaking the brigtness contrast and color a bit can get you.

 

Nice - thanks for the conversion

[w1k]

i using first dither=none /pal=laoo.act and secord render (output.png-dst.png) dither=chess /pal=laoo.act

 

now rendering doom2

[Xuel]

 

tiger4.xex

Edited May 10, 2012 by Xuel

[Xuel]

I noticed that the display list that RastaConverter generates uses LMS instructions for every line. Those eat 2 cycles for DMA every line. Could another LDA/X/Y could be squeezed in if those are removed?

 

Another cycle could be saved if missile DMA is disabled. So, using emkay's scheme that should be enough for another STA/X/Y as well, since 3 extra cycles + 1 = 4 = cycles per STA/X/Y.

Edited May 10, 2012 by Xuel

[emkay]

I noticed that the display list that RastaConverter generates uses LMS instructions for every line. Those eat 2 cycles for DMA every line. Could another LDA/X/Y could be squeezed in if those are removed?

It doesn't really matter, because of the DMA reads spread on the right half of the screen. What's more important is to add an 48 byte mode, to get the border unicolour, when all PM is used, which helps to add more colours there.

 

[emkay]

What also could help, is to check all dither methods and how close they get per scanline.

Many (all?) images would take benefit, because they contain ranges that would do better with different dithering..

 

The main point is that sometimes a well fitting colour could be used, to have less changes in one scanline, while the transition pixel add another colour that reduces the image quality because the limit is exceeded.

In other lines it could be useful to add another colour for the details, until the limit per line is reached.

 

The Rasterizer could build all versions of dithering, and check all lines, comparing it to the best result, and use the best dither method for that line, and copy it into the final output picture.

Edited May 10, 2012 by emkay

[Xuel]

It doesn't really matter, because of the DMA reads spread on the right half of the screen. What's more important is to add an 48 byte mode, to get the border unicolour, when all PM is used, which helps to add more colours there.

 

I agree. That would be cool.

[emkay]

Sorry, the refresh is on the left side of the screen..., causing a wider DMA read, thus less changes on the left side

Edited May 10, 2012 by emkay

[AtariNerd]

Non-techy person question. Are not all colors displayable on a line, available anywhere on that line? I've prepared images that are well within limits, but still get streaks of different near colors, but not the color I've selected itself, even if it is a significant color used on that line. It will appear on one half of the screen side, but not the other. Which side has greater weight priority? Just trying to understand this from a simple users perspective.

 

That Lotus is georgous.

[emkay]

Non-techy person question. Are not all colors displayable on a line, available anywhere on that line? I've prepared images that are well within limits, but still get streaks of different near colors, but not the color I've selected itself, even if it is a significant color used on that line.

 

Not sure HOW the rasterizer works. But sometimes you have to shift a red to pink to have red in the final picture.... sometimes red turns into brown... and... most interestingly.... into a green ?!? Sometimes it puts violett into blue and so on... actually it "creates" new colours, even if there is no need...

I also wonder why that happens.

 

 

 

[ANTIQ]

The computer only has a certain number of paint pots (palette registers). If it puts blue in the red pot it won't be able to show red until it changes it again.

 

Say you have a picture which is half black, quarter red and quarter blue. If you merge the colours into two registers they may end up containing black and purple.

[emkay]

It still seems to priorize the brightness of a colour. So it choses a green even if a red would do better, just because the brightness fits more.

 

Hm....

[Heaven/TQA]

interesting to hear why LMS per line if that is true. never checked yet the displaylist myself.

[ANTIQ]

@emkay

 

Are you using Floyd-Steinberg?

Edited May 10, 2012 by ANTIQ

[emkay]

@emkay

 

Are you using Floyd-Steinberg?

 

With Floyd-Steinberg it is more obvious. But , same with all filters, extreme brightness changes make the colours more correct and give more details. Less brightness changes make the colours more incorrect and result in less details.

[Rybags]

Widescreen wouldn't ensure constant colour outside the picture if all registers are in use.

 

The reason for LMS every line - it gives a constant delay so the calculations can be the same for every line. In theory a NOP could be inserted every line to make things the same, difference would be a saving of ~ 190 bytes for a standard height screen.

[miker]

Here's something from me.

 

Original picture (s-shot from C64):

 

Converted one:

 

and the xex file:

output.xex

 

Almost pixel perfect. I waited till 30 million evals.

 

Enjoy!

 

Oh, build this way:

start RastaConverter.exe finalelf.gif /h=200 /filter=box /pal=Palettes\OlivierP.act

Edited May 11, 2012 by miker

[Irgendwer]

It still seems to priorize the brightness of a colour. So it choses a green even if a red would do better, just because the brightness fits more.

 

Hm....

 

This is correct. The human visual perception is much more sensitive regarding lightness faults than hue variations. (Utilizied e.g. in chroma subsampling (and C64 art ))

Edited May 11, 2012 by Irgendwer

[emkay]

It still seems to priorize the brightness of a colour. So it choses a green even if a red would do better, just because the brightness fits more.

 

Hm....

 

This is correct. The human visual perception is much more sensitive regarding lightness faults than hue variations. (Utilizied e.g. in chroma subsampling (and C64 art ))

 

With the exception that colour is as important as brightness, when the pixelcount gets low. You only can define the difference of grass and water with the used colour. Brightness isn't relevant there. A heap of 4-8 pixels only gets the definition by the colour... is it a stone (grey) is it some ice (blue) is it some straw (green) or is it something.... (brown).

 

 

[emkay]

Great work... must make those pixels submit! W1, I love that greyscale spider! :E

 

Sometimes, if you have a large flat area of very subtle shading on the brighter or darker end of the spectrum, it helps sometimes to deliberately outline those areas and color reduce them using a dithering pattern. This will sometimes give them a bit more "grit" and contrastyness, giving the program something to bite into. It can wreck the natural detail, of course, so would avoid it most times; but just another idea for the pixel-wrangling toolbox.

 

The tool gets interesting there.... just use it for the "finish"

 

The "vest" you wouln't see on the converted picture .... here some brighter stripe.... there some black line and .... voilá ... you see the vest

 

 

 

Coming soon to the A8 ....

 

 

 

FC2.xex

 

In a wider logic, it works as someone would think of an A8 drawing tool. You draw something, and the logic is putting it into the possible look (and code) automatically.

[emkay]

I also think, you don't want to see all the "makeup" on the source there, to have all the unwanted "wrinkles" removed

 

....

 

 

portrait.xex

[AtariNerd]

It will never replace an 8-bit pixel artist ( you folks are amazing, working with such small palletes,) , but I can see photos of shy demo party participants being distributed this way, their identities remaining more or less intact

 

Ewww, don't d/l that Gauntlet test from earlier... I was just making a point that sometimes things don't come out as planned, but sometimes very subtle, minor tweaks can render better results. The result I posted being the "before" picture. You don't have to be a photoshop expert to have fun with this. For serious. So come on shy Atarians, jump in and show us your stuff. We need participation.

 

Here's another take on the Gauntlet picture...just pushed the contrast a bit, but otherwise didn't do much. It's still rendering, but here is the current state.:

 

(Oops, posted wrong pic, now fixed. )

gauntlet_b.xex

Edited May 12, 2012 by AtariNerd