Brush Preview - Feature Request

Hello Krita-Artists.org!
This is my first ever post on here but I would like to suggest a “Brush Preview” docker much like FireAlpaca has.

I have found it overwhelming time and time again flipping through the great selection of brushes here on Krita and not knowing what they do unless I paint with them and possibly ruin my canvas.

A Brush Preview docker would honestly be such a great addition for me and I believe many other artists as when you flip through the different brushes you are able to preview how they look, how they change the canvas, and how transparent they are.

I do know that Krita has the brush menu which includes a Brush Preview so I believe the code to be there already. It is just having to click on the brush menu is as much of a hassle as is painting on the canvas rather than having a docker that you can move around.

Below is a few examples of how FireAlpaca’s preview works with their different brushes much like Krita has -

image
[“Watercolor”]

image
[“Eraser”]

Hopefully, this can get implemented! <3
Thank you for listening. I hope you have a great rest of your day!

11 Likes

Hi

The brush editor already provide it:

So as it seems everything already exist to generate this preview, I suppose that it should be possible to have… :thinking:

Grum999

1 Like

There is the scratchpad. Just use the “Edit Brush Settings” button. Then click the arrow on the left to expand the Presets. Now you can switch between brushes there and see the preview as well and instantly test them on the scratchpad on the right as well (you may need to click the arrow on the left to expand it)

This will be a nice feature. I agree the reasons provided. Seeing an image visual of properties like opacity can be more intuitive than numeric value.

I talked about automated brush icons in earlier of my post but this feature fulfills my request (a welcome surprise :grin: . A preview docker will provide quick easy and live information about brush present.

1 Like

I always wanted the brush preset lists (in the docker and the toolbar) to have the option to show the stroke. It’s on my list of things of things to see if I can implement. Would be really helpful in finding some less used brushes. The ones I most use I recognize by their thumbs (usually my terrible scribbles), but often the ones I use less are for specific textures and not mine so have their own thumbnails. Which while they’re nice, the actual stroke is often a very small part of the thumb. It’s hard to see if it’s the texture that I was looking for.

5 Likes

yes. The texture will show up better :grin:

I do not know if this is mentioned but a preview stroke docker will allow user to judge the properties of the brush objectively at a glance compare to brush icon only or brush name only.

1 Like

It would be cool to have the option to see the preview of the brush stroke from the brush presents docker. Here’s my mockup of it

image

8 Likes

Yes, but as I said in the post it is still more of a hassle rather than having a visual docker you are able to glance at and move around.

That was implemented by @scottyp I think. We can ask him to guide you if you have free time to volunteer for this feature. It would be good to have in my opinion.

Also a note: Not all brush engine can get a preview, so there will be brushes with “No preview available” message.

2 Likes

you have my vote for this!
i see plenty people using that sort of listing in other software so its evidently useful.

this preview is still somewhat incomplete though. the shape fill engine doesnt generate a preview nor does the ‘blender pixelize’ preset. then theres the question of how to represent different blend modes in the preview since some brushes are designed specifically for certain blend modes.

on the more technical side of things i guess its worth asking when to generate the stroke preview. i worry that generating each stroke on the fly as the user scrolls through the list might cause experienced slowdown (especially on lower end hardware). you cant save the preview as a plain image since it needs to adapt to kritas theme. is the best option then to generate the previews on startup and cache them somehow? do we dare to request more features for the new resource system? :stuck_out_tongue:

1 Like

On my side, according to brush, the blend mode is taken in account in the preview…

Or you’re talking about something else?

Once a preview is generated for brush, it can be stored I think.
No need to regenerate it unless the brush definition is modified.
no?

Grum999

1 Like

colour, hue, increase/decrease saturation, for example :wink:
one could also argue that modes like overlay, multiply, colour dodge, and screen would benefit from having a preview that goes from dark to bright and that involves some kind of hue as well. i think that might be overkill though. as long as you can tell that its different from the normal blend mode it should be fine.

i was mainly thinking out loud about how to achieve the best performance+ux. if someone changes kritas theme they probably expect their list of brushes to adhere to the new colour scheme and all the previews would have to be regenerated (maybe changing themes should prompt the user to restart krita idk). generating and storing the preview is probably something that would need to be worked into the new resource system for krita 5 too. i know halla is very eager to finish up on that so im just careful not to step on any toes :smiley:

@Grum999 - The existing preview code is already a QWidget…so it probably wouldn’t be too hard to reuse in other areas. Here is where the code is at …

5 Likes

Yeah, I think that would be a good optimization. And the preview image itself shouldn’t be affected by the theme, so I think the only thing that would necessitate generating a new preview image is opening the brush editor and making changes in there.

A question that would have to be answered, probably by @halla or @dkazakov, is whether it would make sense to add that preview image to the brush preset file itself, so it can be loaded directly when the preset is loaded, or if it should always be generated new when the preset is loaded. I can see performance pros and cons to both options, and don’t know enough about the new resource system to know which makes more sense with it.

I do really like the idea of seeing a preview without having to open the brush editor, so I hope this becomes reality!

2 Likes

Here is a mockup inspired by @fizzyflower 's.

On the left is the curvy s-style preview and on the right is Krita’s standard preview.

*note: for the s-style preview, I guessed the values for the curves.

8 Likes

My point of view is to have the basic: same render than one produced by default brush in brush editor.

If you start to take in account brush size, brush color, opacity, current blending mode, … it could be confusing because you have in mind an “image” of what you search, and potentially it won’t be the same each time you look to your brush list.
(I don’t know what other painting software does)

The preview should be theme independent.
Eventually, a PNG file preview with transparency to get a background matching current theme (like it’s currently done in brush editor).

In this case, preview can be generated when brush is created and/or when displayed in list for first time (and then, saved in a cache)

Thanks for information!
Problem of a QWidget, it’s a QWidget :slight_smile:

Didn’t look in detail how it’s implemented, but best thing might be to split it in 2 part:

  • A QObject that produce a QPixmap
  • A QWidget that use the QObject to get a QPixmap

This allows to be able to generate preview without being dependent of a widget in an interface.
And having code centralized in one place:

  • ensure to produce the same rendered preview everywhere
  • only one place where to maintain code

But this need to do some additional work… :confused:

+Adding the option from @fizzyflower about possibility to choose how brushes are displayed (like now or with preview)

The s-style is interesting to, but might be influenced by other software.

My point of view is to keep for the preview the same render than one currently applied by Krita in brush editor (keep consistency and own way for Krita to render preview).
After that maybe could be an option…

Grum999

3 Likes

The preset docker uses a QListView (well a derived class) to display the presets, so the individual entries are not actually QWidgets but rendered by a specialized item delegate (KisPresetDelegate).

As far as I know, they use one pic for all in Medibang Paint Pro / Fire Alpaca for instance. But I’ve got only a few brushes for those toys! :wink:

Michelist

I really like the way you designed your mockup! :heart_eyes:

I think I would like to see an option to have the brush stroke previews rendered as a “S-curve” one day even though the design copies the way other software does it

1 Like