PhotoChrome v6

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

PhotoChrome v6

Postby dml » Wed Dec 04, 2013 10:38 pm

It's been a while since I looked at PhotoChrome - a lot of effort was made in v5 to upgrade the convertor to use more powerful algorithms and with more flexible options. Some extra features were also added which I did not fully document.

One of these features included the capability to convert images for display formats other than the native PCS format - including display routines which had not yet been developed. The aim was to provide a toolkit for converting images, rather than just trying to display images with more colours - since everyone has their own routines...

PhotoChrome was the first attempt at dual-field images on the ST/E. Meaning - using more than one bitmap to display extra colours normally not available. There have been several very good implementations since then, including good convertors. While a lot was done with my convertor, it has been stuck with a display routine from 1991. This routine was based on the SPU (Spectrum512) timings because it was well known, I could generate images compatible with Spectrum using the same tables, and it was good enough at the time. No more!

So I decided to go back and push against some limits again.


PhotoChrome v6 has a new experimental specification for a stock STE. This is one of several new modes for v6.

* Full overscan - 416x272
* 52 palette changes per scanline (I believe the last record was 48?)
* Uniform distribution of colour changes

All of these things have been achieved or slightly exceeded individually, but not all at once in the same mode. I had this working a while ago but wanted to wait until I had it tested on a few different machines. I also still have some things to fix (like wakeup protection, missing 1st scanline and several other glitches) and I will get around to that.

Getting this mode to work really depended on a good "image-at-once" reduction algorithm, or at least the ability to propagate error globally between scanlines - since there is complex sharing of colours across left/right border. Scanline-at-a-time can't do it.


Further, PhotoChrome v6 can generate and display images with the highest colour depth so far - "tri-field" images. It can render from a palette of nearly 100,000 colours (the old PhotoChrome - and it's recent competitors - achieved nearly 28,000 colours on STE). This is a fun experimental thing, but results are already getting pretty good and I have now found a decent way to stabilize them. These images are presented without any dithering:

final-sgl.png

final-dual.png

final-tri.png



Also, I have upgraded the convertor to accept more complex display configurations. It is now possible to define a unique rule for any group of scanlines, down to a single scanline. This can be done via a rule file, without recompiling the convertor. If you think of a great new displayroutine but it involves fiddly stuff for bottom border or you want to reserve colours in a portion of the image, it's now relatively easy to generate an image for it by making one of these rule files. The new displaymodes I have created are implemented through these rule files and I'll provide them as examples. The rest is down to reformatting the data it produces to suit your display code (it's best to emit the data in raw format, when doing this - it saves messing with PCS format headers).

Wakeup protection (preventing the dreaded columns of random dots/lines) can also optionally be enabled, as a flag (this works for old types of image but I haven't fixed it for flexible image types yet).


Lastly, there are new algorithms and some new features aimed at different tasks. I'll describe these later when I release the updated tool.


I figure that should qualify as an upgrade - and perhaps something new to beat ;-) For now though, I think it may be (however briefly) back at #1

Happy holidays to all Atari coders and users alike!
You do not have the required permissions to view the files attached to this post.

User avatar
dhedberg
Atari God
Atari God
Posts: 1125
Joined: Mon Aug 30, 2010 8:36 am
Contact:

Re: PhotoChrome v6

Postby dhedberg » Wed Dec 04, 2013 11:34 pm

Looks absolutely fabulous! Great work!
Daniel, New Beat - http://newbeat.atari.org. Like demos? Have a look at our new Falcon030 demo and feel the JOY.

User avatar
christos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2455
Joined: Tue Apr 13, 2004 8:24 pm
Location: Greece
Contact:

Re: PhotoChrome v6

Postby christos » Wed Dec 04, 2013 11:48 pm

Impressive!

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Thu Dec 05, 2013 12:11 am

dhedberg wrote:Looks absolutely fabulous! Great work!


Thanks Daniel!

BTW it's great to see you around here :)

User avatar
Xerus
Moderator
Moderator
Posts: 1233
Joined: Fri Dec 13, 2002 9:31 pm
Location: France

Re: PhotoChrome v6

Postby Xerus » Thu Dec 05, 2013 1:37 am

It looks really impressive but the flickering with 3 permutations may be too visible ?
I can't wait to see it on a real monitor !

Bravo :D

User avatar
TheNameOfTheGame
Atari God
Atari God
Posts: 1339
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: PhotoChrome v6

Postby TheNameOfTheGame » Thu Dec 05, 2013 2:39 am

Whoa, that is super coding! Good job!

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 667
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: PhotoChrome v6

Postby Anima » Thu Dec 05, 2013 4:43 am

Really great stuff. Thanks for your ongoing development on this topic.

Cheers
Sascha

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: PhotoChrome v6

Postby AtariZoll » Thu Dec 05, 2013 8:34 am

Great news Doug :D
I don't think that tri-field images will flicker significantly more than 2 field ones. Of course, will need more space.
There are some routines with 54 palette color changes per scanline, with 2 colors fixed. Did you try palette change with blitter ? In theory it could give more.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

jok
Atari freak
Atari freak
Posts: 72
Joined: Wed Dec 19, 2012 3:06 pm

Re: PhotoChrome v6

Postby jok » Thu Dec 05, 2013 9:31 am

Great work, wow!

User avatar
spiny
Disk Imager Supreme
Disk Imager Supreme
Posts: 2634
Joined: Mon Aug 11, 2003 11:53 pm
Location: just outside bristol
Contact:

Re: PhotoChrome v6

Postby spiny » Thu Dec 05, 2013 10:18 am

nice !

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Thu Dec 05, 2013 10:28 am

AtariZoll wrote:I don't think that tri-field images will flicker significantly more than 2 field ones. Of course, will need more space.
There are some routines with 54 palette color changes per scanline, with 2 colors fixed. Did you try palette change with blitter ? In theory it could give more.


They do need a ridiculous amount of space unpacked yes.

54 palette swiches per line - that I believe is without overscan. Without overscan I can also do more.

I haven't analysed the colour references in the non-overscan mode but it could be anywhere between 56 and 64.

I think the most changes per line (with full overscan) was 48 on normal hardware. However I didn't search very hard so who knows.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Thu Dec 05, 2013 10:45 am

Xerus wrote:It looks really impressive but the flickering with 3 permutations may be too visible ?
I can't wait to see it on a real monitor !


Yes you're right of course - it is much harder to stabilize 3 fields esp. with lower refresh like 50hz. It will never be as stable as 2 fields for most cases, and the display type is also a big factor (looks better on TVs/CRTs than on flatscreen and non-sync'd emulation).

It's not too hard to prevent flicker - but to hide the interlacing effect (strange boiling movement) well requires a lot of care.

However the results look encouraging and some images definitely work much better than others. So if you're making a demo and select the image with care it seems to be valid and worth supporting as a new thing.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: PhotoChrome v6

Postby AtariZoll » Thu Dec 05, 2013 12:16 pm

dml wrote:..
I think the most changes per line (with full overscan) was 48 on normal hardware. However I didn't search very hard so who knows.

Yes. I think that 48 is max with horizontal overscan of 416 px. With only vertical overscan can use same line displaying code as with regular screen, except line 228 where we need some extra writes to video freq. register at line start.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Thu Dec 05, 2013 12:53 pm

AtariZoll wrote:Yes. I think that 48 is max with horizontal overscan of 416 px.


It used to be ;-)

User avatar
nativ
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4106
Joined: Mon Jul 30, 2007 10:26 am
Location: South West, UK

Re: PhotoChrome v6

Postby nativ » Thu Dec 05, 2013 5:41 pm

Forgot to comment earlier [smilie=greencolorz4_pdt_02.gif] [smilie=greencolorz4_pdt_08.gif] [smilie=greencolorz4_pdt_02.gif] [smilie=greencolorz4_pdt_01.gif]

and what is the most 'animated' screen colours available to do? The Ratio of colours per free cycles left for logic and other things ;D

are there GFA and STOS extensions / inlines ?

:cheers:
Atari STFM 512 / STe 4MB / Mega ST+DSP / Falcon 4MB 16Mhz 68882 - DVD/CDRW/ZIP/DAT - FDI / Jaguar / Lynx 1&2 / 7800 / 2600 / XE 130+SD Card // Sega Dreamcast / Mega2+CD2 // Apple G4

http://soundcloud.com/nativ ~ http://soundcloud.com/nativ-1 ~ http://soundcloud.com/knot_music
http://soundcloud.com/push-sounds ~ http://soundcloud.com/push-records

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Thu Dec 05, 2013 6:02 pm

nativ wrote:and what is the most 'animated' screen colours available to do? The Ratio of colours per free cycles left for logic and other things ;D


I can't answer this trivially because it would depend on what you are trying to achieve, or how many displaylines you want to use for the image.

For the mode I described here - specifically the fullscreen/overscan case - there are no cycles left for any of the active displaylines. Not even spare/dead ones within the scanline. They are all used to hold the image. If you give back displaylines in the top/bottom border, you get that percentage of CPU time back. If you give up some colour changes during the line, you get a few cycles free per line if you are able to use them (only by interleaving some custom asm with the displayrout - no other way to use those cycles)

Generally though, all hicolour modes of this kind consume 100% CPU for active displaylines and it's a matter of deciding how many lines you can afford, versus the other work you need to do. Inactive lines are free to use by the CPU. So most demos which use these modes, have to conduct their other business in the top/bottom border - and it's usually very limited.

There are exceptions to this but they are not 'typical' and usually for a specific effect.

If you want to move a lot of stuff around the screen while using extra colours I figured out a different way to do that which is written up in a separate thread. Then you have 100% CPU free, but limited to around 48-120 colours (most typically around the 64 mark).

nativ wrote:are there GFA and STOS extensions / inlines ?
:cheers:


For this? No - it's very new and I'm still working on the asm version. It's unlikely I'll be able do STOS/GFA versions myself - but I'll help anyone who wants to wrap a small asm module for those languages when it's done. There are extensions for the old PCS but they are very old (It's been too many years since I was anywhere near STOS).

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Thu Dec 05, 2013 6:12 pm

I'm going to try to post a combined test tonight (famous last words!).

I was already prepared to do this yesterday then ran into a really bizarre problem involving overscan and various power supplies - which probably merits a separate thread :)

This particular issue is now fixed (although it may not be the last of its kind) and so I'll try again. I'm a bit pushed for free time tonight so if it doesn't appear later it will be tomorrow or the weekened.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Thu Dec 05, 2013 7:06 pm

Here is a first test with one of the new modes and a tri-field image.

IMPORTANT: It should only be tried on a normal STE. This one is currently not compatible with STF, MegaSTE (or with TT/Falcon or any accelerated box). In time I'll show coverage for a better range of machines but this will have to do for now. If it just seems to quit back to the desktop it probably thinks you have the wrong type of machine. If it bombs out instead, it's probably a bug of mine.


This test uses the most extreme displaymode I have tried from the selection (416x272 x 52 changes per line) - but has dithering and other more advanced conversion settings disabled so the 3-field aspect is more clear.

It uses one of 3 available field interlace modes (I just picked one of them). On a CRT or TV it should look stable but you might see a mild swimming effect depending... On a LCD or scandoubler - well, good luck with that :)


It will kinda-work in Hatari/STeem but "it depends". I can give some hints how to tweak the emulators for the patient - but if it looks bad under emu, you don't need to report it to me :)

Lastly - it might still not work on some STEs because I have to fiddle with overscan timings. If you get weirdness, PM me with a photo of the mess and I'll take a look when I get time. I will be interested to try and fix that sort of thing. Please don't post hundreds of grabs in here because if its very broken there could be an endless sequence of them :) I'll only need one.

I'll try to make tests for the other modes sometime later. If anything is going to break though it's this one.
You do not have the required permissions to view the files attached to this post.

User avatar
Frank B
Atari God
Atari God
Posts: 1012
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: PhotoChrome v6

Postby Frank B » Thu Dec 05, 2013 7:44 pm

Very cool!

zerkman
Atarian
Atarian
Posts: 9
Joined: Fri Jun 17, 2011 7:14 am

Re: PhotoChrome v6

Postby zerkman » Thu Dec 05, 2013 9:04 pm

Hi, this looks really good. Great work Doug !

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Thu Dec 05, 2013 9:12 pm

zerkman wrote:Hi, this looks really good. Great work Doug !


Thanks!

TBH there wasn't very much room left to improve on your own MPP display - and I didn't begin with the aim to try, but to get something decent.

I just happened to find a way to use short blits between overscan toggles, by adjusting the toggle timing a very tiny amount - and so scraped a few more colours. The uniformity came with the blits. As did many other strange headaches. :)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Thu Dec 05, 2013 10:31 pm

Actually I've just noticed two problems with it since posting. I should probably fix both of those things at once and see if this helps further with colour timing. I don't really want to start changing the timings yet again but if I have to fix it anyway then it's worth a bit more effort.

User avatar
bullis1
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2301
Joined: Tue Dec 12, 2006 2:32 pm
Location: Canada
Contact:

Re: PhotoChrome v6

Postby bullis1 » Fri Dec 06, 2013 3:13 am

Firstly I must say that this is amazing :D
I wonder what the results would be like with some varied photographic sources? The best yet on ST to be sure but just how good?

Secondly, have you ever tried applying these techniques (or similar) to medium-resolution? Maybe it's already part of the Photochrome system but I can't recall seeing an example of it.
Member of the Atari Legend team

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Fri Dec 06, 2013 11:04 am

bullis1 wrote:Firstly I must say that this is amazing :D
I wonder what the results would be like with some varied photographic sources? The best yet on ST to be sure but just how good?


TBH I haven't tested this one (the tri-field part) enough yet to know what it's best for. It seems to work well on raytraced and painted images. I haven't tried photos.

The old PCS used to struggle with some types of photo in particular (saturated colour rainbows etc!) - not enough CCs per line and not evenly distributed enough.

In fact the displaymode presented in the uploaded sample (and the basis for the test images in the first post) is definitely not the limit on STE - there are still problems with it which can be fixed and I'm pretty sure it's possible to release another 2 colours at least. It would involve reconfiguring the overscan and I haven't been successful with that yet, partly because I'm not sure if that type of overscan is supported by emulators (and I haven't had time to test on STE - the turnaround cycle for me is quite slow here).

However I think it's fair to say you can *probably* get something between 54-60 colour changes per line with overscan specifically on STE (but not on STF) given enough time to frig around with non-stabilized border toggles and well tested timings.

bullis1 wrote:Secondly, have you ever tried applying these techniques (or similar) to medium-resolution? Maybe it's already part of the Photochrome system but I can't recall seeing an example of it.


No - it is a good idea, and I think it has also been tried. There is at least one demo which uses a multipalette image in medium res. I don't remember if it is also overscan (sorry - I forget the name but it displays a mountain range, somebody will remind me).

[EDIT] I remember now - it was this cool screen http://www.pouet.net/prod.php?which=12237 by RA/Paradox!

There are lots of contributing things happening in these multipalette systems (ignoring multi-field stuff), and they tend to be traded against each other (i.e. you can't have everything at once)

- number of changes applied per line - the most often quoted figure
- total number of colours which can be referenced in the line (this can be several more than the number of changes per line and depends on both the displayrout and the convertor)
- distribution/spacing of the changes - uneven bursts can give more colours in total, but leaves gaps where not many changes occur and can affect quality in places
- changing palette depth - how many colours available to any one pixel, and persistence of a colour across the screen - (can't be more than 4 in medium res, tends to vary 14-16 in low res depending on method)
- overscan causes some extra problems because changes must pause to perform border toggles etc.

The problem with medium res is the palette depth - you can have the same number of changes per line, but each colour change only 'lasts' for 4 change 'events' across the screen, with one change event averaging several lowres pixels (depending on speed of changes - higher speed = shorter persistence). So if a colour is needed several times across the screen it must 'steal' several colour changes to restore that colour value repeatedly to one of the 4 constantly-changing palette slots. Whereas a deeper palette means each change has greater persistance - e.g. can last for one third of the screen or even a whole line.

So in summary medium res can produce the same rate of colour changes and the same total number of colours in theory, but depending on the image there can be a lot of waste, continually reloading the same colour. However for some images this won't necessarily be a problem. It just won't work well for a wide range of images.
Last edited by dml on Fri Dec 06, 2013 11:39 pm, edited 1 time in total.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: PhotoChrome v6

Postby dml » Fri Dec 06, 2013 11:08 am

BTW the tool can also convert and display quad-field images (220k colours) - however attempts to stabilize these have not yet been successful. It is rather difficult :)

I might be able to crack this given enough effort but the images suck so much RAM (for the normal case, where bitmap+palette are unique) that it's probably not of great use.

Still it would be fun to have a 220k palette on an STE even if just for one very bodged image.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 2 guests