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

You do not have the required permissions to view the files attached to this post.

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

You do not have the required permissions to view the files attached to this post.

Cyg wrote: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.

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):

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 UCyg / BLaBla

You do not have the required permissions to view the files attached to this post.

Last edited by Cyg on Thu Jul 07, 2011 8:10 am, edited 1 time in total.

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.

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.