New "higheSTcolor" mode better than Photochrome & Spectrum

[Cyg]

Hi there !

It is a few days since I work on a new hicolor algorithm I called "higheSTcolor" to encode pictures compliant with my 55 colors per line display and here are some first promising results.

I will soon release a demo including some pictures based on this algorithms and the most important is its ability to produce very interesting effets. Any hicolor artist is welcome to participate to its design...

I added an average error % (luminance based, 19% R, 55% V, 26% B) compared to the original 256 R,V,B levels picture. No flicker option yet, some few improvements could still be possible (but with a flicker sensation). Theorical average error with a 16 levels perfect pixel per pixel conversion (320 colors per line) is : (16/2/2) / 256 = 1.625%

Enough talking, here are the results, screenshots made with steem, size doubled to have more details:

original_vallejo.jpg

higheSTcolor_STE4096-Floyd.jpg

higheSTcolor_ST512-Floyd.jpg

spectrum 4096.jpg

PCS 4096.jpg

Photchrome a.jpg

Other samples will follow...

Best regards,
Cyg / BLaBla

[spiny]

neat looking forward to the demo

[Dal]

This is impressive stuff! Looking forward to the demo

[Cyprian]

It is a few days since I work on a new hicolor algorithm I called "higheSTcolor" to encode pictures compliant with my 55 colors per line display and here are some first promising results.

55 colors per line? good result. does it work on STfm?

[nativ]

It is a few days since I work on a new hicolor algorithm I called "higheSTcolor" to encode pictures compliant with my 55 colors per line display and here are some first promising results.

55 colors per line? good result. does it work on STfm?

Third picture down is ST512


Is there a possibility of an animated screen using this technique?

There once was the Genesis demo... a 512 GFA Raytrace anim with Sample loop

[Cyprian]

It is a few days since I work on a new hicolor algorithm I called "higheSTcolor" to encode pictures compliant with my 55 colors per line display and here are some first promising results.

55 colors per line? good result. does it work on STfm?

Third picture down is ST512

true,
Cyg, how do you reach 55 colors per line on pure STfm?

[wongck]

This is impressive...

[dma]

Indeed impressive, i can't wait to see it displayed on my ST!
Is the screenshot ST or STe?

[Nyh]

Cyg, how do you reach 55 colors per line on pure STfm?

You have 512 clock cycles per scan line. Use them like this for 58 colors per line:

Code: Select all

     lea     $ff8244,a7
     lea     colors,a6
repeat loop starts here        ; clock:  pixelpos: comment
     movem.l (a6)+,d0-d7/a0-a5 ; 124
     movem.l d0-d6,(a7)        ;  64               14 start colors, there are two fixed colors
; here starts the displaying of the line
     movem.l d7/a0-a5,(a7)     ;  64      0 to  64 14 new colors, total 28 colors, first color change at pixel no 8
     movem.l (a6)+,d0-d7/a0-a5 ; 124     64 to 188
     movem.l d0-d6,(a7)        ;  64    188 to 252 14 new colors, total 42 colors
     movem.l d7/a0-a5,(a7)     ;  64    252 to 316 14 new colors, total 56 colors
     nop                       ;   4
     nop                       ;   4
total                          ; 512               56 + 2 fixed colors

Hans Wessels

[Cyprian]

thanks Nyh, that's looks very interesting.

[SofiST]

I think that displaying self is just one half of progams quality. How well usable, popular will it be depends much from how conversion self will be made. And it may be pretty much work ...

[Cyg]

Hi there,

Sorry for the delay in replying but I am currently on holidays and wifi spots are rare.

SofiST is right, the displaying rout is far easier than the conversion routine.

I missed a thing, my displaying rout is 55 different colors per line + 2 global colors.

Yes it works on STFm, see higheSTcolor_STF512-Floyd, there is no use of the blitter (I don't like "hardware" acceleration )

Nyh, your display routine is better than mine, +1 color per line, but the colors are not as regularly distributed (in the 2nd quarter and middle of the screen) which could lead to a bad conversion with some pictures.

I added a new sample with a RGB test picture :

RGB_24bits_palette_color_test_chart.jpg

RGB_hicolor_STE4096_Floyd.jpg

RGB_hicolor_STFM512_Floyd.jpg

rgb test pcs spectrum 4096.jpg

rgb test pcs.jpg

rgb test Photochrome.jpg

See you soon,
Cyg / BLaBla

[Scarlettkitten]

Great stuff, Looking forward to seeing the demo

[nativ]

mmmmm colours....

[wongck]

WOW the 4096 colour gradient don't look too bad, even better than photochrome.

[Nyh]

Nyh, your display routine is better than mine, +1 color per line, but the colors are not as regularly distributed (in the 2nd quarter and middle of the screen) which could lead to a bad conversion with some pictures.

Yes, I know, it was just an answer to a question how to display many colors. It seems my routine gave you some inspiration to improve on yours. That is great.

Can you show us your routine?

You should use .png format pictures instead of .jpg. We are looking at pixel level to so how good the pictures are. The .jpg format will introduce pixel errors and distort the picture a bit. That is not what we want in this case.

What routine are you using for color quantization? I think that is a very interesting subject: color quantization whit a variable color set.

Hans Wessels

[Cyprian]

What routine are you using for color quantization? I think that is a very interesting subject: color quantization whit a variable color set.

I'm interested in a such algorithm too. I'd like to add convert option BMP to SPC/SPS file, but I have no idea how to manage color quantization with variable color set.

[Cyg]

Hi again,

Nyh, no improvement between the Vallejo and the RGB test, but flicker methods are under construction with 2 quantization methods already done, improving again the result, I still have to do the display, few minutes of ASM work...
The simplest method is based on 32 levels of colors instead of the 16 of the STE (resp. 16 instead of 8 for STFM)
The more advanced method generate another "original" picture, taking the original pictures and adding the inverse of the errors produced by the quantization. So that by flicking you have an average picture closer to the orifinal. It seems to be the best method (and it includes a 32 level of colors).

caps are converted in JPG 100%, no visible quality is lost and it's smaller than PNG.

The routs and a sample displaying of the results for better understanding (helpful to me, for the quantization algorithm):

Code: Select all

; HigheSTcolors display rout. 1992-2011 Cyg / BLaBla
; colors 0 and 1 are global
lea	$ff8244,a6
lea	colors,a7
rept 199 ; 199 lines only, first line is lost because of the synchronisation, possibility for a lower border removal
movem.l (a7)+,d0-d7/a0-a5	; load 28 colors
movem.l d0-d6,(a6)			; display 14 colors at the beginning of the right border
movem.l (a7)+,d0-d6			; load 14 colors
movem.l d7/a0-a5,(a6)		; display 14 colors right after the end of the left border
movem.l (a7)+,a0-a5			; load 12 colors
movem.l d0-d6,(a6)			; display 14 colors
movem.l a0-a5,(a6)			; display 12 colors
move.w (a7)+,(a6)			; display 1 last color (3 nop)
endr

Steem__005 Copie.gif

Best regards,
Cyg / BLaBla

[Zorro 2]

Very happy to see you and welcome on this board mister Cyg

Your last production is Oldiez and I want to know how you did that

Thanx for the new challenge on ATARI ST

[nativ]

Hi,

I have a 15sec animation, I would like to use this 'colour process' to play it! Is that possible? Do you have any source code?

Many thanks
/nativ

[Cyg]

Hi,

Zorro2 : look at my quick answer about the tunnel effect in Oldiez on ATB forum. Wait for my next tunnel routine which will explode the quality of this one...

Nativ : you're served, see my attachments for a little surprise featuring 2 versions (for 1Mo and 2Mo memory computers). The video has been screencap frame per frame from a fullHD trailer, using no compression (I don't think it is possible to decompress a fullscreen picture fast enough...).
It could have been displayed in fullscreen but I wanted to preserve the aspect ratio and avoid some extra memory & diskspace, the framerate could also be higher.

2 Mo version displays 40 frames at 12.5Hz, 3 seconds at all. 15 seconds seems very difficult to achieve (is it something like a raytrace?)
Each frame weigth 55Ko in 320x199 (32Ko for the pixels, 23Ko for the colors).

I will not release the encoding process because it still needs many manual actions... You can send me your video and I will generate a preview of it => PM me

A preview:

Steem__017.png

HighAvat.zip

See U
Cyg / BLaBla

[dma]

Wow, really amazing rendering-wise, congrats again on your routs!

[bid]

This is very very cool.

PhotoChrome was a revelation to me for raytracing on the ST. And unfortunately I could never find a working copy of Spectrum 512 ( I did find a boxed one at a flea market for a couple of quid, but the disks were corrupt ). I would love to see this complete, but also with an interface and not just for demos, so we can load up raytrace images into it etc.

This is amazing work!

[SofiST]

Looks really great. I thinkered little about making hard disk version, which could run longer animations even with 512K RAM only . Someone proposed it earlier for Photochrome images . Then I said that it is not possible due high transfer rate needed.
Still, I say that it is possible with limited res (so not full screen ST low) and limited framerate - less than 25 fps.
Main problem is that multicolor presentation (to call it so) eats about 65% of CPU time. So, for hard disk load is left not much. It limits tranfer rate to max 600KB/sec aprox - and only with fastest hard disk adapters, what not much people have. Someone may say: 'use DMA' . Well, it works not, actually DMA is pretty useless here - although I have IF which can 2MB/sec on DMA, it is not good, as DMA transfer screws multicolor displaying (stops CPU during transfer, about 2.5% for each 100 KB/sec. ) . So, DMA should work only when no line scan, what is max 37% of CPU time. And it would require some very advanced code, loading not via regular GEMDOS, as it not provides sync with video.
What would be possible is 12.5 fps and lower res - let say some 200 x 120 px. But it still needs special loading from HD to avoid screen screwing, at least with ACSI. With IDE it should be easier, as V interrupt can stop IDE transfers.

[Zorro 2]

Bravo Mister Cyg

Here the final result : Street Art (http://pouet.net/prod.php?which=58056)