Hmm, well, I didn’t actually mention the difference between black brush mark on white and white brush mark on black. There are areas of quantization in both cases, it’s jut not as obvious with black marks on white. But the dividing lines between the various quantized areas appear to be in the same place for black on white as for white on black - zoom way in and look closely, and you’ll see it.
There really are quantized-appearing areas even for the radial gradient, but the “lines of quantization” are much closer together and I’m guessing this might be a case of screen quantization. There’s always quantization on the screen as the screen only displays integer increments (speaking of normal screens, not $10,000 state of the art screens used in the movie industry). And if one wants to be super nit-picky even floating point numbers are quantized at the bit/byte level, though the size of the increment is presumably hugely smaller than the human eye can discern.
I don’t know how to export a Krita brush, but here’s a screenshot of the settings I used. I don’t have my tablet hooked up at the moment, so this is just a basic “mouse only” adjustment:
It sort of looks like a bug to me. But maybe it’s a deliberate compromise/trade-off between speed and accuracy, in which case it still could be considered a bug depending on one’s priorities when painting.
If it is brush bit depth, it sure is a bug. One would expect brushes to be aligned to the reference space, both colour space and bit depth I would think.
Perhaps not a bug that can be repaired immediately, but should be on the TODO at the very least.
i note that the transparent layer isn’t needed to reproduce this and that brush hardness affects the position of the quantization considerably. On a quick inspection the brush preview is 8bit but i’m not sure that’s used for painting.
However, paint/gimp_brush_core_subsample_mask() has a suspicious-looking 127 in it.
@gungan - if you would like to file an official bug report, that would be nice - maybe reference this thread and of course post your example images and/or any of the screenshots I uploaded to this thread.
This quantization really does look like a bug. If perchance you haven’t ever made an official GIMP bug report before, this link has the “how to” information: GIMP - Bugs
I suspect @barefootliam and @anon11264400 are right, that the brushes are still 8-bit brushes, and that might be the problem. But either way, those quantized edges aren’t pretty!
If that’s the case, it is a double whammy. First it is quantised at eight bits and upsampled, so there are canyons between values. Worse, there are collisions in all of the lower values potentially as they collapse into a many-to-one situation, hence the huge posterisation gaps.
Should I report the issue, or maybe some of you guys? I’m thinking you have a better insight in what exactly is going on in the back end, so you’d explain it better? Just wanted to check with you.
The actual bug report is just that there’s very visible posterization along the edges when making certain kinds of brush marks. Anything beyond that is just guessing.
If you make the bug report, then as soon as I see it I’ll post a follow-up comment confirming your findings - I check GIMP bug reports every morning, or you could post the link here. But if you prefer, I don’t mind making the bug report - your sharp eyes have found an issue that does need attention, and having seen that edge posterization I think I’ll have trouble “unseeing” it .
I tried to simplify it as best as possible, and to follow the bug template. I hope it’s alright. Do keep an eye on it a bit, cause I’m all over the place .
The gbr and gih brushes are 8-bit brushes - if you open one of these brushes as an image, change the precision to 32f and then export again as a new brush, and reopen the exported brush, it’s at 8-bit precision.
I thought there was an open bug report about GIMP gih and gbr brushes only being 8-bit precision but I can’t find it - the gitlab bug reports are not easy to search, or maybe I just haven’t figured out how to use the search interface. Apparently the vbr brushes also are 8-bit brushes.
Thanks! for the information. Are the Krita layer masks also 8-bit? Or maybe just the histogram binning when using Levels/Curves on a layer mask? I remember being puzzled about this the last time I used Krita for painting.
If you were painting an image that’s in the regular sRGB color space in Krita, you wouldn’t notice edge artifacts because the regular sRGB color space has an approximately uniform Tone Response Curve.
GIMP is a bit different from Krita in that for Krita, to paint using linear sRGB, the image has to be converted to a linear gamma sRGB ICC profile, which of course should only be done with a high bit depth image. But for GIMP the RGB channel values are automatically converted to linear RGB for most operations, unless you do something like choose Legacy or change the composite mode.
The more I think about it, the more something feels “more wrong” in GIMP. An 8 bit brush, if handled properly, should result in the exact same quantised steps in a linearised reference space, and appear identical to its 8 bit counterpart in a nonlinear reference.
Is it possible the brush isn’t being managed and the 8 bit values are being interpreted as linear values?
Off-topic but sounds familiar : It seems the recently released PhotoShop CC 2019 has legacy and default compositing modes, with users resorting to legacy to restore previous blending results:
Anyone know what the differences are between PhotoShop CC 2019 legacy and default compositing modes?
Completely off-topic: Is proprietary software now being marketed like new cars, such that 2019 updates are released in the fall of 2018? This just seems odd.
“The October 2018 release of Photoshop CC (version 20.0)” called Photoshop CC 2019?! Really dislike this sort of naming convention. There are the devs and then there is marketing.
So, I just saw that this issue was labeled as a bug at gitlab, so I was wondering, is there any way to follow the status of it, or we just have to wait till it’s handled all in all? Not in a rush or anything, just never followed a bug fix with GIMP before.
While we’re at it, I was further testing all of these 2.10 features and I was wondering about Blend space and Composite space. Whenever we change the layer mode, as in from Multiply to let’s say Screen, Blend space and Composite space would reset from Linear and Perceptual to Auto. So we always have to change to what we want with Blend and Composite, again and again, when we change the layer mode. Seems a bit of a hassle. So I was wondering is that how it’s suppose to be and there’s a reasoning behind the constant reset?
The idea is that the “auto” blend/composite/etc defaults to the technically correct option, either linear or perceptual depending. So as a user, you aren’t expected to have to keep changing these except on a layer by layer basis. So yes, having to reset each and every layer every time you change the layer blend mode is a hassle.
The hassle is made worse because the word “auto” doesn’t tell the user which option is being used, which is highly annoying. I opened a bug report on this issue awhile back. Please feel free to add a comment if this bug report addresses the situation you are describing:
In your particular use case, I suspect the main reason you are resorting to constantly changing the blend and composite modes is as a workaround to the truly awful posterization you are getting as you try to softly shade an image. In other words, if the 8-bit posterized brush stroke issue were fixed, it’s possible that you’d quickly adapt to shading using linear instead of perceptual RGB. Leastways I do a lot of shading and I always use very low opacity linear RGB multiply for this task. But on the other hand, maybe your style actually requires perceptual RGB for this task.
There was a time when the “default/legacy” switch in the layer dialog could easily have been converted to a “linear/perceptual” switch on a layer by layer basis, but that particular suggested code change never got incorporated - instead we have the “right-click on layer” to accomplish the same thing. But I think more goes on with “default/legacy” than just the RGB encoding, which might be why there are two ways to get from linear to perceptual.
If you think it’s worthwhile, you might want to open a bug report requesting a way to set a given layer to a specified composite space and have that stick throughout the layer’s life and regardless of changes in the layer’s blend mode.
Changing topics, I suspect that this “8-bit posterization” bug you’ve uncovered is why I keep piling on texture/fade/small color changes/noise/etc in the brush dynamics that I’ve put together, in an effort to mask abrupt tonal changes that I never actually thought of as “oh, that’s at least partly 8-bit posterization”.
Not sure exactly what you are asking - are you receiving notifications when someone makes a post to the bug? If not, this can be controlled through your gitlab GNOME account.
If no one has any patches or comments, then nothing will be posted. Sometimes a long time goes by before any given bug is worked on. There are only a few devs and a lot of bug reports, and the main thing right now that most of the devs are working on is converting from GTK+2 to GTK+3.
I’ll consider writing something specifically on the topic in the future, perhaps. But I thought that “Auto” always meant Linear. I had no idea that it could be either, depending on “the technically correct option”. Especially if one doesn’t know what is technically correct in a given situation.
.
.
Really dislike this sort of naming convention. There are the devs and then there is marketing. 