GNOME Bugzilla – Bug 777704
'Merge visible layers' erases RGB values for 100% transparent pixels on the stack
Last modified: 2017-02-09 17:55:17 UTC
When exporting individual layers of a multiple layer GIMP file as PNG, the colour values of transparent areas are not preserved properly. This results in the exported file being unusable in, e.g. Blender VSE, as the transparent areas will have black jaggies around them. To reproduce: 1. Create a new file in GIMP, filled with white 2. Add an alpha channel to the layer, then duplicate the layer 3. Hide the bottom layer, select the top layer 4. On the top layer, create some transparent areas by erasing, or selecting and deleting an area 5. Export the top layer as exp1.png 6. Open exp1.png in GIMP, and use 'Anti-erase' to see what colour values are 'behind' the alpha channel - for me, they are black, which is wrong (they should be white) 7. In the original GIMP file, _delete_ the hidden layer, then export the top (now only) layer as exp2.png 8. Open exp2.png in GIMP and use 'anti-erase' - the alpha will be removed and white will show again At step 4 in the original GIMP file, 'anti-erase' will restore white, so I'm pretty sure GIMP is holding the correct colour values for that layer. But the PNG exporter does not seem to cope well with multiple layers. The workaround is to delete all layers except the one to export, then 'undo' and repeat for other layers to be exported.
Update - I now have a single-layer .xcf file which shows this problem; it happens when the single layer is not the same size as the image. If I export such an image as png, _all_ transparent pixels are shown as black + full transparency - even those which have real colour values 'underneath' the transparency in the .xcf file. If I expand the layer to the size of the image (Layer → Layer to Image Size) before exporting, the colour values are preserved.
You can't have color values where there is no layer, they simply don't exist. Where do the "preserved" values come from when you simply enlarge the layer? By default those areas are filled with black transparency. I think there is some misunderstanding.
Yes, I think there is :). When the layer is smaller than the image, _all_ the colour values for that layer are erased under the transparent areas. I believe they shouldn't be. When the image is expanded to the image size, the 'old' areas of that layer under the transparency are preserved. The newly expanded area of that layer are, rightly, black. For example: Imagine a layer 400px wide in a 600px wide image. The layer is solid white. Now erase the right hand half of the layer (from 200px to 400px in the image coordinates). Exported as png, this should give an image which is in 3 sections from left to right 200px white, 200px transparent with white 'underneath' and 200px transparent with black underneath. What I get is 200px white and 400px transparent with black underneath. The colour values from 200px to 400px in the original have been lost. Hope that helps.
Thre is no U.I. for "export layer" - what happens is that when you hide all other layers and export the image (or export an image which single layer is a different size than the canvas). the exporter mechanism in GIMP perform a "merge-visible-layers" on an image copy before even calling the plug-in - the plug-in always get a single drawable to work on. (File exporters that don´ t support alpha transparency get the drawable after a "image-flatten" - not even "merge-visible-layers". The merge-visible-layers behaves as if there was a virtual background layer filled with RGBA(0,0,0,0) - and that is what results in you getting black pixels. This mayeb is not THAT complicated to fix, as it requires rewritting the core code for "merge-visible-layers" to preserve the 'RGB' values even of fully transparent layers - but them, someone has to step in and change it. Meanwhile, since you are a somewhat advanced user needing to export several layers of an image to reuse in a 3D program, you might gain more productivity of using one of the GIMP built-in command prompts (tiny-fu or Python-fu) to export each drawable with a direct plug-in call. That will not only preserve the RGB values you need, as it can be done in a single step for all layers of an image. For example, the following expression, if pasted on the Python prompt, will save all layers of the leftmost-tab image (denoted by the [0] index) on the "/tmp/" folder named as "<layername>.png"> - The complicated parameters for the pdb PNG file save function are easily dealt with if you use the "browse" button on the botton of the dialog - the "apply" on the PDB browsing will paste a template for the PDB call - in this case, I tweaked it to ensure offsets are not saved, and transparent pixels RGB values are kept: >>> [pdb.file_png_save2(layer.image, layer, "/tmp/" + layer.name + ".png", "/tmp/" + layer.name + ".png", 0, 9, 1, 1, 0, 0, 0, 0, 1) for layer in gimp.image_list()[0].layers]
Many thanks for the clear explanation of why this happens - it's good to know there is a real root cause! I've not been a contributor to GIMP but use it a lot, and it would be nice to see if I can work out a fix. I guess merge-visible-layers would benefit from it anyway, regardless of the png export side of things. In the meantime, your python snippet is great - I will maybe see if I can build a plugin based on that to export all / visible layers to a specified location.
There is no guarantee whatsoever for color values of 100% transparent pixels. Some operations might preserve them, most don't.