<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi everyone,<br><br>Simon Legrand wrote:<br>> We should all check out the photoshop equivalent FIRST and only change it if there is a real disadvantage or problem to it.<br>> I will try to create a keyboard layout config that closely mimics photoshops as soon as I have a spare second.<br><br>I agree it is important to try to follow Photoshop "rules" (since this software is widespread everywhere).<br>However, on Linux, I suppose it is not that easy since every "Desktop" (Kde, Gnome, Unity etc) follows slightly different rules.<br><br>BTW, this same topic (about shortcuts) has been discussed in this mailing list in the past  [0]<br><br>Regarding the Krita shortcuts, I am wondering how difficult would be to implement an option to simply import a file into Krita with all Photoshop shortcuts enabled?<br><br>In essence, as with Gimp [1], the user should be

 able to paste a text-file (e.g. the ps-menurc with Gimp) in the appropriate folder of Krita in order to get all Photoshop shortcuts out of the box.<br>This option would be extremely time-saving :-)<br><br>Best regards,<br><br>Silvio<br><br>[0] http://mail.kde.org/pipermail/kimageshop/2010-October/009194.html<br>[1]  http://epierce.freeshell.org/gimp/gimp_ps.php<br><br><br>--- <b>Mer 27/3/13, Boudewijn Rempt <i><boud@valdyas.org></i></b> ha scritto:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>Da: Boudewijn Rempt <boud@valdyas.org><br>Oggetto: Re: vfx features for Krita<br>A: "Krita's developers and users mailing list" <kimageshop@kde.org><br>Data: Mercoledė 27 marzo 2013, 17:59<br><br><div class="plainMail">On Wed, 27 Mar 2013, Simon Legrand wrote:<br><br>> Hey guys. So the Matte painting guys have been putting Krita through its paces and this is what they came up<br>>

 with as their main priorities:<br>> <br>> Priority:<br>> <br>> - Performance. That's the greatest priority. We need to be able to paint in 16bit 4k + smoothly.<br><br>Tthat needs investigation. I am noticing that there are sometimes awful <br>delays, and sometimes it's just smooth. But yeah, needs investigation.<br><br>> - Painting on the 'transparency layer' should be done with black and white color not with eraser and paint.<br><br>Dmitry already has that in a branch, it needs some finishing touches <br>though, most fixing a few remaining brushes.<br><br>> -This transparency layer should be displayable on its own. IE: ctrl+eye on a transparency layer should display<br>> the layer as a grayscale image<br><br>I've been thinking about this since the meeting in London. I thought we <br>could load/save masks as images, but that's not true either -- both need <br>to be implemented. Anyone any idea on how to fix this? If masks were

 <br>really grayscale, it would have been easy enough, I guess.<br><br>> - At the moment the brush opacity in the transparency layer seems to be either 1 or nothing. The painting<br>> environment of the layer mask should be full greyscale like any normal greyscale layer.<br><br>Thats the same issue as the one above: this also solved in Dmitry's <br>branch.<br><br>> - Clone tool needs a 'sample anything visible option'. Dare I say like Gimp (sample merged)? Or photoshop's<br>> default clone tool behaviour. :)<br><br>Right.<br><br>> Important:<br>> <br>> - Select by colour improvement. At the moment it's limited to a selection box with discreet hues to pick from.<br>> This would be nice to turn into a color picker with some parameters for adjusting the range of selection<br>> (threshhold in Gimp, fuzziness in Krita fill selection)<br><br>There is the "select similar colors" tool -- that selects using a color <br>picker with a

 range determined by fuzziness. Or do you mean something <br>else?<br><br>I actually don't know why we have the select/select from colorrange dialog<br>still -- it's really old.<br><br>> <br>> - Healing and cloning improvements as mentioned in Boud's previous email. To start with the above priority is a<br>> good start.<br>> <br>> Often requested:<br>> <br>> - Support for Multi-layer exr.<br><br>I think we have some support already -- but it probably isn't thoroughly <br>tested.<br><br>> <br>> - Photoshop hotkeys (a little off-topic), layout and tool workflows. All in all we have to admit that every user<br>> that turns to Krita will have years of experience and workflows in photoshop. Right now more users still need to<br>> be attracted. So while it is great to try and create a better keyboard layout than photoshop right off the bat,<br>> we still have to think about keeping the UI open to photoshop users who may not

 be willing to learn new<br>> workflows just yet. I'd say as a rule of thumb, when designing the UI to any tool, we should all check out the<br>> photoshop equivalent FIRST and only change it if there is a real disadvantage or problem to it.<br>> I will try to create a keyboard layout config that closely mimics photoshops as soon as I have a spare second.<br><br>Right :-).<br><br><br>> - The topic of Gamma and Gain sliders (that affect ONLY the display) came up again. I went to take a look again<br>> at the LUT docker which was meant to fulfill this role but I am getting very unpredictable results. Currently if<br>> 'use environment is selected there is no effect on the image as you scrub the exposure and gamma sliders at all.<br>> I will do more research on this tonight and will reopen the 'Lut Docker' thread.<br><br>Was opengl enabled? Also, was the OpenColorIO environment setup properly? <br>This should work, though I only tested

 with a subset of available configs.<br><br>I checked with the sample nuke config, but it's gotten quite a bit slower <br>since December for some reason....<br><br>> <br>> Would be Nice:<br>> <br>> - Live file-in layer. (seems like boudj has already started on this)<br>> <br>> I'll append to this tonight or on the weekend but that's a start. :)<br>> <br>> <br>> <br>> <br>> <br>> On Tue, Mar 26, 2013 at 2:22 PM, Boudewijn Rempt <<a ymailto="mailto:boud@valdyas.org" href="/mc/compose?to=boud@valdyas.org">boud@valdyas.org</a>> wrote:<br>>       Hi,<br>><br>>       Here is a summary of my notes from last week's london visit: the list of ideas that would make Krita<br>>       even cooler than it already is for people in the vfx world. When we sat down at dneg, basically we<br>>       had something

 attractive to offer to every category of artist, from matte to texture, from<br>>       dust-busting to concept artist.<br>><br>>       * Integration with the pipeline:<br>><br>>       Ocio is great and the future, but Krita is flexible enough that we now can also support the legacy<br>>       color management paths still in use<br>><br>>       * Integration with Nuke, Blender, etc.<br>><br>>       Well, only Nuke, really. Blender would be cool, but we haven't met Blender users in London. The idea<br>>       is to have a krita-backed image/layer node in Nuke. Activate the node activates Krita, and the<br>>       inputs and outputs are Krita layers.<br>><br>>       *

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 (<a href="https://gitorious.org/cubic-b-spline-interpolator" target="_blank">https://gitorious.org/cubic-b-spline-interpolator</a>) > >       * Dynamic file-backed layers > >       Basically, a file on disk that is shown as a layer.

 Read-only and possibily in a different<br>>       resolution, but scaled to the image resolution automatically. I started on this already<br>><br>>       * Image manager<br>><br>>       Well, not really inside Krita, but these people need a Studio version of Gwenview that supports<br>>       OpenImageIO really badly. Something to manage, tag, compare and view hundreds of thousands of exr,<br>>       dpx, cineon and other<br>>       images.<br>><br>>       * HDR Color Selector<br>><br>>       This needs to be brought in line with Mari's HDR color selector: for HDR images an exposure slider<br>>       that is independent of the image exposure slider needs to be added.<br>><br>>   

    * Python Scripting<br>><br>>       Not for painting, but adding bits of gui and executing filters, scaling, merging and other<br>>       operations.<br>><br>>       I think that this was it, actually -- as I said, we're pretty good already :-)<br>><br>>       Boudewijn<br>>       _______________________________________________<br>>       Krita mailing list<br>>       <a ymailto="mailto:kimageshop@kde.org" href="/mc/compose?to=kimageshop@kde.org">kimageshop@kde.org</a><br>>       <a href="https://mail.kde.org/mailman/listinfo/kimageshop" target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br>> <br>> <br>> <br>> <br>> --<br>> Simon Legrand<br>> <a

 href="http://slegrand.blogspot.com/" target="_blank">http://slegrand.blogspot.com/</a><br>> <br>><br>_______________________________________________<br>Krita mailing list<br><a ymailto="mailto:kimageshop@kde.org" href="/mc/compose?to=kimageshop@kde.org">kimageshop@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/kimageshop" target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br></div></blockquote></td></tr></table>