GNOME Bugzilla – Bug 771240
grayscale gih brushes made with transparent layers paint black squares
Last modified: 2018-05-24 16:54:19 UTC
Created attachment 335299 [details] grayscale gih brushes made using transparent layers paint black squares When making a grayscale gih brush with transparent layers, the resulting brush just paints black squares. Looking at the code in file-gih.c (https://git.gnome.org/browse/gimp/tree/plug-ins/common/file-gih.c#n1201), it looks like any alpha channels are supposed to be ignored, but it seems like something isn't happening as intended - maybe the transparent backgrounds are being filled with black instead of white? case GIMP_GRAY_IMAGE: case GIMP_GRAYA_IMAGE: /* alpha channel is ignored */ format = babl_format ("Y' u8"); Removing the alpha channels before exporting the brush (and making sure the background color is white) makes a brush that works as expected.
Hmm, it sounds like this same bug was reported in 2008 (bug 565623) and closed as not a bug. But I suspect no-one making a grayscale gih brush really intends to make an animated series of black squares, and if they did, they'd just fill the brush layers with solid black.
It's exactly as intended. Grayscale images are saved as mask-only brushes that take the color from the current foreground. If you want to make colored GIH brushes, use RGB images. Gray values are just colors too.
(In reply to Michael Natterer from comment #2) > It's exactly as intended. Grayscale images are saved as mask-only > brushes that take the color from the current foreground. > > If you want to make colored GIH brushes, use RGB images. Gray values > are just colors too. I'm aware of the difference between RGB and grayscale gih brushes. This bug report is only about grayscale gih brushes. Consider these two scenarios: Scenario 1: If a user makes a grayscale gih brush where all the layers are varying shades of gray stains on transparent layers, and exports the resulting layer stack as a gih brush, and then paints with the gih brush, the only thing that's painted is a series of black squares. The actual stains on the transparent layers don't matter. Scenario 2: If the user goes back to the layer stack, sets the background color to white and removes the alpha channels from all the layers in the layer stack used to make the grayscale gih brush (so now the layers are gray stains on white instead of gray stains on a transparent layer), and exports the gih brush again, then the gih brush uses the foreground color to paint the stains that the user actually created. It seems to me that a lot of people might not expect that a grayscale gih brush made with transparent layers will actually only paint black squares and not the stains that the user actually put on the transparent layers. So this could be considered a user education issue. And it could be considered a bug simply because the behavior seems unexpected.
This does still happen with current git master?
(In reply to Michael Schumacher from comment #4) > This does still happen with current git master? I have tested on git master commit 6918b4b, creating brushes with transparent layers: # if you exported as .gbr is *OK*, the layer when I open as image results with no alpha... and works normaly. # if you exported as .gih is *NOT OK*, produces the Scenario 1, related by Elle in comment 3.
(In reply to jose americo gobbo from comment #5) > # if you exported as .gih is *NOT OK*, produces the Scenario 1, related by > Elle in comment 3. If you open this .gih brush as image, the layers are resulting completely black and without alpha channel. So, is not possible recover the brush without the original .xcf (Scenario 2 Elle comment 3).
D'oh - off course - which means we will either need a new .gih file spec and implementation for this to work, or use XCFs (or ORA) as brushes in the short term. :-( Anyway, since the original "transparency should be transparency" for gray-scale GBRs is fixed, I suppose this is a valid complaint now.
Created attachment 370786 [details] [review] fix transparent grayscale layer to gih Here the behaviour is the same as gimp-2.8 and it depends on the color of transparent pixels: transparent whites become transparent pixels in the brush transparent blacks become opaque pixels in the brush The attached patch treats completely transparent pixels (alpha == 0) in the same way (regardless of their invisible color) and they become transparent in the brush. Don't know if this is what is desired here.
-- 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/963.