This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>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