Hi all,
the following GIF (attached) does not load properly in SDL_image: It has
transparency in it which does not get detected properly (i.e.
SDL_SRCCOLORKEY isn’t set).
It was created with Photoshop 5.5 using exportGif89a option. It loads
fine (including the transparency) in Gimp. When I save it with gimp the
filesize grows by 2bytes and the image loads fine in SDL_image.
Bye now
Andreas
-------------- next part --------------
A non-text attachment was scrubbed…
Name: icon.gif
Type: image/gif
Size: 229 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011115/838443e2/attachment.gif
Andreas Schiffler wrote:
the following GIF (attached) does not load properly in SDL_image: It has
transparency in it which does not get detected properly (i.e.
SDL_SRCCOLORKEY isn’t set).
This patch seems to fix it. Sam, please apply
diff -u -r1.3 IMG_gif.c
— IMG_gif.c 2001/03/18 18:08:19 1.3
+++ IMG_gif.c 2001/11/15 15:34:57
@@ -253,7 +253,7 @@
} while (image == NULL);
#ifdef USED_BY_SDL
- if ( Gif89.transparent > 0 ) {
- if ( Gif89.transparent >= 0 ) {
SDL_SetColorKey(image, SDL_SRCCOLORKEY, Gif89.transparent);
}
#endif
Wouldn’t that make every GIF image transparent? Even though I don’t know
anything about the GIF image format, this looks to me like a broken
implementation in Photoshop.On Thu, Nov 15, 2001 at 04:36:23PM +0100, Mattias Engdegard wrote:
Andreas Schiffler wrote:
the following GIF (attached) does not load properly in SDL_image: It has
transparency in it which does not get detected properly (i.e.
SDL_SRCCOLORKEY isn’t set).
This patch seems to fix it. Sam, please apply
diff -u -r1.3 IMG_gif.c
— IMG_gif.c 2001/03/18 18:08:19 1.3
+++ IMG_gif.c 2001/11/15 15:34:57
@@ -253,7 +253,7 @@
} while (image == NULL);
#ifdef USED_BY_SDL
- if ( Gif89.transparent > 0 ) {
- if ( Gif89.transparent >= 0 ) {
SDL_SetColorKey(image, SDL_SRCCOLORKEY, Gif89.transparent);
}
#endif
Don’t know the GIF format spec, but I think it would be kind of strange
if index 0 wasn’t allowed for colorkey… (Every GIF saver would have to
reorder the palette and translate the pixels to get around that.)
And the code suggests that Gif89.transparent is signed, so it’s probably
a negative value - not 0 - that means “no transparency”.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 15 November 2001 18:05, Jakob Kosowski wrote:
On Thu, Nov 15, 2001 at 04:36:23PM +0100, =?ISO-8859-1?Q?Mattias Engdeg=E5rd?= wrote:
Andreas Schiffler wrote:
the following GIF (attached) does not load properly in SDL_image: It
has transparency in it which does not get detected properly (i.e.
SDL_SRCCOLORKEY isn’t set).
This patch seems to fix it. Sam, please apply
diff -u -r1.3 IMG_gif.c
— IMG_gif.c 2001/03/18 18:08:19 1.3
+++ IMG_gif.c 2001/11/15 15:34:57
@@ -253,7 +253,7 @@
} while (image == NULL);
#ifdef USED_BY_SDL
- if ( Gif89.transparent > 0 ) {
- if ( Gif89.transparent >= 0 ) {
SDL_SetColorKey(image, SDL_SRCCOLORKEY, Gif89.transparent);
}
#endif
Wouldn’t that make every GIF image transparent? Even though I don’t
know anything about the GIF image format, this looks to me like a
broken implementation in Photoshop.
[snip]
Wouldn’t that make every GIF image transparent? Even though I don’t
know anything about the GIF image format, this looks to me like a
broken implementation in Photoshop.
Don’t know the GIF format spec, but I think it would be kind of strange
if index 0 wasn’t allowed for colorkey… (Every GIF saver would have to
reorder the palette and translate the pixels to get around that.)
And the code suggests that Gif89.transparent is signed, so it’s probably
a negative value - not 0 - that means “no transparency”.
Probably you’re right. (I’ve started programming in C just a month ago)
But this is from the GIF89 spec: (http://www.msg.net/utility/whirlgif/gif89.html#sec23)
|Graphic Control Extension
[Now some lengthy talk about this optional block not included here for space reasons]
| Transparency Flag
| Indicates whether a transparency index is given in the Transparent Index
| field. (This field is the least significant bit of the byte.)
| Values:
| 0 - Transparent Index is not given. 1 - Transparent Index is given.
|
| Transparency Index
| The Transparency Index is such that when encountered, the corresponding
| pixel of the display device is not modified and processing goes on to the
| next pixel. The_index_is_present_if_and_only_if_the_Transparency_Flag_is
| set_to_1.(emphasis added)
Well. Either the GIF loading code has some magic I didn’t understand/see and sets
transparency index to something below zero when the transparency flag is false (then
Gif89.transparent would have to be the transparency index), or Gif89.transparent is the
transparency flag.
-JakobOn Thu, Nov 15, 2001 at 06:28:05PM +0100, David Olofson wrote:
On Thursday 15 November 2001 18:05, Jakob Kosowski wrote:
Thanks for the fix …
Well. Either the GIF loading code has some magic I didn’t understand/see and sets
transparency index to something below zero when the transparency flag is false (then
Gif89.transparent would have to be the transparency index), or Gif89.transparent is the
transparency flag.
No magic.
You have a flag and a index stored in the GIF. The SDL_image code sets
its internal index/flag variable to -1 before processing. If the
transparency flag comes up as beeing set in the GIF header, the internal
variable assumes the value if the index from the header.
Therefore if <0, no transparency. If >-1 its the index. The 0th index
was just forgotten (the bug).
Ciao
Andreas
Oh well, I see. Sorry for adding noise to the list and thank you for
the nice explanation.
-JakobOn Thu, Nov 15, 2001 at 01:52:55PM -0500, Andreas Schiffler wrote:
No magic.
You have a flag and a index stored in the GIF. The SDL_image code sets
its internal index/flag variable to -1 before processing. If the
transparency flag comes up as beeing set in the GIF header, the internal
variable assumes the value if the index from the header.
Therefore if <0, no transparency. If >-1 its the index. The 0th index
was just forgotten (the bug).
