Quantizator

[emkay]

Please, please tell me that you now understand.

 

Den Mist kannst du dir an den Hut stecken.

Was der Konverter macht, ist einen Teil vom Feldberg zu nehmen, da eine Scheibe herauszuschneiden und zu vergessen, weil er ja nicht wichtig ist... dafür wird ein Stück vom Westerwald genau passend gemacht und auch gerne mal das Tal zwischen den Bergen vergessen.

Noch schlimmer ist, dass der Konverter den kleinen Feldberg nicht kennt und deswegen nicht berechnet.

 

Hast du es jetzt verstanden?

 

No he entendido ni una puta palabra. Si intentas otra vez en ingles quizas...

 

 

Cause of the latin roots, this isn't really hard to understand. You have to understand WHY word get used "that way" in a language. It's also "partly" english. So , without knowing the sentences themselves, I understood "write in english sentences" .....

 

 

 

To be fair sometimes when you feel you aren't getting the point across I can see that out of frustration you do just want to drop back to your mother tongue to make sure you are absolutely saying what you want to say to get the point across - I've been there and done that. It doesn't cover the fact that other people just don't speak the same language though so it's not really a way out.

 

It was directly adressed no "Irgendwer". If I'd wanted to insult people, I tell them directly.

 

... I find it very impolite to use german in an AE/BE-language forum...

 

Some people just don't have English as their first language - I'm not sure I'm 100% behind the idea that people who don't quite have it as easy as me (I'm not sure how long I could hold out on a Spanish language forum) and can use their first language without having to think so hard are somehow stupid. There's a lot of folks here using a 2nd/3rd language and doing the best they can with it (which sometimes feels like fighting with both hands tied behind your back), which is better than I think most of us brits/americans/whoever can do and attacking someone on that basis isn't really called for.

 

Criticism for being negative and coming down on everyone elses projects and achievements is fair enough though.

 

...

[emkay]

Here a short explanation video of , how to manage the banding and to have more Image details.

 

http://www.youtube.com/watch?v=s1gLy3ZBkoc

[AtariNerd]

Hmmm. Rembrandt, I think it was, would create a detailed monochrome subpainting first and put colored glazes or washes over that subpainting to give a general colorcast. He would then paint in the color detail.

[emkay]

Hmmm. Rembrandt, I think it was, would create a detailed monochrome subpainting first and put colored glazes or washes over that subpainting to give a general colorcast. He would then paint in the color detail.

 

A try to get even better results could be to use an automation that puts always a colour in. And either the full solution or the "running out of quick solutions" for that step, causes another colour to put in.

[ilmenit]

I'm trying to recreate your explanation.

1. You have 3 steps there - low colour (3:58), medium colour (4:46), full colour (6:35). What kind of colour reductions are applied there? Which tool/option/algorithm did you use for that?

2. What is the stop condition to try the next iteration with more colours?

 

Can you try it on some more complex picture like http://noname.c64.or...lease/?id=98729 ?

Edited July 2, 2012 by ilmenit

[ANTIQ]

It might be useful to be able to lock the converter to the nearest Atari colours when the source picture contains fewer than 128.

 

(I don't want things to get more bogged down.)

[emkay]

 

 

Can you try it on some more complex picture like http://noname.c64.or...lease/?id=98729 ?

 

High colour pictures don't need much different "initial" pictures. Low colour pictures do well with more initial pictures.

4 , 8 , 12 , 14 , 16 colours images were ok. Another problem there is the exact colour/pixel usage.

So here a first result : without dither ... it was almost there at 50M now it is at 100M Evaluations.

 

 

teddy.xex

Edited July 3, 2012 by emkay

[ilmenit]

Could you post the information and images needed to reproduce what you are describing?

1. What kind of colour reductions are applied there? (on the youtube movie)

2. Which tool/option/algorithm did you use for that?

3. What is the stop condition to try the next iteration with more colours?

 

It is required for me to try to implement this.

Edited July 3, 2012 by ilmenit

[emkay]

Could you post the information and images needed to reproduce what you are describing?

1. What kind of colour reductions are applied there? (on the youtube movie)

2. Which tool/option/algorithm did you use for that?

3. What is the stop condition to try the next iteration with more colours?

 

It is required for me to try to implement this.

 

Isn't the converter itself able to produce different colour depths with dithering?

It's really just letting the converter run for a dedicates time, until the picture is adjusted.

Possibly a simple timer (adjustable by the user) helps there.

[ilmenit]

Isn't the converter itself able to produce different colour depths with dithering?

It's really just letting the converter run for a dedicates time, until the picture is adjusted.

Possibly a simple timer (adjustable by the user) helps there.

 

So, the human interaction is needed to decide when to do next iteration step.

Can you answer the other questions?

 

1. What kind of colour reductions are applied on the youtube movie?

2. Which tool/option/algorithm did you use for that?

 

If anyone is interested why am I asking for that - I have a strong feeling that Emkay is not only ignorant, but also a liar, who prefers to hide some facts to defend his ideas.

Edited July 3, 2012 by ilmenit

[emkay]

 

If anyone is interested why am I asking for that - I have a strong feeling that Emkay is not only ignorant, but also a liar, who prefers to hide some facts to defend his ideas.

 

?

 

You really don't get how this works?

It's just a coordinated spread of the available colour changes. Using the "Mountain climbing" with more correct "image" points, that gets handled earlier... The routine doesn't have to search for "important" points, because the important points were set from the start.

 

Use Irfan view , if you like.... simple resize, colours can be adjusted simply...

[emkay]

The multi "colour" increase also helped with the "moon" in this picture.

 

70M Evaluations.

 

 

bm.xex

 

 

[ilmenit]

Use Irfan view , if you like.... simple resize, colours can be adjusted simply...

 

No, colours can't be adjusted that simply. None known to me colour reduction algorithm will create that output that you have presented. None will ignore the sky colour and put the colour where it is needed - on the dresses.

I have tried IrfanView and it does not give that result for any number of colours with "Reduce Color Depth".

[+CharlieChaplin]

Well,

 

when doing some picture colour reduction (e.g. 24Bit to 8bit) I always prefer "Slowview" instead of the well-known programs Irfan-View or XnView. Especially for GIF-pictures it produces much better results with 256 colours than the other programs do. In some cases you don`t see a difference between a 50k-colour JPG picture and a 256-colour GIF picture.

 

Slowview is an old german freeware program for Win XP and its discontinued by its author - a firm (Ashampoo) bought it and nowadays sells it commercially as a gfx package (including a gfx-viewer, a database and other programs) under a completely different name. Here is the old freeware version; when installing the program choose e.g. english or german/deutsch as language, when running the program go to "Configuration" and there you may choose another language, that is not in the setup like e.g. polski or russian. To setup or change the colour reduction go to the Config. menu again, choose Setup and then Colour Reduction, there you can choose colour reduction for 8Bit and 16Bit. For 8Bit there is Median Cut, Popularity Sort and Neural-Net-Quantization (my choice, if I remember correctly). For dithering (which I do not like) there is Serpentine-Floyd-Steinberg, Ordered and None (my choice).

 

Attached is the program and a few sample pictures. Not sure if this program can help here, but I always thought it would be wise to reduce a PC picture to max. 256 colours (and max. 320x240 pixels) before converting it for/to the A8...

 

-Andreas Koch.

slowview.zip

pix.zip

[Wrathchild]

Have we had a source file for the Blood Money yet? The one I have is 320 * 256 and the original seems pretty dithered all ready which makes the filter/dither settings quite critical IMO.

 

Anyway, here is a variation on the current executable with the additional of /distance.

This replaces the /euclid option and so now you can have:

/distance=yuv (the default), euclid or cielab.

The last option is new and uses the L*a*b* colourspace instead of RGB but to support it I've had to remove the earlier optimisation of "long long" and unsigned short" for distance calcs and use double & float instead. This slows things down again but the new colourspace may provide better results in some scenarios (e.g. try with the test.png parrot picture).

 

Next I'll have try at adding something like a '/direct' option to get the application to use an indexed pallete based upon the imported picture's palette.

changes.zip

RastaConverterCieLab.zip

[emkay]

Have we had a source file for the Blood Money yet? The one I have is 320 * 256 and the original seems pretty dithered all ready which makes the filter/dither settings quite critical IMO.

 

 

The "import" to A8 with the fitting palette is just throwing the original title through the filter .... then use the destination picture for the next step.

 

[emkay]

The "unsolvable" Flimbo Title.

 

Not bad for 10M Evaluations...

 

 

flimbo10M.xex

 

 

 

Imagine G2F using such a "helper" .

[ilmenit]

Anyway, here is a variation on the current executable with the additional of /distance.

This replaces the /euclid option and so now you can have:

/distance=yuv (the default), euclid or cielab.

The last option is new and uses the L*a*b* colourspace instead of RGB but to support it I've had to remove the earlier optimisation of "long long" and unsigned short" for distance calcs and use double & float instead. This slows things down again but the new colourspace may provide better results in some scenarios (e.g. try with the test.png parrot picture).

 

I'm sorry to write that, but what you have done is already in Beta4, that was not uploaded to GitHub...

http://www.atariage.com/forums/topic/156160-quantizator/page__st__400#entry2529104

[Wrathchild]

Such a fast moving thread I seemed to have missed, but had done the same thing around that time anyway and had only yesterday got around to merging it with the current GitHub code...

 

I noticed you were sqrt'ing the deltaE distance and so aren't you at risk of losing some precision there when converting to distance_t?

[ilmenit]

I noticed you were sqrt'ing the deltaE distance and so aren't you at risk of losing some precision there when converting to distance_t?

 

You are right, the sqrt is not needed there. It was there to check if my colour calculation gives proper result and I forgot to remove it.

[ilmenit]

I have just found a bug introduced by Phaeron optimizations - the cached colour distance is calculated from the orignal picture, not from the destination picture. After fixing it will remove most of the banding problems and will speed up the whole process.

[analmux]

OK, I'm not an expert in these techniques by far, but isn't it a bug anyway when converting a picture needs millions of steps & a lot of time? Even when the converter is running on PC?

 

I would expect such a tool to run a lot lot faster. Or did you use a slow compiler / interpreter programming language?

[Rybags]

I suspect that's due to the brute force nature of the thing.

 

Maybe if the status update was only once per second or something it'd speed up some more.

[ilmenit]

OK, I'm not an expert in these techniques by far, but isn't it a bug anyway when converting a picture needs millions of steps & a lot of time? Even when the converter is running on PC?

I would expect such a tool to run a lot lot faster. Or did you use a slow compiler / interpreter programming language?

 

Bug is an error in the code, something that was not planned or designed. What you mentioned is not a bug.

I know 2 bugs currently - the one that I just described above and the one with the sprite repositioning (that Phaeron also fixed in Altirra).

 

Why the tools work this way you may read in this topic. For complex multi-colour pictures it is impossible to just calculate or even define the best solution. Setting registers in previous lines influence possibilities of setting registers later.

For example in the first line it may be the best to cover some colour with a player, but globally it may be better to save this player for the next lines, because there won't be time to set it.

Moreover all the changes must be synchronized with the screen draw and LDA/STA instructions have different number of cycles. ANTIC also steals the cycles to complicate things more.

 

I have some ideas to test like local-brute force, changing colours in even lines, sprites in odd lines etc. but they are just heuristics that will not give the perfect result and may work only for simple or low-colour pictures.

 

Edited July 4, 2012 by ilmenit

[snicklin]

I would expect such a tool to run a lot lot faster. Or did you use a slow compiler / interpreter programming language?

 

Compared to the first version, it is a lot quicker now. The thing is, instead of doing 10M evaluations, we now expect to do 100M evaluations! If it was speeded up more, we'd expect to do 200M evaluations! and so on....!

 

Personally, I think it's a very fast tool with the amount of calculations it is doing.

 

However, it's not fast at getting the picture perfect, but then it never will be perfect. Due to the increased speed, our definition of what is "adequate" has probably increased in quality. We used to think that the Atari ST was fast!

 

By the way, it is compiled.

 

On a different note:

I quite like the theory of what Ilmenit has produced. From my computer science background, I understand the theory of how it is an iterative process which will never be perfect unless with ultra-simple pictures, it just gets iteratively better, with lower amounts of benefits as more time passes by. There will never be a perfect solution for all pictures thrown at it.