phil@ux1.cso.uiuc.edu (06/17/89)
I created a GIF output file using the program FRACTINT. I then displayed that file using different GIF viewers, VGIF, VUGIF, SHWGIF, and FASTGIF. All showed DIFFERENT colors. I thought the color pallette was a part of the GIF format. Can someone explain why different programs show the same GIF file in different colors? Is something defective in the file? --Phil howard-- <phil@ux1.cso.uiuc.edu>
vgopal@cbnewsc.ATT.COM (venu.p.gopal) (06/20/89)
In article <5300015@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes: >I created a GIF output file using the program FRACTINT. I then displayed >that file using different GIF viewers, VGIF, VUGIF, SHWGIF, and FASTGIF. >All showed DIFFERENT colors. I thought the color pallette was a part of >the GIF format. Can someone explain why different programs show the same >GIF file in different colors? Is something defective in the file? True color representation depends on the graphics display card you are using. GIF allows 256 colors, each one of which can be one of 16.7 million possible colors. If you are using a CGA, you are limited to 4 colors that are pre-fixed. How can you possibly do even a reasonable job on a CGA ? If you are using an EGA, you have 16 colors that can be selected from a possible set of 64 colors. Better, but far from what is needed for reasonable color representation. VGA and SuperVGA 256 colors modes are much better. Though you do not get the full color resolution that GIF is capable of, you can still select 256 colors out of 262 thousand colors. You will find that when you use these modes, the differences between the display programs disappear. The differences mainly exist because the GIF colors specifications have to be approximated by what the display card can show and different programs have different methods. Venu P. Gopal UUCP: att!ihuxy!vgopal Internet: vgopal@ihuxy.att.com BITNET: com%"vgopal@ihuxy.att.com" or com%"vgopal%ihuxy@research.att.com" Silence those silent letters and save the world 500 million keystrokes a day.
peter@ficc.uu.net (Peter da Silva) (06/20/89)
GIF is restricted to 256 unique colors? How is one to convert Amiga HAM images (with up to 4096 unique colors) to GIF? Some will work, but others won't. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
pt@beta.lanl.gov (Paul A. Thiessen) (06/20/89)
In article <1305@cbnewsc.ATT.COM> vgopal@cbnewsc.ATT.COM (venu.p.gopal) writes: >disappear. The differences mainly exist because the GIF colors >specifications have to be approximated by what the display card can >show and different programs have different methods. > >Venu P. Gopal >UUCP: att!ihuxy!vgopal >Internet: vgopal@ihuxy.att.com >BITNET: com%"vgopal@ihuxy.att.com" or com%"vgopal%ihuxy@research.att.com" >Silence those silent letters and save the world 500 million keystrokes a day. More specifially, GIF can handle 8 bits of color resolution, meaning every color can have red, green, and blue values from 0 to 255. But VGA is only 6 bits, meaning RGB values from 0..63. So to display on VGA, the GIF program has to scale the 8 bits down to 6 bits which can cause color distortion and differences in colors depending on exactly how the program "crunches" 256 values into 64. - Paul -- ------------------------------------------------------------ PAUL THIESSEN (Summer only: pt@lanl.gov) pthiessen@hmcvax.bitnet ...uunet!jarthur!pthiesse ------------------------------------------------------------
foss@iris.ucdavis.edu (Jim Alves-Foss) (06/21/89)
In article <1305@cbnewsc.ATT.COM> vgopal@cbnewsc.ATT.COM (venu.p.gopal) writes: >In article <5300015@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes: > >>... Can someone explain why different programs show the same >>GIF file in different colors? Is something defective in the file? > ... >select 256 colors out of 262 thousand colors. You will find that when >you use these modes, the differences between the display programs ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >disappear. The differences mainly exist because the GIF colors ^^^^^^^^^ >specifications have to be approximated by what the display card can >show and different programs have different methods. Different display programs also have different default modes. FASTGIF displays GIF files in EGA modes but does a good approximation of better modes using a dithering technique, VGIF uses the VGA modes and I'm unsure about the others. Check the documentation that comes with these programs to see what modes they support and then use the one best suited for YOUR particular hardware configuration (ie FASTGIF for EGA, VGIF for VGA, ...) -Jim Alves-Foss (foss@iris.ucdavis.edu) /* of course these are MY opinions */
phil@ux1.cso.uiuc.edu (06/21/89)
> True color representation depends on the graphics display card you are > using. GIF allows 256 colors, each one of which can be one of 16.7 million > possible colors. If you are using a CGA, you are limited to 4 colors that > are pre-fixed. How can you possibly do even a reasonable job on a CGA ? I would not be able to, but at that point I'd expect to see that same set of 4 colors (or less) from all viewers that work, although not necessarily assigned to the same original color. > If you are using an EGA, you have 16 colors that can be selected from > a possible set of 64 colors. Better, but far from what is needed for > reasonable color representation. > VGA and SuperVGA 256 colors modes are much better. Though you do not > get the full color resolution that GIF is capable of, you can still > select 256 colors out of 262 thousand colors. You will find that when > you use these modes, the differences between the display programs > disappear. The differences mainly exist because the GIF colors > specifications have to be approximated by what the display card can > show and different programs have different methods. I have standard IBM VGA in a PS/2-30/286. > More specifially, GIF can handle 8 bits of color resolution, meaning > every color can have red, green, and blue values from 0 to 255. But VGA > is only 6 bits, meaning RGB values from 0..63. So to display on VGA, > the GIF program has to scale the 8 bits down to 6 bits which can cause > color distortion and differences in colors depending on exactly how the > program "crunches" 256 values into 64. So, I'd expect the colors to be truncated this way, and therefore still have the same colors displayed on my 256-of-262144 display from a file having 256-of-16777216 colors. The colors are instead DRAMATICALLY different. One viewer shows one area as several over saturated hues of the rainbow and another viewer shows the same thing as a SINGLE ugly green hue. > Different display programs also have different default modes. FASTGIF > displays GIF files in EGA modes but does a good approximation of better modes > using a dithering technique, VGIF uses the VGA modes and I'm unsure > about the others. Check the documentation that comes with these programs to > see what modes they support and then use the one best suited for YOUR > particular hardware configuration (ie FASTGIF for EGA, VGIF for VGA, ...) This indeed seems like what must be happening. Although ALL viewers are squishing the images (360x480) into the left side, some were truncating it on the bottom, indicating the likelyhood of being in the EGA (640x350) mode. The FRACTINT program has a tweaked VGA mode of 360x480x256 with non-square pixels. It works by loading the registers directly instead of calling BIOS to set a graphics mode (limited choices apparently). Documentation says this works only on IBM VGA *REGISTER COMPATIBLES*. I'd like to see a viewer that can use this mode. FRACTINT source is available, so why not. So far, I have NO SOURCE to any viewers, so I can't get in and FIX THEM. --Phil howard-- <phil@ux1.cso.uiuc.edu>
zu@ethz.UUCP (Urs Zurbuchen) (06/22/89)
In article <5300015@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes: > >I created a GIF output file using the program FRACTINT. I then displayed >that file using different GIF viewers, VGIF, VUGIF, SHWGIF, and FASTGIF. >All showed DIFFERENT colors. I experienced a similar problem here with a .gif file showing a girl's head as a photograph in the upper left corner and a logo 'grafx' at the lower right. Using Vgif the picture displayed correctly, but with Fastgif it was hardly recognizable. None of the 10 other .gif files I have on my harddisk showed a similar amount of deviation. Any ideas? ...urs UUCP (dumb): {backbone}!mcvax!cernvax!ethz!zu (smart): zu@norad.UUCP or netto@norad.UUCP or zu@ethz.UUCP Fido: 2:302/801.36
pokey@well.UUCP (Jef Poskanzer) (06/22/89)
In the referenced message, peter@ficc.uu.net (Peter da Silva) wrote: }GIF is restricted to 256 unique colors? How is one to convert Amiga HAM }images (with up to 4096 unique colors) to GIF? Some will work, but others }won't. To say nothing of converting professional-quality 24 bit deep images to a 256-element colormap. This is known as the color quantization problem. If you read comp.graphics for a while, you will be sure to see solutions posted. --- Jef Jef Poskanzer pokey@well.sf.ca.us {ucbvax, apple, hplabs}!well!pokey "What we've got here is a failure to communicate."
phil@ux1.cso.uiuc.edu (06/22/89)
> GIF is restricted to 256 unique colors? How is one to convert Amiga HAM > images (with up to 4096 unique colors) to GIF? Some will work, but others > won't. TIFF allows true RGB colors, and that result in 16777216 colors or more. Conversion to GIF obviously must distort the colors some. Better programs will be able to better estimate a good GIF pallette to use from the frequency of usage of the whole color range. This is also one of the drawbacks of GIF. TIFF does not allow pallettes in the current version I have docs for, but this is less of a drawback since a GIF file can be converted to a TIFF by just mapping the pallette into each pixel. --Phil howard-- <phil@ux1.cso.uiuc.edu>
vgopal@cbnewsc.ATT.COM (venu.p.gopal) (06/23/89)
In article <4623@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >GIF is restricted to 256 unique colors? How is one to convert Amiga HAM >images (with up to 4096 unique colors) to GIF? Some will work, but others >won't. Yes, the current GIF standard is restricted to 256 colors only; however, each of the 256 colors can be one of 16.7 million colors. If you are converting from a 4096 color image, obviously you will lose something. The 4096 colors, depending on their red, blue and green content, will have to be mapped to 256 colors that should be selected from the 16.7 million. There was some discussion on color mapping algorithms in this newsgroup sometime earlier. The 256 color restriction is obviously based on the 8-bit byte so that a color can be represented by a byte. You can actually do a lot with 256 colors, I have seen a lot of very impressive images. Venu P. Gopal UUCP: att!ihuxy!vgopal Internet: vgopal@ihuxy.att.com BITNET: com%"vgopal@ihuxy.att.com" or com%"vgopal%ihuxy@research.att.com" Silence those silent letters and save the world 500 million keystrokes a day.
hst@mh_co2.mh.nl (Klaas Hemstra) (06/23/89)
I would like to get to the bottom of this, because I also have had some
strange colours.
I think the problem of the GIF viewers is when the size of the image is larger
than 320 x 200 AND there are more than 16 colours.
Some GIF viewers automatically choose EGA or VGA modes with 16 colours to
display these images. This will result in scaling down the number of colours
from x (mostly 256) to 16, which cannot be done very well. Most likely this
feature causes the inconsistent display of images.
Some of the GIF viewers give you the possibility to manually select the
displaymode, with that You might be able to check whether it is correct for
your pictures and monitors.
Anybody who thinks this is not correct ?
Please mail me with more information about your particular system.
When there are other reasons I will post them.
Klaas
Klaas Hemstra (hst@mh.nl) | / / ,~~~ ~~/~~
uucp: ..{uunet!}hp4nl!mh.nl!hst | /--/ `-, / ___ |_/ |__|
Multihouse N.V., Gouda, the Netherlands | / / ___/ / --- | \ | |
"Most of us mindreaders are atheist, you know" A song for Lya: George Martinpeter@ficc.uu.net (Peter da Silva) (06/23/89)
In article <12315@well.UUCP>, pokey@well.UUCP (Jef Poskanzer) writes: > In the referenced message, peter@ficc.uu.net (Peter da Silva) wrote: > }GIF is restricted to 256 unique colors? How is one to convert Amiga HAM > }images (with up to 4096 unique colors) to GIF? Some will work, but others > }won't. > To say nothing of converting professional-quality 24 bit deep images to > a 256-element colormap. This is known as the color quantization problem. > If you read comp.graphics for a while, you will be sure to see solutions > posted. So, basically, GIF is an inadequate format. Too bad it's so popular. So, what does that leave? IFF/ILBM should do a better job, but it's not popular outside the Amiga. What about this 'TIFF' format? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
pt@beta.lanl.gov (Paul A. Thiessen) (06/23/89)
In article <4623@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >GIF is restricted to 256 unique colors? How is one to convert Amiga HAM >images (with up to 4096 unique colors) to GIF? Some will work, but others >won't. Just a note: GIF can only have 256 colors *on screen*, from a choice of about 16 million (256**3). I don't know if that's what you meant, but it is true that a choice of only 256 colors would be lame... - Paul -- ------------------------------------------------------------ PAUL THIESSEN (Summer only: pt@lanl.gov) pthiessen@hmcvax.bitnet ...uunet!jarthur!pthiesse ------------------------------------------------------------
vgopal@cbnewsc.ATT.COM (venu.p.gopal) (06/24/89)
In article <5300017@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu writes:
..
..So, I'd expect the colors to be truncated this way, and therefore still have
..the same colors displayed on my 256-of-262144 display from a file having
..256-of-16777216 colors. The colors are instead DRAMATICALLY different.
..One viewer shows one area as several over saturated hues of the rainbow
..and another viewer shows the same thing as a SINGLE ugly green hue.
..> Different display programs also have different default modes. FASTGIF
..> displays GIF files in EGA modes but does a good approximation of better modes
..> using a dithering technique, VGIF uses the VGA modes and I'm unsure
..> about the others. Check the documentation that comes with these programs to
..> see what modes they support and then use the one best suited for YOUR
..> particular hardware configuration (ie FASTGIF for EGA, VGIF for VGA, ...)
..
..This indeed seems like what must be happening. Although ALL viewers are
..squishing the images (360x480) into the left side, some were truncating it
..on the bottom, indicating the likelyhood of being in the EGA (640x350) mode.
..
..The FRACTINT program has a tweaked VGA mode of 360x480x256 with non-square
..pixels. It works by loading the registers directly instead of calling BIOS
..to set a graphics mode (limited choices apparently). Documentation says this
..works only on IBM VGA *REGISTER COMPATIBLES*. I'd like to see a viewer that
..can use this mode. FRACTINT source is available, so why not. So far, I have
..NO SOURCE to any viewers, so I can't get in and FIX THEM.
..
..--Phil howard-- <phil@ux1.cso.uiuc.edu>
You may want to try VUGIF, posted to c.b.i.p. a short while ago, and
probably available from clarkson, simtel etc. by ftp.
You can select the video mode yourself from the umpteen choices on
the menu and see for yourself what is happening.
It will also scale the picture (if you want) to fit the screen so that
your image size and color quantization effects can be independently seen.
Venu P. Gopal
UUCP: att!ihuxy!vgopal
Internet: vgopal@ihuxy.att.com
BITNET: com%"vgopal@ihuxy.att.com" or com%"vgopal%ihuxy@research.att.com"
Silence those silent letters and save the world 500 million keystrokes a day.phil@ux1.cso.uiuc.edu (06/24/89)
> To say nothing of converting professional-quality 24 bit deep images to > a 256-element colormap. This is known as the color quantization problem. > If you read comp.graphics for a while, you will be sure to see solutions > posted. I hope some of those solutions show up as public domain source code to display TIFF files on 256 color displays (PC VGA, Mac II, or even Amiga) or TIFF to GIF conversion. --Phil howard-- <phil@ux1.cso.uiuc.edu>
peter@ficc.uu.net (Peter da Silva) (06/25/89)
In article <26915@beta.lanl.gov>, pt@beta.lanl.gov (Paul A. Thiessen) writes: > Just a note: GIF can only have 256 colors *on screen*, from a choice of > about 16 million (256**3). I don't know if that's what you meant, It's what I meant. I routinely use images with up to 4096 unique colors on screen at one time. This is on a $1000 micro. Apparently GIF can't support that. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
phil@ux1.cso.uiuc.edu (06/28/89)
> So, basically, GIF is an inadequate format. Too bad it's so popular. > > So, what does that leave? IFF/ILBM should do a better job, but it's not > popular outside the Amiga. Even as an Amiga owner, I find the IFF documentation to be much harder to read that either GIF or TIFF format documentation. > What about this 'TIFF' format? It currently LACKS the ability to specify a palette. One could, of course convert palette images to plain RGB very easily when converting to the TIFF format. The reverse conversion, however is trickier because it would require the program to verify that not more than the pallatte maximum of different colors is used. Also, if there is any importance to the particular order of the colors in the palette, that is lost, too. I've heard that a future enhancement to TIFF is supposed to include the ability to specify a palette. TIFF does include the possibility of user-agreed and user-defined fields of information that could be used to define a pallatte, as well as any other information desired. Its easy for a program to skip over any data field that it does not understand since everything is addressed relative to the beginning of the file. So the user-defined fields can be ignored by programs that don't know them. I want to encode the coordinates of Mandelbrot images as part of image files, so I could use one of those fields for that. --Phil howard-- <phil@ux1.cso.uiuc.edu>
peter@ficc.uu.net (Peter da Silva) (06/29/89)
I said: > So, basically, GIF is an inadequate format. Too bad it's so popular. > So, what does that leave? IFF/ILBM should do a better job, but it's not > popular outside the Amiga. In article <5300023@ux1.cso.uiuc.edu>, phil@ux1.cso.uiuc.edu writes: > Even as an Amiga owner, I find the IFF documentation to be much harder to > read that either GIF or TIFF format documentation. Maybe so, but remember that IFF (1) covers more ground, and (2) is extensible and customisable. I can store sound samples in an IFF file, or I can add custom chunks that will be ignored by others. And I've done both. You mention that TIFF allows custom information, too. If it doesn't let you specify a palette, does that mean a TIFF file always includes a full set of RGB bitplanes (12 or 24 bitplanes)? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.