Experimental Atari STE image enhancement website online

[Anima]

The (New) Experimental Atari STE image enhancement website to create images with more than 16 colours for the Atari STE is now online for a certain amount of time.

Details about this display technique can be found here: http://atari-forum.com/viewtopic.php?f= ... 48#p250595

Please note: the recommended proportion of images to be converted is 16:10 (like 1280 x 800 pixels). For your convenience please change your browser width to have two images in one row. Still not perfect in many ways but quite usable.

Edit: new website URL.

Cheers
Sascha

[Cyprian]

awesome tool, example images looks really good.
Is it based on DML's conventer?

[Anima]

awesome tool, example images looks really good.
Is it based on DML's conventer?

Well, no. It's an own algorithm which might not produce results as perfect as Dougs solution does.

Cheers
Sascha

[AtariZoll]

Interesting project. Obviously it works without on-fly color changes (during scanlines), but with alternating 2 regular STE screens, which are prepared to get best visual impression . So, low CPU usage. But there is downside too - 1 picture needs 64 KB, while Dml's Photochrome, or Cyg's hiSTE needs about 50KB in single phase mode - what may look better if well prepared, and no flickering.
Maybe time for new video playback experiment - since this can work well with DMA (ACSI) hard disks
That could work well, if can make 2 PI1 data as similar as possible, so second one to present as delta - will reduce overall data length. Hmm... - this may give you idea of creating new file format and less than 50KB for both phases

[dml]

awesome tool, example images looks really good.
Is it based on DML's conventer?

Well, no. It's an own algorithm which might not produce results as perfect as Dougs solution does.

Cheers
Sascha

I suspect the results will be quite similar in fact.

Much of the work I 'added' on top of the initial concept was in the following areas:

- trying to trade down unwanted flicker against colour fidelity based on the significance of colours and how they get used
- trying to make it run practically fast in a non-cloud environment (e.g. a desktop PC)
- adding different kinds of conversion for realtime uses, like textures etc.

I ended up adding the original convertor to PhotoChrome 6 as a new convert mode because I couldn't be bothered making/maintaining a new tool for it, even if it behaves quite differently

But anyway - these details aside I'd expect results to be about the same for both of our tools (esp. when viewing the composite/blended image). In fact if I turn off the flicker trading stuff (and any equivalent in your version) the results probably will be the same.

[dml]

Maybe time for new video playback experiment - since this can work well with DMA (ACSI) hard disks
That could work well, if can make 2 PI1 data as similar as possible, so second one to present as delta - will reduce overall data length. Hmm... - this may give you idea of creating new file format and less than 50KB for both phases

I actually suggested this experiment to you some time ago (streaming video using the output from cryptochrome tool - no colour changes) while we were working on the early hicolour video tests, since I just got the tool working around that time. I can't remember what the conclusion was but it got dropped - possibly because the palette eventually needs updated as the video progresses to keep the image represented fully and/or changing it every frame causes too many catchup artifacts.

Anyway I guess you tried so many different experiments at that time, this one wasn't much of a priority and you forgot

[Anima]

Interesting project. Obviously it works without on-fly color changes (during scanlines), but with alternating 2 regular STE screens, which are prepared to get best visual impression . So, low CPU usage. But there is downside too - 1 picture needs 64 KB, while Dml's Photochrome, or Cyg's hiSTE needs about 50KB in single phase mode - what may look better if well prepared, and no flickering.
Maybe time for new video playback experiment - since this can work well with DMA (ACSI) hard disks
That could work well, if can make 2 PI1 data as similar as possible, so second one to present as delta - will reduce overall data length. Hmm... - this may give you idea of creating new file format and less than 50KB for both phases

Totally agreed. There is a lot of room for improvements. Using two uncompressed images has no real advantage and was only chosen for sole reason that you can load the images into Degas Elite and play around with them. Also the main goal for this approach was "zero CPU time". So this technique can be used for games or animations (or maybe to convert some games from another system to the Atari ). I think Doug has explained the pros and cons nicely in the other thread.

Cheers
Sascha

[rian_ata]

Results are impressive!

Original:


Enhanced:


Original resized:


Enhanced resized:

[Anima]

Results are impressive!

Thanks for testing!

The higher resolutions are for game maps since you cannot display any image of a higher resolution than 320 x 200 pixels on the Atari STE so please keep that in mind.

Please note: after uploading an image you can change the colour space parameter and click on "enhance" again without selecting (and uploading) the file again. As I can see at the result above the bright areas are darker than in the original. You might try the colourspace XYZ to get a better result.

Edit: in fact, "YIQ" fixes the brightness problem:



Cheers
Sascha

[Anima]

Here is an example for game maps.

Original image:


Atari STE enhanced image (YIQ colour space, 82 colours):


Link: http://enhanceimage.dyndns.org/index.ph ... e=YIQ#form

Cheers
Sascha

[Dal]

This is very clever stuff with stunning results.

[AtariZoll]

...
I actually suggested this experiment to you some time ago (streaming video using the output from cryptochrome tool - no colour changes) while we were working on the early hicolour video tests, since I just got the tool working around that time. I can't remember what the conclusion was but it got dropped - possibly because the palette eventually needs updated as the video progresses to keep the image represented fully and/or changing it every frame causes too many catchup artifacts.
Anyway I guess you tried so many different experiments at that time, this one wasn't much of a priority and you forgot

I really don't remember details about it. Probably I expected much worse quality than with Photochrome.
Certainly video is hard case - because color number reduction normally calculates some new colors, close to original ones, and that may change in every frame, so will see ugly flickering on some parts.
Even 16 colors may look well, if can do color reduction with same palette for all frames in scene. Dithering is less visible on old TVs, monitors. If this system can produce good images without much dithering, it is great. I need to look your site, threads ...
As very fast ACSI-CF adapter will soon go in sale, it would be nice to make some animations for - max datarate is about 1900 KB/sec .
So, possible to get fullscreen, 25 fps even with 64K frames. But, as said crucial is to maintain same palette during scenes.
Will need to do some conversions to see how animations may look ...

[dml]

Edit: in fact, "YIQ" fixes the brightness problem:

TBH I came to much the same conclusion for CryptoChrome convertor (and also for PhotoChrome in earlier experiments) - CIE/XYZ colour space is theoretically better than (e.g.) YIQ/YUV but depends a lot on calibration for the display/representation device - without correct calibration the resulting colour error is so large it's not worth the cost of using it over other cheaper spaces.

[Anima]

Edit: in fact, "YIQ" fixes the brightness problem:

TBH I came to much the same conclusion for CryptoChrome convertor (and also for PhotoChrome in earlier experiments) - CIE/XYZ colour space is theoretically better than (e.g.) YIQ/YUV but depends a lot on calibration for the display/representation device - without correct calibration the resulting colour error is so large it's not worth the cost of using it over other cheaper spaces.

That's an interesting fact since I was only trying different colour spaces because ImageMagick support them and while reading the quantization part I was like "why not use them". ImageMagick does a brilliant job on all your image manipulation needs. It is my first choice for whatever I want to do with graphics (of course except drawing or painting). So in general it seems that our approaches are not totally different.

In fact, IMHO there's no "the best" colour space but you need to find out what's best for your needs by looking at the results (probably there's a way to do that automatically but I cannot imagine yet how it should work).

Cheers
Sascha

[Zamuel_a]

I tried it on the Giana sisters Amiga intro image and wonder why the dither pixels gets so big? They are 2x2 pixels wide instead of 1x1. (Not that the final image was so impressive, but anyway )

giana.png

[Anima]

I tried it on the Giana sisters Amiga intro image and wonder why the dither pixels gets so big? They are 2x2 pixels wide instead of 1x1. (Not that the final image was so impressive, but anyway )

giana.png

It's necessary because the enhanced image uses dithering. Using the same pattern would result in a flicker again so it is enlarged by a factor of 2.

Cheers
Sascha

[Zamuel_a]

Why can't the dither area be 1x1 pixels? That would result in less flicker

[Anima]

Why can't the dither area be 1x1 pixels? That would result in less flicker

Well, try it out by yourself. The website has been updated. You can now choose between some predefined "anti-flicker modes" so choose wisely.

Actually, 2 x 2 alternating pixel-blocks has been chosen by me because I wanted to reduce flickering for scrolling but I still need a proof that this will work.

Cheers
Sascha

[evil]

The Experimental Atari STE image enhancement website to create images with more than 16 colours for the Atari STE is now online for a certain amount of time.

Hello,

very nice tool, well done! I have a couple of suggestions and questions, don't take it as critisism please

a) Would it be possible to support other resolutions than 320x200 and still output in two files just not .pi1? Some of us enjoys coding in fullscreen and then bigger pics would be great A simple format could be: palette+rawdata, 16px alignment for width is of course needed.

b) Supporting ST palette would be neat as well

c) Would using two palettes (one for each frame) improve the results?

d) Will this tool be released stand-alone? dyndns doesn't sound comforting for the future


Thanks again for the tool, it's great to see new stuff like this being made.

[dml]

Will this tool be released stand-alone? dyndns doesn't sound comforting for the future

The original tool was (and is) standalone, and has been finished for four months now - but due to other stuff I didn't have time to release it and explain how to use it - so for now Anima's implementation of this is the only public one and it works well.

I'll try to get my tool out soon with some kind of config instructions for those who want an offline solution.

[Zamuel_a]

Why can't the dither area be 1x1 pixels? That would result in less flicker

Well, try it out by yourself. The website has been updated. You can now choose between some predefined "anti-flicker modes" so choose wisely.

Actually, 2 x 2 alternating pixel-blocks has been chosen by me because I wanted to reduce flickering for scrolling but I still need a proof that this will work.

Cheers
Sascha

I tested it on some pictures and it gave a much better result I think. I need to try it on a real machine with a CRT monitor to see what it looks like.

[dml]

I just posted a link to the standalone tool (CryptoChrome) for the first time, in the other thread:

http://www.atari-forum.com/viewtopic.ph ... 66#p219913

It's basically the same implementation as I used in 2012, but it has been glued into PhotoChrome with extra arguments. This tool does the same sort of job as Anima's new web service and is based on my writeup here from 2012:

http://www.leonik.net/dml/sec_crypto.py


In most cases though, I think Anima's web service is probably going to be easier to use and isn't constrained by CPU resources (which was always the biggest problem with my implementation - and where much of the effort went). The standalone tool though is still quite useful for demos and build scripts where graphics must be converted in a batch, for specific duties - so I'm making it available while it remains interesting

[dma]

You could also have a look at Zerkman routine : http://zerkman.sector1.fr/index.php?pos ... ersion-1.1
Result of this can be seen in the hi-color slideshow part of "Antiques" demo : http://www.pouet.net/prod.php?which=59066

[dml]

You could also have a look at Zerkman routine : http://zerkman.sector1.fr/index.php?pos ... ersion-1.1
Result of this can be seen in the hi-color slideshow part of "Antiques" demo : http://www.pouet.net/prod.php?which=59066

Zerkman's tool and displayrouts are very good - but they are a different kind of technique, similar to PhotoChrome, HigheSTColor/Cyg - and like those, uses most available CPU time.

The techniques on this (and the other related) thread are more about leaving 100% CPU free for other stuff like moving graphics, using a single 16-colour palette to simulate many more colours - but with more limitations and flicker than a full palette-switching solution (and no CPU free).

[dma]

Oh OK, i didn't read the thread closely enough, interesting approach indeed.
How could this work with sprites? Would those also be two-images-flickering based or not?