vfx features for Krita

Boudewijn Rempt boud at valdyas.org
Wed Mar 27 16:59:13 UTC 2013


On Wed, 27 Mar 2013, Simon Legrand wrote:

> Hey guys. So the Matte painting guys have been putting Krita through its paces and this is what they came up
> with as their main priorities:
> 
> Priority:
> 
> - Performance. That's the greatest priority. We need to be able to paint in 16bit 4k + smoothly.

Tthat needs investigation. I am noticing that there are sometimes awful 
delays, and sometimes it's just smooth. But yeah, needs investigation.

> - Painting on the 'transparency layer' should be done with black and white color not with eraser and paint.

Dmitry already has that in a branch, it needs some finishing touches 
though, most fixing a few remaining brushes.

> -This transparency layer should be displayable on its own. IE: ctrl+eye on a transparency layer should display
> the layer as a grayscale image

I've been thinking about this since the meeting in London. I thought we 
could load/save masks as images, but that's not true either -- both need 
to be implemented. Anyone any idea on how to fix this? If masks were 
really grayscale, it would have been easy enough, I guess.

> - At the moment the brush opacity in the transparency layer seems to be either 1 or nothing. The painting
> environment of the layer mask should be full greyscale like any normal greyscale layer.

Thats the same issue as the one above: this also solved in Dmitry's 
branch.

> - Clone tool needs a 'sample anything visible option'. Dare I say like Gimp (sample merged)? Or photoshop's
> default clone tool behaviour. :)

Right.

> Important:
> 
> - Select by colour improvement. At the moment it's limited to a selection box with discreet hues to pick from.
> This would be nice to turn into a color picker with some parameters for adjusting the range of selection
> (threshhold in Gimp, fuzziness in Krita fill selection)

There is the "select similar colors" tool -- that selects using a color 
picker with a range determined by fuzziness. Or do you mean something 
else?

I actually don't know why we have the select/select from colorrange dialog
still -- it's really old.

> 
> - Healing and cloning improvements as mentioned in Boud's previous email. To start with the above priority is a
> good start.
> 
> Often requested:
> 
> - Support for Multi-layer exr.

I think we have some support already -- but it probably isn't thoroughly 
tested.

> 
> - Photoshop hotkeys (a little off-topic), layout and tool workflows. All in all we have to admit that every user
> that turns to Krita will have years of experience and workflows in photoshop. Right now more users still need to
> be attracted. So while it is great to try and create a better keyboard layout than photoshop right off the bat,
> we still have to think about keeping the UI open to photoshop users who may not be willing to learn new
> workflows just yet. I'd say as a rule of thumb, when designing the UI to any tool, we should all check out the
> photoshop equivalent FIRST and only change it if there is a real disadvantage or problem to it.
> I will try to create a keyboard layout config that closely mimics photoshops as soon as I have a spare second.

Right :-).


> - The topic of Gamma and Gain sliders (that affect ONLY the display) came up again. I went to take a look again
> at the LUT docker which was meant to fulfill this role but I am getting very unpredictable results. Currently if
> 'use environment is selected there is no effect on the image as you scrub the exposure and gamma sliders at all.
> I will do more research on this tonight and will reopen the 'Lut Docker' thread.

Was opengl enabled? Also, was the OpenColorIO environment setup properly? 
This should work, though I only tested with a subset of available configs.

I checked with the sample nuke config, but it's gotten quite a bit slower 
since December for some reason....

> 
> Would be Nice:
> 
> - Live file-in layer. (seems like boudj has already started on this)
> 
> I'll append to this tonight or on the weekend but that's a start. :)
> 
> 
> 
> 
> 
> On Tue, Mar 26, 2013 at 2:22 PM, Boudewijn Rempt <boud at valdyas.org> wrote:
>       Hi,
>
>       Here is a summary of my notes from last week's london visit: the list of ideas that would make Krita
>       even cooler than it already is for people in the vfx world. When we sat down at dneg, basically we
>       had something attractive to offer to every category of artist, from matte to texture, from
>       dust-busting to concept artist.
>
>       * Integration with the pipeline:
>
>       Ocio is great and the future, but Krita is flexible enough that we now can also support the legacy
>       color management paths still in use
>
>       * Integration with Nuke, Blender, etc.
>
>       Well, only Nuke, really. Blender would be cool, but we haven't met Blender users in London. The idea
>       is to have a krita-backed image/layer node in Nuke. Activate the node activates Krita, and the
>       inputs and outputs are Krita layers.
>
>       * Healing/Cloning
>
>       We have a healing/cloning paintop, but it isn't really strong enough according to David, for the use
>       of Matte painters. We can do a lot there.
>
>       * Matte stuff
>
>       - Content-aware fill, maybe even as a filter layer or filter mask
>       - Improved masking: import and export of masks from and to image files
>       - Improved mask visualization
>       - Improved scaling (https://gitorious.org/cubic-b-spline-interpolator)
>
>       * Dynamic file-backed layers
>
>       Basically, a file on disk that is shown as a layer. Read-only and possibily in a different
>       resolution, but scaled to the image resolution automatically. I started on this already
>
>       * Image manager
>
>       Well, not really inside Krita, but these people need a Studio version of Gwenview that supports
>       OpenImageIO really badly. Something to manage, tag, compare and view hundreds of thousands of exr,
>       dpx, cineon and other
>       images.
>
>       * HDR Color Selector
>
>       This needs to be brought in line with Mari's HDR color selector: for HDR images an exposure slider
>       that is independent of the image exposure slider needs to be added.
>
>       * Python Scripting
>
>       Not for painting, but adding bits of gui and executing filters, scaling, merging and other
>       operations.
>
>       I think that this was it, actually -- as I said, we're pretty good already :-)
>
>       Boudewijn
>       _______________________________________________
>       Krita mailing list
>       kimageshop at kde.org
>       https://mail.kde.org/mailman/listinfo/kimageshop
> 
> 
> 
> 
> --
> Simon Legrand
> http://slegrand.blogspot.com/
> 
>


More information about the kimageshop mailing list