You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is apparent from various reported issues that Pillow has a problem with the palettes on subsequent GIF frames. To use one of Pillow's own test images to demonstrate -
Each GIF frame can have its own palette, and Pillow is reading that in as the palette that of that new frame. However, when the new frame is at least partially pasted on top of the existing image, the palette should not be applied to the pixels already loaded. So the image has turned red here because the blue in the previous palette is red in the new palette.
I put together a change to combine each of the palettes as they were loaded, but discovered that this doesn't work as well as it could because of the limitation of 256 colours in a palette.
Another option is to convert each of the image parts from P to RGB for merging and then back again, but the image then becomes an approximation of an image where users aren't able to know for certain what colour a pixel was in the file.
The most straightforward solution to this is to change GIF P images to RGB and leave them that way, removing the limitation of 256 colours. However, considering Pillow's strong encouragement of backwards compatibility, this is might be considered a bit of a problem.
So, any thoughts?
The text was updated successfully, but these errors were encountered:
The value of 'pixel' also defines the maximum number of colors within an image. The range of values for 'pixel' is 0 to 7 which represents 1 to 8 bits. This translates to a range of 2 (B & W) to 256 colors.
It is apparent from various reported issues that Pillow has a problem with the palettes on subsequent GIF frames. To use one of Pillow's own test images to demonstrate -
Each GIF frame can have its own palette, and Pillow is reading that in as the palette that of that new frame. However, when the new frame is at least partially pasted on top of the existing image, the palette should not be applied to the pixels already loaded. So the image has turned red here because the blue in the previous palette is red in the new palette.
I put together a change to combine each of the palettes as they were loaded, but discovered that this doesn't work as well as it could because of the limitation of 256 colours in a palette.
Another option is to convert each of the image parts from P to RGB for merging and then back again, but the image then becomes an approximation of an image where users aren't able to know for certain what colour a pixel was in the file.
The most straightforward solution to this is to change GIF P images to RGB and leave them that way, removing the limitation of 256 colours. However, considering Pillow's strong encouragement of backwards compatibility, this is might be considered a bit of a problem.
So, any thoughts?
The text was updated successfully, but these errors were encountered: