-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AnimGIF not transparent #5548
Comments
The first frame has a #3434 would fix this image, by setting the uncovered parts of the first frame to transparency. I just don't understand why this is the solution on a theoretical level, as the spec states that
rather than the transparency. |
@RLaursen since you're thinking a lot about GIFs at the moment, I'll ask you. See this 75px by 50px image. The first frame (well, the only frame) has an Image Descriptor with an Image Left Position of (25, 0) - in Pillow terms, those are the So the leftmost 25 pixels of the image are not covered. Since the spec states that the background color should be "used for those pixels on the screen that are not covered by an image", and the background color is #0f0 (0 index, meaning the first entry in the palette), I would think those pixels should be green. Instead, the browser renders those pixels as transparent. Any thoughts as to why this is? This is not a question about how Pillow behaves, rather a question about how GIFs behave. |
@radarhere That's certainly interesting, and I agree that the uncovered portion on the left should be the background color. Even if the background index was the same as the transparency index, which it isn't, I still think it should display the background color, purely based on the 89a specs. My guess is that viewers are generally set up to only use the background color when disposal method 2 is used, even though this seems like an incorrect interpretation of the format. Perhaps Pillow should mirror this behavior, if only to display GIFs consistently. |
I'm also trying to get Pillow working better with animated GIFs. Not much progress yet. @radarhere has already noticed some problems with the spec. E.g., when method 3 is used in the first frame, to dispose to previous, when there is no previous? Or what happens with disposal method 2 when there's no GCT, so no background color? Apparently the interpretation "in the wild" may follow historic conventions. A clue: http://giflib.sourceforge.net/whatsinagif/bits_and_bytes.html says of the background color index: "GIFLIB supports reading and setting this byte, but modern viewers and browsers generally have no use for it." (Also says of the size in the Logical Screen Descriptor: "The canvas width and height are usually ignored by modern viewers.") A page apparently authored when animated GIFs were a new thing: http://www6.uniovi.es/gifanim/gifabout.htm says this: "The Logical Screen Block also chooses one of the colors in the Global Color Table to be the Background color of the screen. This color selection is ignored by Netscape Navigator. If a GIF's background area shows through, Navigator displays the color set in the BGCOLOR of the page's body or, if none is specified, the background color set in the menus under OPTIONS/GENERAL PREFERENCES/COLORS. Now, of course, the question arises; how do I get it to be transparent? Well, this SHOULDN'T work, but it does. Apparently, if Netscape's decoder finds a Control block (it must be first, before any images) with Transparency turned on (any color) the background of the GIF will be transparent. This will allows background GIFs to fill in the logical screen background." It's not clear to me what Navigator did when no transparency was set, since it ignored the background color set in the LSD. But I'm guessing browsers may have always ignored it. That page also says "If your logical screen is larger than your image, you will have space around the image when displayed." But doesn't say what was in that space. Maybe just the page bgcolor or browser preference. That page also says "The logical screen area should be large enough to display all of your individual frames in it. If an image in the GIF file is larger than the logical screen or, by its positioning, extends beyond the screen, the portion that is off-screen will not be displayed." Which contradicts Pillow's decision to expand the size when a frame exceeds its boundaries. I opened 75x50 GIF in several programs. Irfanview indicated its size as 50x50, consistent with what giflib whatsinagif says. It does the same with @RLaursen's GIF above. I haven't found any more information about how programs actually interpret these features (background, transparency, image size, disposal methods.) I'll keep digging. |
Ok. I've given up and created #5557 to fix the image from the start of this issue. |
I've managed to find https://legacy.imagemagick.org/Usage/anim_basics/#dispose. In discussing why ImageMagick uses transparency for disposal method 2, it states (emphasis mine)
|
Loading some anim-GIFs result in opaque background.
Example to reproduce: PNG has a black border on the right inside (should be transparent):
The text was updated successfully, but these errors were encountered: