vfx features for Krita

Fri Mar 29 02:07:34 UTC 2013

On Thu, Mar 28, 2013 at 12:13 PM, Simon Legrand <legrand.simon at gmail.com>wrote:

> 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.
>

It's a bit tricky. There isn't a single file with just the shortcuts in it.
Additionally to the KDE system Krita stores the shortcuts to
~/.kde4/share/config/kritarc
file (which is suppose was done to work around some problem). I can have a
look if we can switch that to a separate file.

> 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/
>
> _______________________________________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20130329/c415dc32/attachment-0001.html>