[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19990315: SVGIF problem

>From: Anthony James Wimmers <address@hidden>
>Organization: UVa
>Keywords: 199903151804.LAA13281 SVGIF

Tony,

>We're having a problem that has always been around, but with Paul Menzel's
>visit coming up, we have some incentive to fix it now. When using SVGIF on
>windfall (a 24-bit color display) not all the colors in the gif are as they
>were in the McIDAS window.

Just for information, GIF images are 8-bit, so your comment about
having a 24-bit color display should not come into play.

>In the gif file, the lack of colors makes the
>image appear blockier with less detail. (See 
>windfall.evsc.virginia.edu/~mcuser/webpage/nat67.gif )

I looked at this image and do not see the blockiness that you are referring
to.  Perhaps this example is not the one you meant to reference?

>I notice that this problem does not happen 100% of the time, (See
>http://windfall.evsc.Virginia.EDU/~ajw7g/1.gif ) and I have no idea why that
>is.

I looked at this image as well, but I don't see much, if any, difference
from the first.  What feature are you pointing out?

>Can you venture a guess as to what is causing this,

Since I am not seeing the problem that you are referring to, I can't make
any concrete comments, but I do speculate on what may be happening below.

>and if it can be fixed?

Well, since we are dealing with software, anything can be fixed :-).  I
can tell you, however, that IF there is a problem, it won't be worked
on (by me) in the near future.

>BTW, is there a name for this problem?

Again, I am not seeing what you are referring to, but I would call it a
sampling problem.  Is it possible that you are looking at the images
using a browser that is reducing the number of colors in the GIF (I
doubt that this is the case, by the way)?

Speculation:  I am betting that you are creating the image(s) with some
sort of a ROUTE PP BATCH invocation (true?), and comparing it(them) do
displays in a McIDAS session.  If so, the environment being created by
'mcenv' in the PP BATCH invocation most likely has less color levels
available for the display.  The 7.40 version of 'mcenv' allows you to
specify how many image colors can be used for a frame:

mcenv -- execute in a McIDAS environment
  mcenv [-f <framespec>]... [-e <bytes>] [prog arg...]
Remarks:
  Command line arguments:
     -f <framespec>  specifies a set of frames to include in the
                     McIDAS environment

                     A <framespec> of the form N@LxE in which N, L,
                     and E represent integers, and x is the small
                     letter x, means to allocate N frames of L lines
                     by E elements.

                     A <framespec> of the form LxE means to allocate
                     1 frame of L lines by E elements.

                     A <framespec> of the form N means to allocate N
                     frames of 480 lines by 640 elements.

                     Multiple -f options can be given in order to
                     specify frames of different sizes.

                     If there are no -f options, the default
                     environment is as if ``-f 1@480x640'' were
                     given.

     -e <bytes>      specifies how large to make the MAKFRM free
                     space pool in the McIDAS environment

                     The <bytes> number can be suffixed with a k or
                     an m, for kilobytes or megabytes.

                     If there is no -e option, the default
                     environment is as if ``-e 0'' were given.

     -g <number>     specifies number of graphics color levels
                     (McIDAS-X only)

     -i <number>     specifies number of image color levels
                     (McIDAS-X only)

     prog arg...     program to run in the McIDAS environment

                     If no program is specified, the default
                     program to run is $SHELL.

  The mcenv command creates an environment (shared memory block) and
  then forks and execs the given program.  When the program exits,
  mcenv removes the shared memory object and exits.

  mcenv processes can nest; commands run under an inner mcenv can
  not see or affect the environment created by the outer mcenv.
----------

You should try adding the '-i 128' flag/value to your 'mcenv' invocation
in the Bourne shell script batch.k that is being used for the PP BATCH
invocation (if that is how these are being created).

Please let me know if this was the problem.

Tom