GIF IMPORT problem (Resolved - AGS bug)

[SpacePaw]

EDIT: cleared the post. More actual info below

When I import pallette based png or gif the sprite doesn't look right.

Orginal:


Sprite after importing to AGS (either gif or png file imported) with no transparency:


see the black stripe almost at the bottom?

Sprite after importing to AGS(either gif or png file imported) with leave-as-is transparency


the black stripe is now acompanied by the pinkish ags-transparent one..

It doesnt seem to be a color depth problem as all colors besides the stripe don't change Sorry - turned out that colors change so there's some color compression... Does it matter if I use optimized octree or median cut while lowering the color depth?

the problem occurs only when file is saved in 8bit color depth. Apart from displaying in AGS file seems ok (and even get's uploaded right when I use my plugin instead of AGS import).

It doesn't matter what color depth I choose.

[Pumaman]

I can't reproduce any problems with sprite exporting. Can you upload some sort of example of this?

Is it only GIF exports that you have this problem with, or does it happen if you export the sprite in any format?

[SpacePaw]

Okay, here's something even more strange!
I don't want it to sound like self advertisement but I tried uploading SAME FILE with my plugin (Gif to View Importer) and THEN export it. Guess what...It's allright now. So...What the hell?? I'm really confused about this one...

It seems that when AGS adds sprite from file from the editor level it does that differently than when you do that in code (using the provided function). Shouldn't it be the same function?..I feel so lost T.T

[Pumaman]

What colour depth is your game? If it's 16-bit then the sprite will get downscaled from 32-bit on import, which is why the gradient becomes blocky on the PNG.

As for exporting the GIF, it's probably just that the GIF exporting library isn't clever enough to work out the optimal 256-colour palette to downscale the image back to. AGS uses the standard Windows routines for exporting GIFs so they're probably not optimal.

[SpacePaw]

It doesnt really depend on game color depth. Tried all of them. Try importing file with no transparency or leave-as-is yourself. Editor screws something up 0.o. As for the gif - you're probably right, that's a library thing. But the problem isn't exporting anymore it's importing Cuz the sprite change occurs while import not export.

[Gilbert]

I'm not quite sure, but when the GIF format was created, base palettes for graphic modes were usually not up to 24 bit (for example, the 256 colours in MCGA mode were choosen from a 18-bit base palette, not a 24-bit one, i.e. 6-bit, or 64 colours, for each channel). So, graphic libraries/programmes in those days couldn't really manage 24-bit, for example, the infamous DP2E for PC could only manage the 18-bit MCGA palette (it seemed that you can set the intensity of each channel using a 0-100 scale, but it's actually hashed to the hardware 0-63).

Even today, when working with indiced colours (256 colours or less), many programmes/libraries/routines would not support the true 24-bit base palette, so it's quite possible when you export an image to a 256-colour GIF using a certain routine, the image would be downgraded to use a lower colour base palette (even though the original may not contain more than 256 colours, for example in your original.gif there is a smooth gradient, when you compare say colours #0 and #1 they differ VERY little in their RGB values in the 24-bit scale, these colours would probably not be able to be reproduced in a lower base palette as two distinct colours, which as a result the image would be either dithered or converted into flat colours without dithering giving that "banded" effect).

[SpacePaw]

I'm not quite sure, but when the GIF format was created, base palettes for graphic modes were usually not up to 24 bit (for example, the 256 colours in MCGA mode were choosen from a 18-bit base palette, not a 24-bit one, i.e. 6-bit, or 64 colours, for each channel). So, graphic libraries/programmes in those days couldn't really manage 24-bit, for example, the infamous DP2E for PC could only manage the 18-bit MCGA palette (it seemed that you can set the intensity of each channel using a 0-100 scale, but it's actually hashed to the hardware 0-63).

Even today, when working with indiced colours (256 colours or less), many programmes/libraries/routines would not support the true 24-bit base palette, so it's quite possible when you export an image to a 256-colour GIF using a certain routine, the image would be downgraded to use a lower colour base palette (even though the original may not contain more than 256 colours, for example in your original.gif there is a smooth gradient, when you compare say colours #0 and #1 they differ VERY little in their RGB values in the 24-bit scale, these colours would probably not be able to be reproduced in a lower base palette as two distinct colours, which as a result the image would be either dithered or converted into flat colours without dithering giving that "banded" effect).

Thank you for the info on gif format. I looked into it too lately. The problem is different however. you should read lower posts long-story short when I import this file (even when it's saved as png) no matter what depth is set it shows it with this damned black stripe on the bottom...the orginal image doesnt have it and when I use my plugin everything is ok...I still didn't find any possible solution :/

EDIT: besides. Look how the png looks. It HAS all the colors of the orginal besides that stupid stripe so I don't think it's a color depth problem oops my bad, it DOES seem compressed indeed. Might be a color depth problem...Does it matter if I use optimized octree or median cut while lowering the color depth?

[Pumaman]

Please don't edit your older posts and change the problem in them, it makes the thread very hard to follow.

Anyway, you have two separate issues with importing this graphic:

1. The gradient has lost its smoothness. This is because when importing a 256-colour image, AGS switches into 256-colour mode, which has a maximum palette of 15-bit colour. Therefore, if you have a 256-colour image with a very specific palette it effectively gets reduced to the 15-bit colour palette while being imported, because that is the best definition available in 8-bit games.

2. The black/pink lines at the bottom. The black line is a bug in AGS which I'll get fixed, the pink line is because you chose "Leave As-is Transparency" and the bottom row is Palette Slot 0 which is the transparent colour.  Use "No transparency" as the import option if you don't want this.

[SpacePaw]

Please don't edit your older posts and change the problem in them, it makes the thread very hard to follow.

Sorry - I just didn't want to start a new thread. Thought it would be against the rules and stuff...

2. The black/pink lines at the bottom. The black line is a bug in AGS which I'll get fixed, the pink line is because you chose "Leave As-is Transparency" and the bottom row is Palette Slot 0 which is the transparent colour.  Use "No transparency" as the import option if you don't want this.

Thank you I'm glad I could find a bug, some kind of contribution

[Gilbert]

Sorry - I just didn't want to start a new thread. Thought it would be against the rules and stuff...

You don't need to start a new thread. If the problem is related just start a new post.

[SpacePaw]

Ok I will I just tried too hard