Newsgroups: comp.sys.atari.st
Path: utzoo!utgpu!watserv1!watmath!lsuc!jimomura
From: jimomura@lsuc.on.ca (Jim Omura)
Subject: Re: GemView (new version and some questions)
Organization: Consultant, Toronto
Date: Wed, 22 May 1991 19:35:54 GMT
Message-ID: <1991May22.193554.26435@lsuc.on.ca>
References: <3272@laura.UUCP>

In article <3272@laura.UUCP> haacke@exunido.UUCP (Ralf Haacke) writes:
>
>Dieter have no permission to post articles to the News, so here is his message:
>
>================================================================================
>
>Hi folks,
>
>sorry but the program/accessory posted in comp.binaries.atari.st have a few
>bugs or "unknown features".

...


>- The main-(log)-window have a FULLER-button, which makes a very small and
>  smart window.

     This sounds interesting.

...

>What to do in the future:
>
>- GemView could be faster (and smaller).
>- A Big-GemView, which saves pictures in other formats (???)
>- Transfer GEM-Metafiles into pixel-maps (and reverse ???)
>- Saving installs.
>- Continue work, if GemView runs as ACC and changing the main-application.
>  Therefor some questions: Should GemView automaticly opens its own windows,
>  if it found out that the runing main program is a gem-program (appl_init)?
>  Or should GemView wait for a handling with windows (wind_create/open)?
>  Should it ask the user for CANCEL the action, WAIT for new activition or
>  changing program or CONTINUE it's work and open the windows?
>  (!!! THIS WILL NOT IMPLEMENT IN THE NEXT SOME WEEK/MONTH !!!)
>- A new color reduce algorithm. I have the followed idea:
>  A color is a point in a 3-dim-room (N^3). First calculate the distance
>  from each point to each other and save the nearest point with the distance.
>  Next searching the nearest neighbours and make this two point to one. The
>  new points is nearer to a  point which represent more points then the
>  other. From the new point calculate the distance to all other points and
>  save the nearest (some other points must update, if the new point is nearer
>  as the nearest neighbour before). Then begin to search the nearest ....,
>  until we have reduce enough.

     I felt that you did a really good job on the colour reduction
algorythm.  The colour selection seems better than on a couple of
other programs I've been using ("VDI_GIF" and another one I can't
remember offhand).  I've been kicking around ideas for colour
reduction codes for a while now and I haven't gotten around to
writing one yet, but it seemed to me that it might be easier to
work in a 2D framework based on Hue and Intensity, which is the
way a television signal works.  But to do this you have to start
by converting the palette from RGB's for most picture format, then
do the calculations, and then re-convert to the target palette
style (Atari in this case).

     Working from Hue and Intensity, I think you could give preference
to one or the other for your colour assignments, as an option for
the user.  That is to say you could allow the user to chose whether
colour assignments are weighted to give the maximum detail in terms
of the hues (which could result in a pastel, low contrast image with
a lot of detail in terms of colours) or maximum detail in terms of
contrast (which might result in a picture with fewer colours, but
more shading).

     Again, I'll emphasize that I haven't gotten around to writing
this code yet so I don't know if it's going to work out the way
I'm expecting it to.



-- 
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
lsuc!jimomura
Byte Information eXchange: jimomura
