An interesting way to get more colours on an ST/E...

All 680x0 related coding posts in this section please.

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

Zamuel_a
Atari God
Atari God
Posts: 1223
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: An interesting way to get more colours on an ST/E...

Postby Zamuel_a » Thu Mar 27, 2014 6:58 am

Is there any available code / tools available to create high color images? I had liked to use that in a project I'm working on. Either a CPU consuming method (If I play YM music at the same time) or a more CPU friendly if I chose a mod player.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
Cyprian
Atari God
Atari God
Posts: 1488
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: An interesting way to get more colours on an ST/E...

Postby Cyprian » Thu Mar 27, 2014 9:23 am

Zamuel_a wrote:Is there any available code / tools available to create high color images? I had liked to use that in a project I'm working on. Either a CPU consuming method (If I play YM music at the same time) or a more CPU friendly if I chose a mod player.



yes, look at DML footer and go to section "PhotoChrome & related"
http://www.leonik.net/dml/sec_atari.py
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

Zamuel_a
Atari God
Atari God
Posts: 1223
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: An interesting way to get more colours on an ST/E...

Postby Zamuel_a » Thu Mar 27, 2014 11:26 am

yes, look at DML footer and go to section "PhotoChrome & related"
http://www.leonik.net/dml/sec_atari.py


I could only find the conversion tools here. I would also need a simple viewer in assembly code.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
bod/STAX
Atari Super Hero
Atari Super Hero
Posts: 508
Joined: Wed Nov 24, 2004 8:13 pm
Location: Halesowen, West Midlands, England

Re: An interesting way to get more colours on an ST/E...

Postby bod/STAX » Thu Mar 27, 2014 11:53 am

Are you looking to display Photochrome PCS images?

If so you can find the source-code for the 'PCS Display Module' here (in full 68000):

http://www.atari-forum.com/viewtopic.php?f=16&t=13124&p=113851&hilit=photochrome+source#p113851

This code has the depack code and display routine included.
So let it be written, So let it be done. I'm sent here by the chosen one.

Zamuel_a
Atari God
Atari God
Posts: 1223
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: An interesting way to get more colours on an ST/E...

Postby Zamuel_a » Thu Mar 27, 2014 12:44 pm

Are you looking to display Photochrome PCS images?

If so you can find the source-code for the 'PCS Display Module' here (in full 68000):

viewtopic.php?f=16&t=13124&p=113851&hilit=photochrome+source#p113851

This code has the depack code and display routine included.


Thanks! This seems to be what I was looking for :D

I tested it and noticed that it always needed two images (to flicker between). I guess it's easy to adjust it to only handle one image mode aswell.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
bod/STAX
Atari Super Hero
Atari Super Hero
Posts: 508
Joined: Wed Nov 24, 2004 8:13 pm
Location: Halesowen, West Midlands, England

Re: An interesting way to get more colours on an ST/E...

Postby bod/STAX » Thu Mar 27, 2014 1:05 pm

Zamuel_a wrote:I tested it and noticed that it always needed two images (to flicker between). I guess it's easy to adjust it to only handle one image mode aswell.


It's pretty straight forward.

If you rip out the depack code you can save the two images and palettes as raw data files (this is how I did the intro picture for my game).

The same for the display routine.

AFAIR the 'Module' takes the picture data and displays it correctly whether you're using two picture/palette interlacing or not. It also set's the screen frequency
to how you display it within Photochrome.
So let it be written, So let it be done. I'm sent here by the chosen one.

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

Re: An interesting way to get more colours on an ST/E...

Postby Anima » Thu Mar 27, 2014 3:54 pm

Here is a short tutorial how I did the image creation.

You'll need ImageMagick and two simple C# programs. Download AtariEnhancePalette.exe (source) and AtariEnhanceImage.exe (source) and put both binaries into one folder. Put the shell script into the same folder. To watch the result on the Atari here's a small viewer as well.

As an example I'll take this as the source image:

Image

Save this image to the same folder as well.

Now you should find these files in the folder:

Code: Select all

AtariEnhanceImage.exe
AtariEnhancePalette.exe
enhance.sh
nature.jpg


Running the command

Code: Select all

enhance.sh nature.jpg

...should create the following files

Code: Select all

atari.png
palette.png
enhanced.png
1.png
2.png
1.pi1
2.pi1

...and they should look like the following images.

atari.png (16 unique colours):
Image
palette.png (94 unique colours):
Image
enhanced.png (94 unique colours):
Image
1.png (16 unique colours):
Image
2.png (same 16 unique colours as 1.png):
Image

And also the two Degas images 1.pi1 and 2.pi1 which can be viewed with this online tool. Actually, both images are identical to 1.png and 2.png respectively.

So finally enhanced.png is the "image to be expected". 1.png and 2.png are the alternate displayed images sharing a single 16 colours palette.

Here's the shell script (enhance.sh):

Code: Select all

#!/bin/sh

convert $1 -quantize sRGB -resize 320x200 +dither -colors 16 -fx '((u * 255) & 0xf0) / 255' atari.png
identify -format "%k, " atari.png

./AtariEnhancePalette.exe atari.png palette.png
identify -format "%k, " palette.png

convert $1 -quantize sRGB -resize 320x200 -ordered-dither o4x4,32 +dither -remap palette.png enhanced.png
identify -format "%k\n" enhanced.png

./AtariEnhanceImage.exe atari.png enhanced.png

And the simple viewer source:

Code: Select all

.global _main

   .text

_main:
   jbsr   load_images
   jbsr   init

   clr.b   0x8260.w

   movem.l image1_palette,d0-d7
   movem.l d0-d7,0x8240.w

   cmpi.b  #0x1+0x80,0xfc02.w
   jne      1b
1:
   move.b   0xfc02.w,d0
   btst   #4,0xfa01.w
   jeq      1b

   jbsr   restore

   clr      -(sp)
   move   #0x4c,-(sp)
   trap   #1

load_images:
   clr      -(sp)
   pea      image1_filename
   move   #61,-(sp)
   trap   #1
   addq   #8,sp

   move   d0,d7

   pea      image1_palette
   move.l   #2,-(sp)
   move   d7,-(sp)
   move   #63,-(sp)
   trap   #1
   lea      0xc(sp),sp

   pea      image1_palette
   move.l   #32,-(sp)
   move   d7,-(sp)
   move   #63,-(sp)
   trap   #1
   lea      0xc(sp),sp

   pea      image1
   move.l   #32000,-(sp)
   move   d7,-(sp)
   move   #63,-(sp)
   trap   #1
   lea      0xc(sp),sp

   move   d7,-(sp)
   move   #62,-(sp)
   trap   #1
   addq   #4,sp

   clr      -(sp)
   pea      image2_filename
   move   #61,-(sp)
   trap   #1
   addq   #8,sp

   move   d0,d7

   pea      image2_palette
   move.l   #2,-(sp)
   move   d7,-(sp)
   move   #63,-(sp)
   trap   #1
   lea      0xc(sp),sp

   pea      image2_palette
   move.l   #32,-(sp)
   move   d7,-(sp)
   move   #63,-(sp)
   trap   #1
   lea      0xc(sp),sp

   pea      image2
   move.l   #32000,-(sp)
   move   d7,-(sp)
   move   #63,-(sp)
   trap   #1
   lea      0xc(sp),sp

   move   d7,-(sp)
   move   #62,-(sp)
   trap   #1
   addq   #4,sp

   rts

init:
   clr.l   -(sp)
   move   #0x20,-(sp)
   trap   #1
   addq   #6,sp
   move.l  d0,old_ssp

   move   #0x2700,sr

   movem.l 0x8240.w,d0-d7
   movem.l d0-d7,old_palette

   move.b   0x8260.w,old_res
   move.b   0x820a.w,old_hz

   move.b   0x8201.w,old_screen+1
   move.b   0x8203.w,old_screen+2
   move.b   0x820d.w,old_screen+3

   move.b   0xfa07.w,old_fa07
   move.b   0xfa09.w,old_fa09
   move.b   0xfa13.w,old_fa13
   move.b   0xfa15.w,old_fa15

   move.l   0x70.w,old_vbl

   clr.b   0xfa07.w
   clr.b   0xfa09.w
   clr.b   0xfa13.w
   clr.b   0xfa15.w

   move.l   #vbl,0x70.w

   move   #0x2300,sr

   rts

restore:
   move   #0x2700,sr

   movem.l old_palette,d0-d7
   movem.l d0-d7,0x8240.w

   move.b   old_res,0x8260.w
   move.b   old_hz,0x820a.w

   move.b   old_screen+1,0x8201.w
   move.b   old_screen+2,0x8203.w
   move.b   old_screen+3,0x820d.w

   move.b   old_fa07,0xfa07.w
   move.b   old_fa09,0xfa09.w
   move.b   old_fa13,0xfa13.w
   move.b   old_fa15,0xfa15.w

   move.l   old_vbl,0x70.w

   move   #0x2300,sr

   move.l   old_ssp,-(sp)    | Supervisor off
   move   #0x20,-(sp)
   trap   #1
   addq   #6,sp

   rts

vbl:
   move.l   d0,-(sp)

   move.l   image1_address,d0
   move.l   image2_address,image1_address
   move.l   d0,image2_address

   move.b   image1_address+1,0x8201.w
   move.b   image1_address+2,0x8203.w
   move.b   image1_address+3,0x820d.w

   addq   #1,vbl_counter

   move.l   (sp)+,d0

   rte

     .data

image1_filename:
   .asciz   "1.pi1"

image2_filename:
   .asciz   "2.pi1"

   .even

image1_address:
   dc.l   image1

image2_address:
   dc.l   image2

   .bss

old_ssp:

   ds.l   1

old_screen:
   ds.l   1
old_palette:
   ds.l   256
old_videl:
   ds.l   11

old_line_f:
   ds.l   1
old_trap_f:
   ds.l   1
old_vbl:
   ds.l   1
old_keyboard:
   ds.l   1

old_res:
   ds.b   1
old_hz:
   ds.b   1

old_fa07:
   ds.b   1
old_fa09:
   ds.b   1
old_fa13:
   ds.b   1
old_fa15:
   ds.b   1

   .even

vbl_counter:
   ds.w   1

image1_palette:
   ds.w   16

   .align 4

image1:
   ds.b   32000

image2_palette:
   ds.w   16

   .align 4

image2:
   ds.b   32000

   .end


Edit: colour count added, spelling.

Cheers
Sascha

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

Re: An interesting way to get more colours on an ST/E...

Postby dml » Thu Mar 27, 2014 11:21 pm

bod/STAX wrote:AFAIR the 'Module' takes the picture data and displays it correctly whether you're using two picture/palette interlacing or not. It also set's the screen frequency
to how you display it within Photochrome.


That's correct - the displayer will adapt to the type of image which was converted with the tool. If you convert a single-field image that's what it displays. Likewise for a 2-field image.

It doesn't pay to generate a 2-field image and steal one of the fields because then it will have luminosity offset and dithered incorrectly. It will also have colours allocated less efficiently than a single-field image and may have extra errors as part of 2-field conversion (and will be 'twice' as visible when not viewing both fields together).

So better convert the type of image you need, and let the module use that display config for best results.

[EDIT]

Note than the recent rewrite of the v5 (and soon v6) tool (coded in c++) does a much better job of converting the images than the old v3,v4 tools which were coded many years ago in 68k for an 8mhz ST. It is also much much slower :)

Note also that v5 onwards can convert images to any custom display routine using ASCII timing tables. So if you come up with a better displayrout and fancy timings, you can use the tool to make images for that quite easily (Two ST projects have made use of this feature already, and both have helped to improve it as a result).

Zamuel_a
Atari God
Atari God
Posts: 1223
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: An interesting way to get more colours on an ST/E...

Postby Zamuel_a » Fri Mar 28, 2014 7:57 am

I tested v5 and it works ofcourse, but I saw that there are ALOT of different settings, so might take a while to find what is best for my image :D I tried the settings from the documentation "pcs5 –cd ste –f 2 –m 5 –nnd 12 –lt 3 –dt 0 –et 1 –ei 4 test.png"

and tried to change -f between 1 and 2. If possible I had liked to use only one image (the original only has about 3500 colors so it's not in need of to much). Is there a way to reduce the look of horisontal lines that build up the image? I think a dither effect had been better. I tried the dither setting, but didn't really seems to help.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

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

Re: An interesting way to get more colours on an ST/E...

Postby dml » Fri Mar 28, 2014 9:49 am

Hi,

Zamuel_a wrote:I tested v5 and it works ofcourse, but I saw that there are ALOT of different settings, so might take a while to find what is best for my image :D I tried the settings from the documentation "pcs5 –cd ste –f 2 –m 5 –nnd 12 –lt 3 –dt 0 –et 1 –ei 4 test.png"

and tried to change -f between 1 and 2. If possible I had liked to use only one image (the original only has about 3500 colors so it's not in need of to much). Is there a way to reduce the look of horisontal lines that build up the image? I think a dither effect had been better. I tried the dither setting, but didn't really seems to help.


I'd expect to see horizontal lines if you use '-lt 1' (interlace type 1 = horizontal), but '-lt 3' uses a checker pattern so you shouldn't get lines.

If you use '-f 1' for a single field, you can disable '-et 1' with '-et 0' because '-et 1' (field diffusion) it only make sense for multiple fields. It spreads colour error between fields. Alternatively you could use '-et 2' for error diffusion e.g. floyd-steinberg.

It might be better for me to see your image to understand what kind of lines you are getting. You can PM the file with commandline etc. and I'll take a look.

Sorry, the manual is not really finished and only has a quickstart guide - the readme.txt has much more info in it on settings, but again some are not yet added, such as the 8 or so alternatives to floyd-steinberg. I still need to revise the text and finish the manual.

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

Re: An interesting way to get more colours on an ST/E...

Postby Anima » Fri Mar 28, 2014 5:52 pm

I have set up a simple converter website which can be used to create images for the technique described earlier. Please note that the service is not permanent online because it runs in the Amazon cloud.

Cheers
Sascha

User avatar
CiH
Atari God
Atari God
Posts: 1120
Joined: Wed Feb 11, 2004 4:34 pm
Location: Middle Earth (Npton) UK
Contact:

Re: An interesting way to get more colours on an ST/E...

Postby CiH » Wed Apr 23, 2014 11:25 pm

I have set up a simple converter website which can be used to create images for the technique described earlier. Please note that the service is not permanent online because it runs in the Amazon cloud.


I managed to get a few pictures done. The results tend to work particularly well for photos.

Molly_STE.jpg
You do not have the required permissions to view the files attached to this post.
"Where teh feck is teh Hash key on this Mac?!"

User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1034
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: An interesting way to get more colours on an ST/E...

Postby MasterOfGizmo » Fri Apr 25, 2014 6:47 pm

I ran this on the MIST using LCDs as well as one old CRT. The first two demos look great on the CRT. But on the LCDs they look pretty much the same as under hatari on a PC connected to a LCD. So it's probably not emulation that causes the problems but the LCDs.

I don't have a real STE. How do these look on a real STE connected to an LCD screen? Since todays LCDs are designed to be fast i am not surprised to see the 25HZ flickering which is barely visible with static images but becomes pretty obvious if the image scrolls.

And the third demo totally kills video on the MIST as the routine used to open the bottom border only works every now and then and the screens all refuse to display anything in that case. I noticed that the bottom border of the thirst demo also looks strange under hatari. Does this really work reliably on a real STE?
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki

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

Re: An interesting way to get more colours on an ST/E...

Postby Anima » Fri Apr 25, 2014 7:44 pm

I have the same effect here on the LCD TV connected to the Falcon. It seems to be the interlace filter.

Cheers
Sascha

User avatar
MasterOfGizmo
Atari God
Atari God
Posts: 1034
Joined: Fri Feb 08, 2013 12:15 pm
Contact:

Re: An interesting way to get more colours on an ST/E...

Postby MasterOfGizmo » Fri Apr 25, 2014 7:56 pm

This equally happens with LCD computer screens and those don't have a deinterlacer.

Gesendet von meinem Nexus 7 mit Tapatalk
MIST board, FPGA based Atari STE and more: https://github.com/mist-devel/mist-board/wiki

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

Re: An interesting way to get more colours on an ST/E...

Postby dml » Fri Apr 25, 2014 8:35 pm

Hi,

I tested this briefly at the time, on a LCD TV and LCD (TFT?) VGA monitor - an older model. It does look different from CRT for sure, but the interlace was stable and I wouldn't say worse than expected. The higher refresh rate helps, but the image persistence is lower so on balance its a bit worse than CRT.

I didn't see anything that looked like the problems I had under emulation - and those are easily explained because I can see frame drops/duplication from 50hz up to 70hz quite easily. I've had lots of practice there ;) It's also possible to correct it via configuration in the emulator if the machine/OS also permits it. So I'd say problems with emulation and LCDs are quite separate things.

There could still be a problem with LCDs I did not see, specific to some models/technologies?

The border removal code - it worked on my STE but I certainly won't claim it's great, compatible stuff. :-) I did everything in a bit of a hurry. Just examples really to show the approach with moving graphics.

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

Re: An interesting way to get more colours on an ST/E...

Postby Anima » Fri Apr 25, 2014 11:59 pm

CiH wrote:
I have set up a simple converter website which can be used to create images for the technique described earlier. Please note that the service is not permanent online because it runs in the Amazon cloud.


I managed to get a few pictures done. The results tend to work particularly well for photos.


The service is online again with some enhancements and also some bugs. :lol:

Cheers
Sascha

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

Re: An interesting way to get more colours on an ST/E...

Postby dml » Mon Apr 28, 2014 10:00 am

Anima wrote:
CiH wrote:
I have set up a simple converter website which can be used to create images for the technique described earlier. Please note that the service is not permanent online because it runs in the Amazon cloud.


I managed to get a few pictures done. The results tend to work particularly well for photos.


The service is online again with some enhancements and also some bugs. :lol:

Cheers
Sascha


Cool :-) It was quite a good idea to 'cloud' it - I'm not sure of the details in your solution but it should certainly reduce the complexity of the problem in some directions at least. And it does let people play with the idea.

I did make some progress towards finishing mine but it grew arms and legs (converting images, playfields, texture sets for a recent demo) and I am still too busy to post it with instructions so now I don't feel in such a rush there :-)

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

Re: An interesting way to get more colours on an ST/E...

Postby Anima » Mon Apr 28, 2014 11:24 am

dml wrote:Cool :-) It was quite a good idea to 'cloud' it - I'm not sure of the details in your solution but it should certainly reduce the complexity of the problem in some directions at least. And it does let people play with the idea.


Yes, exactly: it's kind of a playground for image enhancement tests. ;)

I'll post some details later on if the time permits.

Cheers
Sascha

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

Re: An interesting way to get more colours on an ST/E...

Postby dml » Wed Apr 30, 2014 9:10 am

Since Anima has brought a revival to this topic :-) I have added some instructions to PCS6 to allow the original CryptoChrome tool to be used with that release.

https://dl.dropboxusercontent.com/u/129 ... S6-Win.zip

I'm pretty sure this will run on a 32bit Windows - but I'm on x64 now so I haven't tested that. I'll fix it later if there's a problem.

For those who might have missed it, this tool does the same job Anima's web-based tool, but on a desktop PC. It was written in 2012 and used to make a few demos which can be found earlier in this thread - and STRay 3D engine which can be found in another thread - but I got distracted with other stuff (well, I'm trying to complete BadMood with the small free time I have left and this is quite a big job) so the original tool didn't get released.

The standalone tool is probably also a more fiddly to control because a big part of the problem is computing an accurate palette in a reasonable time without being exhaustive. The longer you're prepared to wait (and fiddle with settings), the better the result. A cloud doesn't have that issue, so exhaustive probably works fine! There are also some settings for managing flicker at the cost of accuracy and so on.

The results I got for the CCDEMO scrolling demos in this thread, and STRay Wolf3D engine (different thread) seemed worthwhile. I have not compared with Anima's result, but remain aware of the note above if you want to do that. And be particularly aware that you'll get better results as you learn how to use the settings ;-) It's not all that hard to produce bad results without getting a bit experience with those.


So I now have some some parameters and instructions tied up, so PhotoChrome 6.10 effectively contains both tools in the same executable. The 'ccmode' argument switched between them.

This is the default, and will select PhotoChrome conversion:
-ccmode 0

-ccmode 1 onwards will select CryptoChrome modes - all of which are based on converting different kinds of material.


Code: Select all

   CCMode_NONE = 0, // normal PhotoChrome job
   CCMode_IMAGE = 1,  // CryptoChrome: output PI1s
   CCMode_PLAYFIELD = 2, // CryptoChrome: output background tilesets and map for CCDEMO scrolling playfield demo
   CCMode_TEXTURESET = 3, // CryptoChrome: output 3D texture set with mipmaps for STRay demo



You can (slowly) convert an image with default settings using this commandline:

./pcs5 -ccmode 1 -ccrounds 1 -ccthreads 1 -ccsat 1.0 -ccgamma 1.0 -ccincap 256 mytest.png

This will emit a pair of PI1s. Other ccmodes will emit ... other formats which I have not documented. The background mode will produce a pair of tilesets and a pair of maps to draw playfields with those tilesets. The texture mode will convert multiple files into one CC palette, and produce c2p maps to assist with drawing 3D textures.

However to get good results, you will need to compute more 'rounds'

./pcs5 -ccmode 1 -ccrounds 24 -ccthreads 1 -ccsat 1.0 -ccgamma 1.0 -ccincap 256 mytest.png


...but to speed things up, you will benefit from spreading over more CPU cores (a 4-core CPU with HT can use 6 threads effectively)....

./pcs5 -ccmode 1 -ccrounds 8 -ccthreads 6 -ccsat 1.0 -ccgamma 1.0 -ccincap 256 mytest.png


To get a preview of what the image should look like, and what the fields look like on the PC, add the '-dg' argument for diagnostics.

./pcs5 -dg -ccmode 1 -ccrounds 8 -ccthreads 6 -ccsat 1.0 -ccgamma 1.0 -ccincap 256 mytest.png

This will emit:

field0/field1.png (noninterlaced fields)
ifield0/ifield1.png (interlaced fields)
composite0.png (final, merged result)

To improve the relative accuracy of results, desaturate the source image slightly:

./pcs5 -dg -ccmode 1 -ccrounds 8 -ccthreads 6 -ccsat 0.8 -ccgamma 1.0 -ccincap 256 mytest.png


To speed up conversion, reduce the cap on the input colour histogram:

./pcs5 -dg -ccmode 1 -ccrounds 8 -ccthreads 6 -ccsat 0.8 -ccgamma 1.0 -ccincap 128 mytest.png


To get more accurate results, increase the cap on the input colour histogram (at the expense of a longer wait!):

./pcs5 -dg -ccmode 1 -ccrounds 8 -ccthreads 6 -ccsat 0.8 -ccgamma 1.0 -ccincap 4096 mytest.png


The rest of the settings are mainly to control image quality and flicker, and this depends a lot on the type of material being converted, the colour content, how it will be used... etc. I don't have time to explain all of that now but will do so another time.



Code: Select all

$ ./pcs -h
PhotoChrome/CryptoChrome ST/E image tool v6.10
built on Apr 30 2014
usage:
 pcs [opts] [-o <outfile>] [infile(s)]

 infile = filename or glob (*.ext)

 -?, -h, --help         > show help/usage
 -v, --verbose          > more output
 -q, --quiet            > less output
 -k, --wait-key         > wait key on exit
 -dg, --diagnostics     > emit diagnostics

 CryptoChrome commands:
 -ccmode                > 0=PhotoChrome, 1..N=CryptoChrome
 -ccrounds              > # competition rounds per thread
 -ccthreads             > # competing CPU threads
 -ccsat                 > saturation level 0.0-1.0
 -ccincap               > cap input colour count
 -ccmaxtrap             > stop round after N useless iters
 -ccseek                > seek rate
 -ccseed                > seed for PRNGs
 -ccgamma               > gamma level (1.0 = no change)
 -ccdls                 > differential luma significance
 -ccdcs                 > differential chroma significance
 -ccapc                 > accuracy population curve
 -ccapc                 > differential population curve

 PhotoChrome commands:
 -f, --fields           > # image fields 1-4
 -fm, --fieldmode       > # field mode 0,1,2
 -m, --method           > reduction type 0-6
 -lt, --lace-type       > i'lace method 0-6
 -dt, --dither-type     > input dither 0-8
 -dl, --dither-level    > dither strength 0.0-1.0
 -et, --error-type      > output diffusion 0-2
 -el, --error-level     > error feedback 0-100%
 -ei, --error-iters     > FIELD error iterations
 -spet, --spatialerr-type       > spatial error type 0-8
 -nnd, --nn-depth       > neural net depth 1-16
 -nnb, --nn-breadth     > neural net breadth 0.0-1.0
 -nnr, --nn-rate        > neural net rate 0.0-1.0
 -pfmg, --pfm-gamma     > PFM gamma
 -pfmi                  > PFM influence
 -pfms, --pfm-source    > PFM source PNG

 -pct, --pct-source     > palette conversion table (.CSV)
 -dpt, --dpt-source     > dynamic point table (.CSV)

 -cd, --colour-depth    > st/3, ste/4
 -x, --xsize            > image width (320)
 -y, --ysize            > image height (200)
 -s, --storage          > output format 0-5

press any key...


Unfortunately some other aspects of PCS6 are still unfinished so the 3- and 4- field conversions won't work as intended and I haven't documented the file formats for that either, so best ignore that side of it for now.

Some of the arguments are useless without knowing their defaults and how to decide when to change them - I'll write that up separately next time I get half an hour free.


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 2 guests