Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
256-color-indexed(png|gif): missing transparency
#1
hey, i've already posted about this problem over on GIMPChat, although for the sake of inclusivity, i'm asking here too. Also, it looks like search functionality is busted atm, so I can't tell if this has been asked before and so i'm going ahead and posting my question...

The question is about how indexed color is represented at the data level in an exported image(png, gif), and what is the best way to export indexed images?: ¿num colors?, ¿remove unused colors from map? -- i guess those are the choices. 

Really, it all comes down to a problem i've had a few times now when trying to export an image(png or gif) as 256-colors indexed. the problem is it keeps adding a background color, and removing my transparency, and no matter how hard i try i have not been able to fix the problem while maintaining a full 256-color palette. here's an example:
   

if you look in image properties you will see it is labeled 256 colors, and there is still transparency in some layers, although it seems impossible to remove my background color in layer 1 or 5... above was actually my 2nd attempt to remove the background using GIMP_2.10
Here is my initial fail using GIMP_2.8:
   

...funny thing though, the problem disappears consistently when i choose fewer colors. see here(128 colors):
   

What is the cause of this problem? Also, why does gimp default to 255 colors? I've had it explained to me that it is because gimp represents transparent as a color too, and so i must decrement by one; but then why is there still transparency in some of the layers in my 256-color gif?

A full explanation would be much appreciated! I like to index a lot of my published work(for various reasons), but I also like to get the best quality, and sometimes that involves choosing 256. also this is not a consistent problem I have saved many pngs with transparency at 256-colors, and not had a problem, although it has not been an uncommon problem for me to encounter...

...could someone dispel the mystery? Thanks!
Reply
#2
The people who give technical answers here are essentially the same as the ones who give them on GC, so you'll get the same answers.

To make it short, in a GIF, there is a color designated as the transparent color, so if you want transparency, you are limited to 255 visible colors.

To quote Wikipedia:
Quote:GIF is palette-based: the colors used in an image (a frame) in the file have their RGB values defined in a palette table that can hold up to 256 entries, and the data for the image refer to the colors by their indices (0–255) in the palette table. The color definitions in the palette can be drawn from a color space of millions of shades (224 shades, 8 bits for each primary), but the maximum number of colors a frame can use is 256. This limitation seemed reasonable when GIF was developed because few people could afford the hardware to display more colors simultaneously. Simple graphics, line drawings, cartoons, and grey-scale photographs typically need fewer than 256 colors.

Each frame can designate one index as a "transparent background color": any pixel assigned this index takes on the color of the pixel in the same position from the background, which may have been determined by a previous frame of animation.
(emphasis mine).


This is what ImageMagick's identify command reports about your second image:

.zip   oscillating_i256tran-forum-crop.zip (Size: 25.39 KB / Downloads: 183) .
This is image doesn't come from Gimp since it seems to have different colormaps per frame.

The first frame has no transparent colors (the designated transparent color is black, but there is no black in the colormap). Most others frames have a transparent color that matches one in the color map.

You'll also notice that the frame with the most colors only has 253 colors, so you are likely wasting your time/effort.

GIF is limited, it dates back to 1989, well before JPEG, PNG, WEBP and MP4 were invented, and at a time where a display that could display 24M colors was the price of a small car, and enterprise networks ran at the blazing speed of 19600 baud.
Reply
#3
Thanks for the .dat file! ...also thanks for the link! ImageMagick seems cool, but i wish they would release a binary for older MacOS(SnowLeopard preferably), as I don't think i have the time right now to build it on own; and sadly I've also stopped using Homebrew since I realized it doesn't guarantee bug-free libs, and subsequently had to build SFML from scratch a few back(also my bug-fix was never accepted by the official branch, though they did merge a different fix of mine).

...and about the layers: if you want to know my process, I took 3 images from this site, and turned them into 8 frames; I did all my work in rgb then indexed to 256-colors, then optimized for .gif, and finally exported to gif. and you might be missing colors in the sample just because i had to crop it to get the filesize down(open gimp, crop, export .gif). ...also, not really to the point, but I wanted to have the globe rotating too, although i was having trouble with WorldWindEarth.

But your explanation has really been illuminating though, since i've been having the same problem with .png previously. I was scratching my head why it only did it some of the time, although now that i i realize that some of my pngs saved were kind of monochrome-ish, and it's also possible i had the "remove unused colors from colormap" box check-marked...

So I guess it's seems kind of obvious, but i hadn't realized transparent also needs a slot in the colormap, so i guess that's mystery solved!

...also, small note. I like pixel art. is .webp a safe format for pixel art? ...most serious pixel-art venues i know of seem to like .png and .gif...?
Reply
#4
What do you call "safe"?

People use PNG and GIF out of habit. It took years to PNG to displace GIF... WebP won't be popular overnight.
Reply
#5
I guess i'm just concerned about files getting degraded accidentally if you use the same extension for lossless and lossy. apparently this distinction is already being blurred on some major web platforms.

heres a thread: https://pixelation.org/index.php?topic=48665.0
Reply
#6
(08-21-2020, 12:08 AM)fingRsoL0 Wrote: I guess i'm just concerned about files getting degraded accidentally if you use the same extension for lossless and lossy. apparently this distinction is already being blurred on some major web platforms.

heres a thread: https://pixelation.org/index.php?topic=48665.0

Moot point. What is important is your source XCF. The rest, lossless or lossy, can be regenerated at will. And when it comes to animations, web platforms replace them with videos anyway these days.
Reply
#7
sure, if you have the original XCF... I was sort of concerned with the scenario where you don't have one though(e.g. web memes, or some other source). it's just frustrating when participants in a collaboration start degrading files on accident.

...and about animations and video, I've been trying to find out recently if there exists a file-format(and corresponding web community) that will allow me to make seamless visual+audio loops(and where i can host such things). ...I had the hardest time creating an mp4 that didn't clip my audio, but when i went to post it on imgur, i discovered it adds a 1/10 second pause each time the video loops... just to burst your bubble!
Reply


Forum Jump: