Gif opening causes color reindexing when duplicate colors in color table #3426
Comments
|
I understand things are more complicated when the gif has local color tables, and that Aseprite may from time to time be forced to convert everything to true color, but this issue is regarding a simpler case where the gif is almost just a list of indexed BMPs. |
|
Thanks @domgetter for this report. I was able to reproduce it. |
Gasparoken
added a commit
that referenced
this issue
Jul 28, 2022
Gasparoken
added a commit
that referenced
this issue
Aug 2, 2022
Gasparoken
added a commit
that referenced
this issue
Aug 10, 2022
…r table (fix #3426) If the RGB color at index 'i' of the local gif palette and the sprite palette match, there is no need to call findMatchColor(). This prevents indexes from being reassigned undesirably. Also, in the special case that a global palette exists and as long as no local palette appears during frame iteration, it is not necessary to call findMatchColor() since the global palette is equal to the sprite's palette (in colors and order).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When Aseprite opens a gif which has a single global color table, it will re-index pixels in some of the frames when they share RGB values with other indices in the color table.
In this gif, the palette is 256 copies of black, but the 2 frames are indexed to color 240 in the table. When Aseprite opens it, frame 1 is all indexed as 240, but in frame 2, all the pixels are re-indexed to 1 since it's also black.
Expected/preferred behavior: When Aseprite opens a gif with only a global color table, the colors are copied from the color table to the current palette, and the indices across all the frames are left alone and copied in as-is.
Aseprite and System version
The text was updated successfully, but these errors were encountered: