GNOME Bugzilla – Bug 86627
support for full alpha channel in indexed images
Last modified: 2016-04-17 14:00:19 UTC
I didn't read the spec, but it's possible to have indexed PNGs have alpha transparency. Find a sample image at http://entropymine.com/jason/testbed/pngtrans/pal_bk.png http://entropymine.com/jason/testbed/pngtrans/pal.png I'm only guessing the alpha-channel 'colors' are stored in the pallette too. I think the mode>indexed function should have a 'number of colors for alpha' setting or something). gqview or gdk-pixbuf seems to handle that (I can see GIMP correctly showing the layer thumbnail preview even).
Created attachment 9481 [details] the server name doesn't resolve for some
Created attachment 9482 [details] the one without bcg color set
The support for transparency in indexed PNG images is more or less broken and this has been the case since the early versions of the GIMP. This problem has already been reported in bug #55700. *** This bug has been marked as a duplicate of 55700 ***
The fix for bug #55700 is part of the stable release 1.2.4. Closing this bug.
GIMP head nor 1.2.4 seem to render it correctly though. And I don't see any UI changes that would enable me to index colors in an image with alpha channel either? I'm attaching a screenshot. You can see GIMP renders the file correctly on the layer image thumbnail preview, WM title, selector widget, but not on the canvas. Same thing with 1.2.4. Can you please reopen it? I can't seem to
oops, moved this over to the parent bug.
This bug is not a duplicate of bug #55700. What this bug is asking for is for the GIMP to represent INDEXEDA images correctly, and that's a bigger issue. Perhaps it would be possible to have a proper INDEXEDA palette colourspace definition in gegl? Not sure how it handles alpha... Removing duplicate tag, repoening, changing to low priority. Cheers, Dave.
There are two issues to be considered: 1) Using the current INDEXEDA mode, can we fix the PNG plug-in so that it saves indexed files with full alpha instead of only 1-bit? 2) How to improve the core so that it supports transparency in a way that would work better with PNG, MNG and TGA formats? The answer to 1) is yes: we can fix the PNG plug-in without changing too much in the core of the GIMP: we have a full alpha channel even for indexed images, so the PNG plug-in could use that. The only difference compared to what the PNG file format expects is the way the transparency is associated with the colormap entries. In the GIMP, they are independent of each other. The plug-in would then have to rebuild a colormap when saving. It should probably tell the user how many new RGBA cells have been created. The same could be done for the MNG and TGA plug-ins. Regarding 2), the suggestion to change the INDEXEDA mode will not work: if we change this mode to allow transparency in the way that is used in PNG, MNG and TGA, we would most likely break the support for the file formats that require 1-bit transparency, such as GIF and XPM. It looks like the only solution is to have two different modes: one supporting full alpha (and in which each index in the colormap has the full RGBA value instead of separating alpha from the other channels) and one supporting 1-bit transparency (current INDEXEDA mode). Note that for both modes, we could still have a full alpha channel allocated for each layer. That would be easier for some operations such as layer masks, layer modes and compositing. But that alpha channel could be a strictly internal thing that is not exposed to the outside. In addition, the values in this alpha channel would be constrained to the what is allowed by the colormap if we use the "new" mode (i.e., the A value for the closest RGBA index for which RGB matches), and they would be constrained to only 0 or 255 if we use the "old" mode. There is a separate issue regarding how the image and its preview are displayed. I have just entered bug #115793 about this.
Actually, the answer to 1 is considerably more complicated than that. I'm not sure that the alpha channel is keps for indexed images when converting to indexed - it may be kept during loading of "proper" indexeda images. In any case, dithering a 255/6 colour palette with a full alpha channel to a 256 colour RGBA palette is hardly trivial. Also, it would be almost completely beyond the control of the user. As far as 2 is concerned, since RGB indexed palettes + 1 bit alpha is a subset of RGBA palettes, all GIF type images can be represented with a 256 colour RGBA palette. If there is a "gificisation" to be done, we could have the function that does that exposed in libgimp, so that it could be done with no user interraction in the plug-in, or offered as an indexed image option in the core. In either case, we would present some kind of dialog similar to the one we present for current exports. Having two modes sounds to me like having a new 16 bit RGBA mode to support 5551 because we don't like using full 32 bit and reducing the colours at save time. Or having a little swimming pool beside the big one because it's kid size, as if the water were diffferent. Since gif type indexeda images are a proper subset of png type indexeda images, it makes sense to start from the superset, and dither down if needed. Cheers, Dave.
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
*** Bug 134867 has been marked as a duplicate of this bug. ***
*** Bug 152456 has been marked as a duplicate of this bug. ***
Since over a year now nothing happened on this bug. Are there currently plans to implement the full alpha support on indexed images?
Definitely not for 2.2, I would say. There are a few ways to address the problem: first is to "fix" the GIMP's indexed mode to use RGBA quadruplets for palette entries, second is to abandon indexed mode altogether, and offer "Save as indexed" as an option in the png save dialog, and then do the palette generation there (or rather, in another dedicated plug-in). The former is hard, but would allow a much better (imho) indexed editing mode, the second is easier, and is the solution favoured by the maintainer. Patches for either would be accepted I think after 2.2 comes out. Cheers, Dave.
Just to avoid a misunderstanding: Even though I may like the idea of eliminating indexed mode since it would clean up the code in quite a few places, I don't favour the removal of indexed support from the GIMP core. I don't see a clean way of fixing this problem without breaking backward compatibility. The only reasonable solution would be the addition of another color format. But there are certainly more important color formats to add. So no, I don't see this being addressed any time soon.
On the issue of __reading__ an indexed image with full alpha channel: The gimp png plug-in does a nice job and account for all possible alpha values. But currently, the GIMP discards that information and thresholds alpha at 127. What about popping up an alert box, asking if such file should be oppened as RGBA instead, and thus at least implementing reading png indexed alpha?
GIMP doesn't threshold the alpha to 127, it only displays it as such. If you convert the image to RGB you get the full alpha channel information.
Should we perhaps remove that stupid limitation in the display for GIMP 2.4? I don't see any reason to keep it.
*** Bug 313666 has been marked as a duplicate of this bug. ***
Yes, there is no reason to keep it.
Just to say that I'm still waiting fot that since a few years. I'll be happy then ! Thanks
Bruno, sitting there on your hands and waiting is not how open source works. We are taking patches and we will also try to help you in case you have any questions on how to implement this feature.
This is apparently not on the cards for 2.4, so I will bump the target to Future for now.
Upgrading target to 2.6.
Created attachment 107597 [details] [review] patch to remove alpha thresholding for indexed images This patch is an attempt at removing the alpha thresholding. This needs testing and there are most probably some more changes needed.
Well the patch seems to remove the thresholding. Since it only affects indexed mode I think we should commit this patch if we want to fix this bug; it's a good start for solving it. Not that I think putting much effort in indexed images support is worth the time since its 2008 now ;)
I don't think it should be committed to trunk without more testing. There are definitely other changes needed if we commit this, for example in some file load and save plug-ins. We definitely need someone who is interested in this change and willing to test it and to think about other changes that are needed.
I agree with the sentiment of comment #26. The need for this functionality has declined over the years considerably. As the one opening it, i certainly lost all interest in it. If I need alpha, I'm fine with going RGBA and I don't think this is important enough to make you guys go through hoops to get the functionality.
*** Bug 530933 has been marked as a duplicate of this bug. ***
As the author of a very recent duplicate feature request (forgot to search for "alpha" or "indexed", though I tried several other keywords), I have to disagree with <a href="#c26">comment #26</a> and <a href="#c28">comment #28</a>. I think RGBA-paletted PNG is useful and may have some uses like greatly reducing filesize where a RGBA-paletted PNG image is enough whereas a PNG32 equivalent would have been much heavier for little to no improvement. But those cases may be not so frequent. Of course, it's too bad we didn't have this in those previous years when dealing with IE5 and IE6 was critical. But as Martin Nordholts it's 2008 now, and when Gimp 2.6 will be released IE6 market share won't be that frightening. So my opinion is: if it's reasonably easy to do, it should be done. If it's too big a change, it might not be worth the work.
It is not going to happen unless someone steps forward, willing and capable to test the attached patch and to isolate whatever problems remain and need to be addressed.
*** Bug 602527 has been marked as a duplicate of this bug. ***
> GIMP doesn't threshold the alpha to 127, it only displays it as such. This is not true. If you open and save the image, alpha is thresholded. Until this bug is fixed, I think that GIMP really should at least display a warning, to prevent unexpected information loss.
The thresholding you refer to actually happens in the PNG plug-in when saving the file. That is deliberate though as that is what GIMP displays. As soon as that is addressed (see attached patch), the PNG plug-in would have to be adjusted.
*** Bug 620492 has been marked as a duplicate of this bug. ***
*** Bug 646652 has been marked as a duplicate of this bug. ***
*** Bug 672681 has been marked as a duplicate of this bug. ***
Just to add my two cents, after days of troubleshooting why my web backgrounds went opaque after recoloring them, I think we still need this capability. (At least I learned a lot about a) PNGs, b) imagemagick, c) GIMP, d) alpha channels, but at the worst possible time.) There's a lot of "duplicates of this bug", so people are still hitting this wall, even thouigh it's 2012 (11 years later). I'm firmly in the "user" camp, but I'm willing to spend time pounding away on any solution someone may devise. Some more info: my issue revolved around PNG32 solid, single-color images with alpha for web site translucent article backgrounds. Interestingly, clearing a single pixel of the image causes GIMP to save the alpha channel, although it seems to be a binary alpha.
If you had a problem with PNG32 images (that is, RGBA images instead of INDEXEDA), then you've got something different.
I think it's PNG32 because it seems to have an 8-bit alpha. The problem symptom, silently stripping the alpha on save is consistant, so it's likely related. Here is the 'identify' output on the original image, the resaved file (no other operation performed) and the diff. The alpha is gone. The image type changes from PaletteMatte to Palette. The transparent color goes from none to black. Maybe it needs to be a new bug, but I'd likely call it "support for full alpha channel in indexed images." ============================= $ cat Sheet-c-original.txt enter ReadPNGImage() enter ReadOnePNGImage() PNG width: 102, height: 102 PNG color_type: 3, bit_depth: 1 PNG compression_method: 0 PNG interlace_method: 0, filter_method: 0 Reading PNG iCCP chunk. Reading PNG cHRM chunk. Reading PNG pHYs chunk: xres: 3779, yres: 3779, units: 1. Reading PNG tRNS chunk. Reading PNG PLTE chunk: number_colors: 1. Reading PNG IDAT chunk(s) Converting PNG pixels to pixel packets exit ReadOnePNGImage() exit ReadPNGImage() Image: Sheet-c-original.png Format: PNG (Portable Network Graphics) Class: DirectClass Geometry: 102x102+0+0 Resolution: 37.79x37.79 Print size: 2.69913x2.69913 Units: PixelsPerCentimeter Type: PaletteMatte Endianess: Undefined Colorspace: RGB Depth: 8-bit Channel depth: red: 8-bit green: 8-bit blue: 8-bit alpha: 8-bit Channel statistics: Red: min: 246 (0.964706) max: 246 (0.964706) mean: 246 (0.964706) standard deviation: 0 (0) kurtosis: 0 skewness: 0 Green: min: 248 (0.972549) max: 248 (0.972549) mean: 248 (0.972549) standard deviation: 0 (0) kurtosis: 0 skewness: 0 Blue: min: 224 (0.878431) max: 224 (0.878431) mean: 224 (0.878431) standard deviation: 0 (0) kurtosis: 0 skewness: 0 Alpha: min: 32 (0.12549) max: 32 (0.12549) mean: 32 (0.12549) standard deviation: 0 (0) kurtosis: 0 skewness: 0 Image statistics: Overall: min: 32 (0.12549) max: 248 (0.972549) mean: 187.5 (0.735294) standard deviation: 90.2704 (0.354002) kurtosis: -0.697481 skewness: -1.11807 Histogram: 10404: (246,248,224,223) #F6F8E0DF rgba(246,248,224,0.87451) Rendering intent: Undefined Chromaticity: red primary: (0.63999,0.33001) green primary: (0.3,0.6) blue primary: (0.15,0.05999) white point: (0.31269,0.32899) Interlace: None Background color: white Border color: rgba(223,223,223,1) Matte color: grey74 Transparent color: none Compose: Over Page geometry: 102x102+0+0 Dispose: Undefined Iterations: 0 Compression: Zip Orientation: Undefined Properties: date:create: 2012-03-20T11:49:51-04:00 date:modify: 2011-12-26T13:05:42-05:00 signature: 3f1f49a0eb26b0e59bfea3edb93f8d2591821874cd4e6a90b2389077b7c65891 Profiles: Profile-icc: 3144 bytes IEC 61966-2.1 Default RGB colour space - sRGB ***** Profile Hex Data Removed ***** (John Desmond) Artifacts: verbose: true Tainted: False Filesize: 2.82KB Number pixels: 10.4KB Pixels per second: 347KB User time: 0.020u Elapsed time: 0:01.030 Version: ImageMagick 6.6.0-4 2012-03-05 Q16 http://www.imagemagick.org $ cat Sheet-c-resaved.txt enter ReadPNGImage() enter ReadOnePNGImage() PNG width: 102, height: 102 PNG color_type: 3, bit_depth: 1 PNG compression_method: 0 PNG interlace_method: 0, filter_method: 0 Reading PNG iCCP chunk. Reading PNG pHYs chunk: xres: 3779, yres: 3779, units: 1. Reading PNG bKGD chunk. Reading PNG PLTE chunk: number_colors: 1. Reading PNG IDAT chunk(s) Converting PNG pixels to pixel packets exit ReadOnePNGImage() exit ReadPNGImage() Image: Sheet-c-resaved.png Format: PNG (Portable Network Graphics) Class: PseudoClass Geometry: 102x102+0+0 Resolution: 37.79x37.79 Print size: 2.69913x2.69913 Units: PixelsPerCentimeter Type: Palette Endianess: Undefined Colorspace: RGB Depth: 8-bit Channel depth: red: 8-bit green: 8-bit blue: 8-bit Channel statistics: Red: min: 246 (0.964706) max: 246 (0.964706) mean: 246 (0.964706) standard deviation: 0 (0) kurtosis: 0 skewness: 0 Green: min: 248 (0.972549) max: 248 (0.972549) mean: 248 (0.972549) standard deviation: 0 (0) kurtosis: 0 skewness: 0 Blue: min: 224 (0.878431) max: 224 (0.878431) mean: 224 (0.878431) standard deviation: 0 (0) kurtosis: 0 skewness: 0 Image statistics: Overall: min: 224 (0.878431) max: 248 (0.972549) mean: 179.5 (0.703922) standard deviation: 104.061 (0.408083) kurtosis: -0.689701 skewness: -1.12701 Histogram: 10404: (246,248,224) #F6F8E0 rgb(246,248,224) Colormap: 1 0: (246,248,224) #F6F8E0 rgb(246,248,224) Rendering intent: Undefined Interlace: None Background color: rgb(1,1,1) Border color: rgb(223,223,223) Matte color: grey74 Transparent color: black Compose: Over Page geometry: 102x102+0+0 Dispose: Undefined Iterations: 0 Compression: Zip Orientation: Undefined Properties: date:create: 2012-03-20T11:51:16-04:00 date:modify: 2012-03-20T11:51:16-04:00 signature: 9bd70cb6aa50aa4c2f266d56b60ff6de64985ee83c52de24718d6ada5f71424e Profiles: Profile-icc: 3144 bytes IEC 61966-2.1 Default RGB colour space - sRGB ***** Profile Hex Data Removed ***** (John Desmond) Artifacts: verbose: true Tainted: False Filesize: 2.77KB Number pixels: 10.4KB Pixels per second: 520KB User time: 0.010u Elapsed time: 0:01.019 Version: ImageMagick 6.6.0-4 2012-03-05 Q16 http://www.imagemagick.org $ diff Sheet-c-original.txt Sheet-c-resaved.txt 8d7 < Reading PNG cHRM chunk. 10c9 < Reading PNG tRNS chunk. --- > Reading PNG bKGD chunk. 16c15 < Image: Sheet-c-original.png --- > Image: Sheet-c-resaved.png 18c17 < Class: DirectClass --- > Class: PseudoClass 23c22 < Type: PaletteMatte --- > Type: Palette 31d29 < alpha: 8-bit 54,60d51 < Alpha: < min: 32 (0.12549) < max: 32 (0.12549) < mean: 32 (0.12549) < standard deviation: 0 (0) < kurtosis: 0 < skewness: 0 63c54 < min: 32 (0.12549) --- > min: 224 (0.878431) 65,68c56,59 < mean: 187.5 (0.735294) < standard deviation: 90.2704 (0.354002) < kurtosis: -0.697481 < skewness: -1.11807 --- > mean: 179.5 (0.703922) > standard deviation: 104.061 (0.408083) > kurtosis: -0.689701 > skewness: -1.12701 70c61,63 < 10404: (246,248,224,223) #F6F8E0DF rgba(246,248,224,0.87451) --- > 10404: (246,248,224) #F6F8E0 rgb(246,248,224) > Colormap: 1 > 0: (246,248,224) #F6F8E0 rgb(246,248,224) 72,76d64 < Chromaticity: < red primary: (0.63999,0.33001) < green primary: (0.3,0.6) < blue primary: (0.15,0.05999) < white point: (0.31269,0.32899) 78,79c66,67 < Background color: white < Border color: rgba(223,223,223,1) --- > Background color: rgb(1,1,1) > Border color: rgb(223,223,223) 81c69 < Transparent color: none --- > Transparent color: black 89,91c77,79 < date:create: 2012-03-20T11:49:51-04:00 < date:modify: 2011-12-26T13:05:42-05:00 < signature: 3f1f49a0eb26b0e59bfea3edb93f8d2591821874cd4e6a90b2389077b7c65891 --- > date:create: 2012-03-20T11:51:16-04:00 > date:modify: 2012-03-20T11:51:16-04:00 > signature: 9bd70cb6aa50aa4c2f266d56b60ff6de64985ee83c52de24718d6ada5f71424e 256c244 < Filesize: 2.82KB --- > Filesize: 2.77KB 258,260c246,248 < Pixels per second: 347KB < User time: 0.020u < Elapsed time: 0:01.030 --- > Pixels per second: 520KB > User time: 0.010u > Elapsed time: 0:01.019
*** Bug 740234 has been marked as a duplicate of this bug. ***
Comment on attachment 107597 [details] [review] patch to remove alpha thresholding for indexed images This is now obsolete, there is no such code in master. Is there anything left to do at all? I think we can just close this as FIXED.
Closing as FIXED. Tried some of the example images in the duplicate bug reports, they showed up correctly.