846 replies to this topic

[ilmenit]

emkay, on Mon Jun 4, 2012 4:36 AM, said:

A short list:
Put the picture through the converter, to have the 160x240 pixel.
Check the available colours per line.
Check the available Atari colours.
Drop the colours down to a countable use, for the available colour changes and usable colours.... per line
Put the "original" picture again through the converter with the aimed "fitting" colours and use dithering for that.

This is exactly how /init=smart and /init=less work.

Preprocess (no matter what type of /init is chosen)
0. Input picture is converted to 160*height pixels  -> output.png-src.png
0.1. Picture palette is converted to full Atari palette and dithering is applied if chosen -> output.png-dst.png

Initialization for /init=smart and /init=less:
In each line
1. /init=smart reduces the number of colors to the closest 12 Atari colours (8 with /init=less).
2. Colors are sorted by the number of pixels in the line (descending order)
3. In sort order colors are assigned to the playfield colors, then to sprite colors, then (if we have free cycles in the line) again to the playfield colors
4. Sprite positions are set to match the position of sprite color pixels

This works well for simple pictures, but gives worse results than /init=random for complex pictures, because the algorithm stuck in a local optimum.

Edited by ilmenit, Mon Jun 4, 2012 5:04 AM.

[emkay]

step 0.1 is in the wrong order. You'd have to leave the original palette there. If you turn to the Atari palette that early, the picture is full of transitions / dither pixels, because the filter wants to adjust all colours and brightness differences there.
It's better to have the Atari palette added, after the conversion is done.
It's just to make clear "before" using the A8 palette, how many colours could really be used for the final image.

Use that amount of colours, convert the picture with dither... then change to the Atari palette without any additional dither.

To add missing brightness steps, a variation of colours helps to keep details.
So if you need a brighter green, use a green with more yellow in it, instead of using the next brightness step of the "original" green, if you want a darker blue, use one with some green mixed into it. (for example).
In that way you get visuable details with always about 3 times of variation of one colour.


If you want to keep the dither methods, you could add some /dither=Atari or else.

Edited by emkay, Mon Jun 4, 2012 6:19 AM.

[Rybags]

That won't work.  Atari palette = 2^7 colours, 24 bit RGB = 2^24 colours.  Most full-colour pictures even if they look to have one solid colour in an area in fact can have dozens of slight variations that you don't easily see.

What might work is a Posturize operation - reduce original image to 8 luma levels early on.  But even then there's not a direct correlation when going to the Atari palette.

[ilmenit]

emkay, on Mon Jun 4, 2012 6:11 AM, said:

step 0.1 is in the wrong order. You'd have to leave the original palette there. If you turn to the Atari palette that early, the picture is full of transitions / dither pixels, because the filter wants to adjust all colours and brightness differences there.
It's better to have the Atari palette added, after the conversion is done.

While the picture without dithering could look a bit better (I don't think that much better), it would be impossible to apply any reasonable dithering.
For dithering you would have only colors available at the current pixel palette. It was like that in the first published version of RastaConverter. You can check the terrible results there.

Also the color-distance caching implemented by Phaeron would not work (colors space would be too big) and the optimization process would be at least 100 times slower.

Edited by ilmenit, Mon Jun 4, 2012 6:38 AM.

[emkay]

My results work and don't really look terrible.
It's just as I wrote above. Check the amount of needed colours and reduce them using dither.
Only the final step has to be done without dither.

[ilmenit]

I'm affraid your ideas will work only for simple pictures. Could you try to apply your idea to those pictures and present the result?

[emkay]

Summer picture , resized to 160x240 indexed colours, adjusted to laoo palette.

400K evaluations.



 atasomer.xex   21.29K   62 downloads



As you see, several transitions still there, but colours get more stable...

[w1k]

wow, thats clean and nice

[emkay]

w1k, on Mon Jun 4, 2012 8:26 AM, said:

wow, thats clean and nice

Well, the A8 has a huge palette. So we should use it


The pilgrim picture is a bit difficult, just because it is done particular for this resolution and the 64's colour density. So we have restrictions here. But "real" pictures always can be used with all available colours ... and dither only, where it is really needed.

[AtariNerd]

Interestingly, for the C64, for strait, non-interlaced, 16-color images, where one knows how that specific limited pallette and the manner of how those colors may be displayed in each cell, one might be able to develope rules that reduce the possible variables to that set, giving fewer permutations to sift through. Limits in the A8's ability to display certain colors in certain instances can borrow from how colors are often dithered on the C64 to produce images, through the use of available complimentary colors or picking a color of a particular shade, etc.

[ilmenit]

emkay, on Mon Jun 4, 2012 8:16 AM, said:

Summer picture , resized to 160x240 indexed colours, adjusted to laoo palette.

Ok, photo was not the best picture to explain what I mean - it still looks OK with many details lost f.e. on palm trees.
Here are the pictures with 'knoll' dithering (400K evaluations) and with 'simple' dithering (40M evaluations).
Still you can see how much more details they have.
 knoll.xex   22.09K   35 downloads
 simple.xex   22.08K   38 downloads

and 'knoll' dithering (400K evaluations) with Laoo palette:
 laoo.xex   22.07K   38 downloads

The Pilgrims picture from my previous post is much more complex to process. Also the "Happy Teddy":


Btw, what GFX program did you use for color reduction and remapping? The dithering on the sky looks nice and I wonder what kind of algorithm is used there.

Edited by ilmenit, Mon Jun 4, 2012 9:26 AM.

[emkay]

48M evals. now



 output.xex   22.12K   43 downloads

[emkay]

ilmenit, on Mon Jun 4, 2012 8:56 AM, said:

Btw, what GFX program did you use for color reduction and remapping? The dithering on the sky looks nice and I wonder what kind of algorithm is used there.

An almost 16 years old tool. The dither is quite similar to "chess" ... it's just that the colours have been adjusted, as I wrote above.

[emkay]

Robocop "Final"



 Robocop.xex   22.11K   38 downloads

Sepia "Final"...



 sepia.xex   18.63K   40 downloads

"Beast" ...

Particuler this shows where the difference is:

As the converter tries to mix some colour in, that looks "by value" fitting better to the brightness, but doesn't fit to the image at all, this picture uses a colour offset from brown to green to light brown, to have the details.



 beast.xex   21.88K   43 downloads

[Tezz]

The beast pic has come out quite well! I've found the g2f version that I did back in 2004 this morning and I've started repixelling the skeletal part this evening with a rare bit of free time. Prob won't get chance to finish it though tonight.

Here's my pic in progress, still lot of pixelling to do on the skeletal remains. I'm using GED+ (char) mode now, the original one i created was regular dli's.

Attached Thumbnails

• 

Edited by Tezz, Mon Jun 4, 2012 5:59 PM.

[AtariNerd]

Oh, you guys and your hi-color Atari pics...  

Automatic images are nice, but it is good to see what skilled pixel artists/hackers,like Tezz here, who have worked within a certain limitation set, could do with this.  It doesn't replace them, just opens up more possibilities.  Eventually, when some manual editor is created, it should be amazing.

But, despite all of the cheats we poke around with, to try and get faster results, sometimes we just have to accept that it will take a bit of time to get optimum pictures, even if it means going bald.

Here's a little work in progress of an image that because of its' smooth gradients and semi-monochrome pallete, will have any incongruities stick out like a Hitch-Hikers thumb. So, I'm going to let lt grind away until a result I will settle for comes up.. or I can't stand it anymore. So far around 600M (yes, AN is that crazy/patient) and it could be over a billion transitions before I'm satisfied. The trouble area is on the left-hand side, about a quarter across, like usual, but I'm willing to see if the program can ferret out something, eventually. I'll try playing around with different dithering levels and masks, if I have some other goes at at it, and I likely will because of a certain iconic nature it has for me and probably some others here - hey why not have a go, yourselves?

Attached Thumbnails

• 

[emkay]

AtariNerd, on Mon Jun 4, 2012 7:31 PM, said:

Oh, you guys and your hi-color Atari pics...  

Automatic images are nice, but it is good to see what skilled pixel artists/hackers,like Tezz here, who have worked within a certain limitation set, could do with this.  It doesn't replace them, just opens up more possibilities.  Eventually, when some manual editor is created, it should be amazing.

Tezz's picture is done in a different environment. The charmode offers 5 colours and the picture uses up to 9 colours.

Quote

But, despite all of the cheats we poke around with, to try and get faster results, sometimes we just have to accept that it will take a bit of time to get optimum pictures, even if it means going bald.

Many pictures ran through 1000 million and more, but the "wrong" colours put colours in, that sometimes cause "unsolvable solutions", and the lines won't be removed. That why I propose the presuming of the colours, which is easily to solve. You know, ... at the end there is a max. of usable and available colours and the converter has this limits anyways. But it doesn't get bothered with wrong placed colours that cause those lines on the screen.

[ilmenit]

emkay, on Tue Jun 5, 2012 12:14 AM, said:

Many pictures ran through 1000 million and more, but the "wrong" colours put colours in, that sometimes cause "unsolvable solutions", and the lines won't be removed. That why I propose the presuming of the colours, which is easily to solve. You know, ... at the end there is a max. of usable and available colours and the converter has this limits anyways. But it doesn't get bothered with wrong placed colours that cause those lines on the screen.

There is a max. of usable colours, but it can't be predicted. You can limit the number of colours per line to 8 or 12 in the input picture, but you may loose details then. With RastaConverter it is possible (but not guaranted) to have up to 10 changes of color in line which with initial state (4 PF colors + 4 sprite colors) gives up to 18 colors in line. The only good way of removing the conversion artifacts (horizontal lines) is by hand and the editor is needed for that. Maybe you should ask Tebe to improve the G2F to load RastaConverter output. Or someone could do an editor basing on the RastaConverter code (I won't do it, I find GUI programming too boring).

I still think that the direct conversion by RastaConverter is much more close to the original than preprocessed by you... With Laoo palette:

Your version | Original | RastaConverter (default)

 rastabeach.xex   22.08K   41 downloads

Edited by ilmenit, Tue Jun 5, 2012 4:08 AM.

[Tezz]

It's impressive what you've achieved with automation. It'll be a great time saver in creating/converting pictures when you're able to finalise the results with manual editing. IMHO the editor should be G2F and not creating a new one. Hopefully as you say Tebe will be interested to work on importing the results with you.

With regard to the processing methods suggested, there will be occasions (or sections of the picture) that will work out better one way or the other for sure. I don't see a way of making a one method fits all solution. That's where manual intervention will come in and once you can edit the results you'll be able to cut and paste and rework things until the picture is as good as it can be.

Edited by Tezz, Tue Jun 5, 2012 4:43 AM.

[emkay]

ilmenit, on Tue Jun 5, 2012 4:06 AM, said:

emkay, on Tue Jun 5, 2012 12:14 AM, said:

Many pictures ran through 1000 million and more, but the "wrong" colours put colours in, that sometimes cause "unsolvable solutions", and the lines won't be removed. That why I propose the presuming of the colours, which is easily to solve. You know, ... at the end there is a max. of usable and available colours and the converter has this limits anyways. But it doesn't get bothered with wrong placed colours that cause those lines on the screen.

There is a max. of usable colours, but it can't be predicted. You can limit the number of colours per line to 8 or 12 in the input picture, but you may loose details then. With RastaConverter it is possible (but not guaranted) to have up to 10 changes of color in line which with initial state (4 PF colors + 4 sprite colors) gives up to 18 colors in line. The only good way of removing the conversion artifacts (horizontal lines) is by hand and the editor is needed for that. Maybe you should ask Tebe to improve the G2F to load RastaConverter output. Or someone could do an editor basing on the RastaConverter code (I won't do it, I find GUI programming too boring).

I still think that the direct conversion by RastaConverter is much more close to the original than preprocessed by you... With Laoo palette:

Your version | Original | RastaConverter (default)

 rastabeach.xex   22.08K   41 downloads

The lines do not really aid the details.
But , as you might see. The sky suffers by the huge brightness steps, while the palms lose their shape in the line-mist.

My picture was a fast conversion, not having the exact possible colours at every scanline. But the software can do the comparisions fast. And if needed, the picture has to be redrawn with possibly a "green" less and some better spreaded sky-dither, to have the image at the best possible solution.

[emkay]

ilmenit, on Mon Jun 4, 2012 8:56 AM, said:

The Pilgrims picture from my previous post is much more complex to process.

What's your best result of that picture.

Possibly it's not that hard to have the pictures "well" on the A8. As the colorization of The C64 is already weird, some strange lines do not really disturb the image there.




 pilg200m.xex   22.07K   33 downloads

let's wait for 1000M ...

[ilmenit]

Did you preprocess the picture manually lowering the number of colours? Can you paste your destination picture?
Here is the picture of original height (/h=200 /filter=box /pal=laoo) without any preprocess after 1100M:
 pilgrims.xex   18.66K   49 downloads
C64 Original:


Even after 1100M evaluations the output picture still gets improved.

[emkay]

ilmenit, on Wed Jun 6, 2012 4:48 AM, said:

Did you preprocess the picture manually lowering the number of colours? Can you paste your destination picture?

22 colours , no reduce of colours, just adjusting the base colours to the palette. and 240 line high.
No dither...

Attached Thumbnails

• 

[flashjazzcat]

I have to say you're getting some nice results there Emkay. Pictures tend to be spoiled by the horizontal banding, but I see hardly any in your latest efforts.

[R4ngerM4n]

ilmenit, on Wed Jun 6, 2012 4:48 AM, said:

Even after 1100M evaluations the output picture still gets improved.

Wow, looks almost identical!