vfx features for Krita

Simon Legrand legrand.simon at gmail.com
Thu Mar 28 11:13:52 UTC 2013 

Ok great. My apologies about the color picker tool I did not see it. :)
Lut: docker, I was under the impression $OCIO was set for us but it wasn't.
I'll play around again with that soon. we're under tight deadlines atm.

About the 16bit 4k image performance. It may have been related to the
multi-layer exr format we're using in-house. More investigation needed.

Regarding the shortcuts. I understand it may not seem like much, but I
think it'll be worth it. KDE's shortcut system has always been a bit of a
mystery to me too. I'll try to make some shortcuts and dig out whatever
file kde creates to save them.

I still need to fix my templates. apologies for the slow turn-around.

Also, is it possible to have a 'latest' krita snapshot in the Centos repo?
We're quite happy to be working with the cutting edge version over here so
that we can make constructive comments on things that haven't 'already been
fixed'.

If someone is happy to teach me to maintain this repo I'm happy to do it.


On Wed, Mar 27, 2013 at 4:59 PM, Boudewijn Rempt <boud at valdyas.org> wrote:

> 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 <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<https://mail.kde.org/mailman/listinfo/kimageshop>
>>
>>
>>
>>
>> --
>> Simon Legrand
>> http://slegrand.blogspot.com/
>>
>>
>>  ______________________________**_________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/**listinfo/kimageshop<https://mail.kde.org/mailman/listinfo/kimageshop>
>



-- 
Simon Legrand
http://slegrand.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20130328/55fb63d7/attachment-0001.html>

More information about the kimageshop mailing list