GNOME Bugzilla – Bug 72877
Incorrect RGBA resampling in Warp plug-in
Last modified: 2018-05-24 10:41:10 UTC
If two pixels have different opacity values (alpha channel), then their colors are not averaged correctly by the Map->Warp plug-in. It looks like the RGB channels are resampled without taking the opacity into account. As a result, the (invisible) color of a transparent pixel can bleed into an opaque pixel. The resulting image is incorrect. See bug #70335 for some test images and a longer description of the problem. This problem affects many other tools and plug-ins.
Changed target milestone of several bugs to 2.0 - these are not features, and don't look to me like blockers for a pre-release, but they have to be addressed before 2.0. Dave.
Bumping the milestone for this bug, and all that depend on it, to 2.2. In the absence of someone actively working on this, there is no point keeping it on the 2.0 milestone. If someone wants to work on this, fixes to this family would also be accepted on the stable branch. Dave.
To use Dave's famous words: In the absence of someone actively working on this, there is no point keeping it on the 2.2 milestone.
Making this change would introduce a bug. The current behavior is correct for many users; the alpha channel is used to hide parts of the image. Hidden parts have perfectly valid data. So, if you "fix" this "bug", be sure to allow for those of us that work with images that have fully valid data in the transparent and semi-transparent areas. Since the proposed change kills performance and causes data loss, it needs to be disabled by default. (with an appropriately hidden option to enable it)
If you want to make some parts of an image transparent while still keeping the color data then you should use a layer mask, not the alpha channel. Using a mask ensures that the RGB channels will not be modified. But if a pixel is fully transparent (alpha channel = 0), then the contents of the RGB channels become unspecified: some operations may keep the color intact while some other operations may destroy it. There are examples of both in the GIMP and the GIMP does not make any promises that the current behaviour of some operations will not change in the future. As the color of these pixels is unspecified, using them in any operation is a bug. There has been a lot of debate about masks, alpha channels and transparency. So before you argue about this, I suggest that you read the related bug reports and the archives of the gimp-developer mailing list.
One is strongly led to use alpha, not layer masks. a. when I create a new image, RGBA (not what, RGBM?) is a choice b. when I load a PNG, RGBA is used c. the PNG spec uses the term "alpha" d. non-gimp documentation uses the term "alpha" e. when I save a masked image as PNG, gimp whines about it f. masked images can not be rotated (maybe fixed in CVS?) It looks to me like you've invented a new term ("mask") and abused a traditional term ("alpha") for some other purpose. Hence the confusion and awkwardness. Pre-multiplied alpha is a rare and evil beast from the past. It's not something that normal users should ever bump into.
I suggest that you take this discussion to the gimp-developer mailing list if you have strong feelings about it. However, as I mentioned in bug #70335, you should also take a look at the PNG specification (http://www.w3.org/TR/PNG/) which notes that the alpha channel can be used for different purposes and even recommends clearing the color of transparent pixels in some cases (in order to achieve better compression). I also recommend that you look at the previous discussions on the gimp-developer mailing list (archives: http://www.gimp.org/mail_lists.html) about the difference between pixels that are fully transparent (undefined RGB, alpha = 0) and those that are simply hidden (well-defined RGB, mask = 0). You also seem to be confusing pre-multiplied alpha (which is usually a file format issue) with the necessity to have RGB colors weighted by their opacity in any compositing operations. If that was not done correctly, then the GIMP would not even be able to display partially transparent layers on top of each other.
This bug is resolved, since he introduction of the GEGL based warp tool uses RaGaBaA for resampling.
Unfortunately, the warp tool replaces the IWarp plug-in, not the wrap plug-in. Was about to close this bug myself a couple of times...
Hello guys, Can you tell me please what about this version? I didn't understand what it is this version. Is it 2.0.0 – 2.0.6 ??????? Merci
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/21.