[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
19990315: SVGIF problem
- Subject: 19990315: SVGIF problem
- Date: Mon, 15 Mar 1999 11:53:01 -0700
>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