Conference hydra::amiga_v1

    
    It's a really great tool!
    I'd konverted some files and displayed them on a VT340 and all the
    gang here did a ooooooooooh!
    
    
    Tim.

    I have to agree. This is one great tool to have on hand.  I have
    used it with an LJ250...  Talk about spectacular results !!
    
    Thanks for your efforts.  All of us will profit from this work.
    
    
    =jbf=

    I've been playing around with it on my VT340. The results have been
    nothing short of superb. I put the Prego and Sanka ILBMs from the
    NewTek demo on line. Tough to tell them apart from the Amiga versions!
    Black & white reproductions using DigiView at 640x400 are truly
    superb since they display at nearly the full screen size of a VT340.
    Unfortunately, they take a few minutes to display even through the
    LAT at 19.2 Kbaud.
    
    Well, looks like a whole new generation of junk mail is about to
    make its way onto the Ethernet!
    
    Paul

    Thanks for the good words.
    
    Does anyone have a good algorithm for changing a HAM pic to an "n" bit
    plane picture?  (N should go as high as 8 since several printers
    support 256 colors).  Off the cuff, I'd do something like the
    following:
    
    1.  Make a list of all the colors in the picture.  Counting the
        number of times that each occurs.  Sort this list and take the
        most frequent N colors.  This will be the color map to use.  All of
        this takes one pass at the bitmap.
    
    2.  Make a second pass at the bitmap to create the new non-HAM picture.
        Colors which were not in the top N need to be mapped to the
        "closest" color possible.  So, how do I measure the similarity
        of two colors given their RGB values?
    
    I'm sure their are better ways to do this.  Any suggestions?
    
    - steve

>        "closest" color possible.  So, how do I measure the similarity
>        of two colors given their RGB values?



Cant you just treat the RGB values as a single n-bit number and compare colors
by numeric value?

For example, say sizeof R= sizeof G= sizeof B = 8 bits each. Now you have
a 24 bit number:
         31       24 23      16 15       8  7       0
	+-----------+----------+-----------+--------+
        |  pad=0    |    "R"   |    "G"    |  "B"   |
	+-----------+----------+-----------+--------+


Now compare that to each color (with RGB and pad in same format) - closest
one wins:


	LONG	color;			/* Color to match */
	LONG	colors[N];		/* Table of known colors */
	BYTE	MIN=-1;			/* min difference between colors */
	BYTE	idx;			/* Index of best match */
	
        for(i=0 ; i<N ; i++) {
           if(ABS(color-colors[i]) < MIN) {
             MIN = ABS(color-colors[i]);
             idx = i;
           };
        };

	COLOR = colors[idx];		/* Selected color */

    you could treat it as a 3-d vector and compare angle and magnitude.
    rgb ~ xyz
    Tom

    re: .5  (Leaving the bytes together and padding to an int or short)
    
    The problem with this is that it may produce colors which are not
    similar to the original.  If you keep the RGB order it will in effect
    match R as good as possible, then match G as good as possible, then match
    B as good as possible.  So (2,15,15) would match (2,0,0) before
    it matched (0,15,15).
    
    re: .6  

    This angle and magnitude method is definitely one way to do it.

    For Tom's method I suppose I could try:
    
      Rank(R,G,B,r,g,b) = ((R-G)-(r-g))**2 + (G-g)**2 + ((B-G)-(b-g))**2
    
    Then pick the match with the smallest rank.
    
    Come to think of it how about:
            
      Rank(R,G,B,r,g,b) = (R-r)**2 + (G-g)**2 + (B-b)**2
    
    Sort of a least squares fit on only two points.  Then pick the smallest
    rank.

    Any comments on which would be better?  Any other suggestions?
    
    - steve   

How about visualizing the desired RGB value as a point in a 16x16x16 cube. You
would then simply select and use one of the other available colors in the cube
which has the minimum distance to the desired color point. That distance would
be:

	SQRT( (R2-R1)� + (G2-G1)� + (B2-B1)� ) 

However, it might improve things if one could look around the area of the
desired pixel to see what the predominant colors were. This might also influence
the choice of colors. 

Dave

    How tough would it be to go the other way?  i.e.  Color Sixel to IFF.
    There are bunches of picture files (.gid) for the pro I would like
    to modify for presentations, but would like to use the Amiga to
    do the modifications.  Once done, then convert back to sixel.
    
    by the way, CSIX is GREAT!!!!
    
    
    John
    

    CSIX works find for me.
    
    Was IFF_SIX.EXE the program that converted IFF to LA50 type
    sixel? Do any of you know where this then resides?
    
    Thx..
    ..R

    
    I've put another version of CSIX in ANT::LIB1:[SMCAFEE.PUBLIC]CSIX.ARC.
    This one will translate HAM pics.  The method used is really ad
    hoc.  I just take the most common 256 colors and use those to print
    the picture.  I think the results would be better if I changed the
    color registers on the fly.  This would produce more colors, but
    the file would get larger.
    
    I've been playing with the percentage color map and results seem
    to vary greatly.  You might want to fiddle with "lin_pct[16]" in
    csix.c if you don't like what you're getting.
    
    I've only had a chance to process one HAM picture with this so let
    me know if there are any problems.  If anyone has any online let
    me know and I'll give them a shot.
    
    Also, our LPS40 seems to be down so I've only been using the LJ250.
    Let me know if there are any problems with the colors on the LPS40.
    
    -  steve

    Hi all!
    
    I uploaded and converted some of my Amiga Pics to VAX-Sixel. If
    anyone is interested in taking a look at my pic-collection try the
    following adress:
    
    >>>>> FROCKY::$1$DUS14:[SCHABACKER.PIC] <<<<<<
    
    There are also some none Amiga-graphics.
    I have also some hot girls (for adults only!) if you are interested
    contact me!
    
    Where are your uploaded and convertede pictures from your Amiga?
    
    The effect from these Pices is the best, when viewing on a VT340!
    
    The best one is ATARI.SIX, you must see it!
    
    much fun
              Tim.
    

Hi!

I cleaned up my directoy's and sorted my graphics to new locations:

            FROCKY::$1$DUS14:[SCHABACKER.GRAPHIC.CRT]
                                                .REGIS]
                                                .SIXEL]
                                                .PS]
                                                .FONT]
                                                .PROMPT]
                                                .JOKE]

have fun with my little optical collection!

If you get new graphics, let me know and I'll put them to the right place!

happy computing
                 Tim.

PS: The hot girls are still at their old location!

    Where is the latest version of CSIX.ARC  ???
    
    It seems to be not accessible on ANT::LIB1:[SMCAFEE.PUBLIC]
    
    Phil

    mtwain::user:[macdonald.amiga.vms]
    

    Today is my last day in LMO.  I will be starting in LTN1 on Monday
    (Feb 6).  So my ANT account will be gone within two weeks.  However,
    the reason no one can get at my account is due to DECNET access
    being disabled on our systems (ever since the virus problem a
    few weeks ago).
    
    - steve m.

I'm trying to track down a copy of this.  Anyone still have it?
jim

    re: CSIX.EXE
    
    I'm certain that a copy is up on TAPE somewhere, try
    
    $ dir tape::user1:[amiga...]csix.exe
    
    					Alan T.

FWIW I fixed a bug in CSIX which was producing lines across the image
     when it contained a mask plane.  I put the new version in
     NORSE::AMIGA:[UPLOAD]CSIX_13B.ARC.  It's arc'd but this is for VMS.

- steve

It seems there was still a problem with masks in the version I posted in
on Norse a few minutes ago.  I've fixed the problem and put a new version
CSIX_13C.ARC NORSE::AMIGA:[UPLOAD].


regards,

steve

Thanks Steve,

This solves the problem that I was having trying to convert D-Painted hi-res 
graphics. I guess the problem crept in when I used the stencil making facilities
of D-Paint II. 

Dave

    I get an address violation error on line 712 when I try to convert
    a 600x1000 iff picture with 2 colors that I created in med-res mode
    with DPAINT II.  What is causing this? 600x1000, med-res, 2 colors??
    
    ... Rich

    I have been trying to print some lo-res iff files converted with CSIX
    on an LJ250 connected to a VAX in the office.  Everything works fine
    except that the images are only 4.5 inches by 3.5 inches.  The docs say
    that using -pLJ250 should correct this.
    
>              2.  320 x 200 pics will be doubled in size if -pLJ250 is
>                  specified.

    The use of pLJ250 does not make any difference to the images that I am
    printing.  If I leave the qualifier off then the images have slightly
    different colour rendering but just the same size.
    
    The images that I am wanting to print are :
    
    	(i)	Lo-res ham images from Vidi Amiga frame grabber.
    	(ii)	Lo-res Deluxe Paint II pictures.
    	(iii)	Lo-res iff export files from Deluxe Print.
    
    Has anyone else got this feature to work or is there a work around?
    
    Regards
    Peter

If the image isn't exactly 320x200 I don't think it will do the doubling.
I took a look at the code and I think if you reproduce the following diff
you should be able to force it to double with the switch -d...


<NAPIER> dif csix.c
************
File NAPIER$USER1:[MCAFEE.AMIGA]CSIX.C;2
   68                   case 'd':
   69                           hdup=vdup=2;
   70                           break;
   71                   default:
******
File NAPIER$USER1:[MCAFEE.AMIGA]CSIX.C;1
   68                   default:
************

Number of difference sections found: 1
Number of difference records found: 3

DIFFERENCES /IGNORE=()/MERGED=1-
    NAPIER$USER1:[MCAFEE.AMIGA]CSIX.C;2-
    NAPIER$USER1:[MCAFEE.AMIGA]CSIX.C;1


I've moved around a lot and misplaced some of the files so I didn't try
it myself, but if you add the three lines you see above that should do it.
hdup & vdup are just integer multipliers for each direction.  Doesn't do
any aliasing or anything just duplicates in each direction.

-steve

    re.24
    Peter,
    
    I use an asset called UTOX which can read in sixel and muck around with
    it's size. Notes conf closet::utox.
    
    Greg

    re .25
    
    I knew my ignorance of C would be an embarasment one day!
    
    I have made the update to the source ... now how do I compile and link
    it?
    
    Peter

I found csix_13b.arc on wjg:: so I made the change.  Turned out
one other very minor change was necessary in defs.h.   Since you
are already half way there...  Add a "d" to the string assigned
to OPTSTRING:


<NAPIER> diff defs.h
************
File NAPIER$USER1:[MCAFEE.AMIGA.CSIX]DEFS.H;2
   15   #define OPTSTRING "de:p:rl:t:"
   16   #define EMSG ""
******
File NAPIER$USER1:[MCAFEE.AMIGA.CSIX]DEFS.H;1
   15   #define OPTSTRING "e:p:rl:t:"
   16   #define EMSG ""
************

Number of difference sections found: 1
Number of difference records found: 1

DIFFERENCES /IGNORE=()/MERGED=1-
    NAPIER$USER1:[MCAFEE.AMIGA.CSIX]DEFS.H;2-
    NAPIER$USER1:[MCAFEE.AMIGA.CSIX]DEFS.H;1

If you want to do this and link yours it will be:

$ cc/nodebug/opt csix,ham,misc
$ link csix,ham,misc,sys$library:vaxcrtl.olb/lib

-steve

    Thanks Steve,
    
    That works just great.  I think that the problem was that the images
    were PAL and so had a height of 256 and not 240.
    
    Peter